Agile Methods In Large Organizations

Software Experience Center Consortium

Agile Methods In Large Organizations

An experience report from the Software Experience Center (SEC)

Consortium

Mikael Lindvall

[email protected]


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


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


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


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


Topics


• Approach (How the material was collected)



• Conclusion & Future usage

• Recognition


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


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


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


What was different then?

Incompatibilities between the XP Pilot and its environment

XP Pilot:New practices

ProjectEnvironment:

Existing practices

“Most difficulties were found in the project environment and not in XP!”

(Organization, Quality Systems, Processes)

Tailoring is always required to minimize incompatibilities!


Topics


• Approach (How the material was collected)



• Conclusion & Future usage

• Recognition


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


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”


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.”


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’”


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”


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.”


Incompatibilities between the XP Pilot and the environment need to be resolved

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

Customers

Requirements

Other teams

Architecture

Legacy systems

Change Control Boards

Quality Systems

Organizational Software processes

XP pilot


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


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

Documents

Agile Methods In Large Organizations