Agile Methods In Large Organizations

1. Agile Methods In Large Organizations An experience report from the Software Experience Center (SEC) Consortium Mikael Lindvall mikli@fc-md.umd.edu

2. Topics • Background (SEC and Motivation) • Approach (How this study was conducted) • Overall results from XP Pilots • Six Observations and Pilot Examples • Summary & Future usage of agile methods • Recognition

3. The Software Experience Center (SEC) Consortium • Founded: 1999 • Members: ABB, Boeing, DaimlerChrysler, Motorola, Nokia • Goal: Improve members’ software competencies, practices • Method: Actively share experiences • Topics: Subcontracting, Requirements Eng., Product Lines etc. • Facilitators, Experience Collectors: Fraunhofer Virtual Institute for Empirical Software Engineering

4. Motivation & Background • Agile methods have shown to be useful in many situations • SEC members: Will agile methods work for us? • They studied, applied agile methods, shared experience • This is an analysis of some of their experiences

5. Approach/How this study was conducted • Based on 4 SEC meetings and one eWorkshop on agile • Experience was openly shared • Decision to compile, report on this experience • Complemented with internal reports, published papers • Material from 15 XP-influenced pilots (various level of detail) • Identified common experiences across organizations • The final report is awaiting formal approval

6. Topics • Background (SEC and Motivation) • Approach (How the material was collected) • Overall results from XP Pilots • Six Observations and Pilot Examples • Conclusion & Future usage • Recognition

7. Business Drivers • Examples: • Software teams face a continuous battle to increase productivity while maintaining and/or improving quality • Large investments in requirements specifications that later change • Development has to begin with incomplete requirements • Quality system too generic and complex to provide good support • Heavy process approaches were disappointing

8. Overall results from XP Pilots • Will agile methods work for us? • 15 XP-influenced pilots were conducted • New web projects – existing large safety critical systems • 10 weeks - 18 months • Less then 10 people • All pilots had similar positive experiences: • Able to respond to change quicker • Improved one or more of the attributes: • customer satisfaction, • quality, • productivity, and/or • cost • Team morale, job satisfaction increased • It was not costly to introduce the practices

9. Practices • Beneficial practices/practices easy to implement (Examples): • Pair Programming prevented gold plating and complex designs • Small releases ensured that there was always a running system • Pair programming, automated test and small releases improved quality • Less beneficial practices/practices not so easy to implement (Examples): • Pair-programming requires a fair amount of planning • There have been problems with the system metaphor practice • Test First Programming was not easy to introduce Most other experience reports mention similar findings

10. Project Environment: Existing practices XP Pilot: New practices What was different then? “Most difficulties were found in the project environment and not in XP!” Incompatibilities between the XP Pilot and its environment (Organization, Quality Systems, Processes) Tailoring is always required to minimize incompatibilities!

11. Topics • Background (SEC and Motivation) • Approach (How the material was collected) • Overall results from XP Pilots • Six Observations and Pilot Examples • Conclusion & Future usage • Recognition

12. 1. Customers • Observation and Challenge • XP suggests one clearly defined customer to be a member of the team • There were often many-to-many relationships between customers and development teams • Examples from pilots • “[To have one customer onsite] was not possible due to the structure of our organization.” • “Instead, each team used their technical domain expert as a “customer proxy.” • See also article on “Scaling Agile Methods” etc

13. 2. Interfacing with other teams • Observation and Challenge • XP changes the way the work is conducted by the team • The work was often distributed over several teams and the XP team needed to collaborate with non-XP teams • Examples from pilots • “The XP team wanted just one or two pieces of a shared interface to work with at a time. The traditional team wanted to develop and review the entire interface before providing it to the XP team.” • “Careful negotiation between the two teams can resolve this conflict.” • See also “The 5 reasons XP can’t scale and what to do about them” and “Limitations of Agile Software Processes”

14. 3. Change Control Board and Refactoring • Observation and Challenge • XP encourages refactoring, i.e. changes to the system that leaves its behavior unchanged and enhances its quality (e.g. simplicity, flexibility, understandability, or performance) • The CCB approved the implementation of the identified change ONLY; • Examples from pilots • “Refactoring clashed with the CCB’s desire to minimize changes.” “Developers were encouraged to think of refactoring ideas but to ask permission from CCB before implementing them.” • “This control increased in intensity as the final release grew closer and as refactorings occasionally broke a previously working feature.”

15. 4. Change Control Board and Continuous Integration • Observation and Challenge • XP recommends frequent integrations • The CCB controls what changes are integrated • Examples from pilots • “A small defect was detected” • “The CCB postponed integration of it.” “Significant changes were made to the code before the defect was approved.” “The file version with the defect fix was very different from the mainline.” “The merge was now non-trivial and had to be done manually.” • See also “Catalog of XP Project ‘Smells’”

16. 5. Quality System and Pair programming • Observation and Challenge • XP suggests that pair programming reduces the need for formal reviews • In most cases, the pilots found that additional quality assurance was necessary • Examples from pilots • “We were required to have a more rigorous review process, because we were doing public safety development.” • “The likelihood of PP eliminating all coding mistakes is small.” • “In our environment, formal reviews can complement pair programming.” • See also “Limitations of Agile Software Processes”

17. 6. Organizational Software Processes • Observation and Challenge • Overlap between existing processes, new practices resulted in double work • Examples from pilots • “Input requirements to XP are coarse, but the program delivered detailed requirements to the project in advance.” • “They are not user stories, defined without developers and often outdated.” • “Double work: requirements were analyzed twice.”

18. Customers Requirements Organizational Software processes Development Team Planning game, Short development cycles Pair programming, Test-first programming Collective code ownership, Frequent integration Never solving a problem that has not yet occurred Refactoring, Minimal documentation Change Control Boards Architecture Quality Systems Legacy systems Other teams Incompatibilities between the XP Pilot and the environment need to be resolved XP pilot

19. Summary & The future usage of agile methods • Positive improvements on productivity without compromising quality • Few defects could be traced to XP practices • Best for independent collocated projects involving few people • Can be used for large, complex, safety-critical systems with long life cycles • Always requires tailoring to fit the task at hand • A broader implementation requires changes to culture and quality system • Use of selected agile practices will become more and more common • Agile methods will not be used much, but will influence other processes • Hybrid processes will be the primary way to apply agile principles

20. People who contributed material to this presentation THANKS! • ABB: Christina Wallin, Aldo Dagnino • DaimlerChrysler: Kurt Schneider, Jan-Peter v. Hunnius, Michael Stupperich • Motorola: John May, David Kiefer, Andrij Neczwid, Jason Bowers, Erik Melander, Matthew Baarman, Azeem Ayoob, Jerry Drobka, David Noftz, Rekha Raghu • Nokia: Tuomo Kähkönen, Kari Känsälä, Jari Vanhanen, Jouni Jartti