Using Agile engineering tools and practices to achieve organizational change
Organizational change is hard, and often teams attempt to implement Agile practices and processes without management support. While a key factor in the success of Agile efforts is adequate process support from senior levels, often agile practices and processes can be used at the grass roots level to improve the culture, which can lead to management buy-in. Areas such as build process, testing approaches, software design, and even IDEs and their configuration can determine aspects such as frequency of change submission, frequency of test execution, and even how projects are laid out and allocated among personnel. These subtle variations can have a remarkable effect on development organization culture, on attitudes towards quality, on release management overhead and care. By making simple changes in these areas, the subtle side-effects can be maximized. This can, in turn, be made visible to help Management see the value in the overall agile approach, which can turn into appropriate organizational support for working in an Agile manner.
Christian will examine these practices, their effects, and provide examples where such a grass-roots approach helped convince management to support or pilot fully agile approaches. He will also provide counter-examples and anti-patterns which can often lead to such an effort being blocked. Attendees should leave better armed to start practising “stealth agile” but with a mind to ultimately demonstrating its value and shifting the organization.
The presentation will largely be explanatory and visualized with presentation aids.
For example, looking at build processes, an overview would be given, starting from a description of a terrible (but realistic) example of a build process. Key metrics about that process would be shown visually, such as a value-stream chart of the developer’s modify-build-execute_test-evaluate cycle, statistics on frequency of check-ins and test execution, impacts such as work-batching with proper reference to Poppendieck and others around queuing theory. Then a more robust build process will be described, including tools to implement and an approach for gradual roll-out. At each stage of modification, the implications will be examined, including (for this example) smaller sub-projects/modules, shorter builds, more frequent test execution, etc. The cultural impacts will be described, taking anonymous real-world examples to illustrate. Then means of presenting these improvements to management in order to best garner support for further change will be offered.
Areas of focus will be on build process (per above), design for testability, organization of source code projects/repository, separation of types of testing (unit, functional,integration) and implementing separate lifecycles for each, continuous-integration/automated build scheduling, etc. Given time, even areas such as platform selection and others can be examined.
Lastly, there would be a Q&A section.