Agile Methods In Large Organizations

1
Agile Methods In Large Organizations

• An experience report from the Software
  Experience Center (SEC) Consortium
• Mikael Lindvall
• mikli_at_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
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 cant 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 CCBs 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
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