Page 79 -

62 Chapter 3 Agile software development

respect, the use of agile methods is likely to make subsequent system maintenance
more difficult and expensive.
Agile practices, used in the maintenance process itself, are likely to be effective,
whether or not an agile approach has been used for system development. Incremental
delivery, design for change and maintaining simplicity all make sense when software
is being changed. In fact, you can think of an agile development process as a process
of software evolution.
However, the main difficulty after software delivery is likely to be keeping cus-
tomers involved in the process. Although a customer may be able to justify the full-
time involvement of a representative during system development, this is less likely
during maintenance where changes are not continuous. Customer representatives are
likely to lose interest in the system. Therefore, it is likely that alternative mecha-
nisms, such as change proposals, discussed in Chapter 25, will be required to create
the new system requirements.
The other problem that is likely to arise is maintaining continuity of the develop-
ment team. Agile methods rely on team members understanding aspects of the
system without having to consult documentation. If an agile development team is
broken up, then this implicit knowledge is lost and it is difficult for new team mem-
bers to build up the same understanding of the system and its components.
Supporters of agile methods have been evangelical in promoting their use and
have tended to overlook their shortcomings. This has prompted an equally extreme
response, which, in my view, exaggerates the problems with this approach (Stephens
and Rosenberg, 2003). More reasoned critics such as DeMarco and Boehm
(DeMarco and Boehm, 2002) highlight both the advantages and disadvantages of
agile methods. They propose a hybrid approach where agile methods incorporate
some techniques from plan-driven development may be the best way forward.

3.2 Plan-driven and agile development

Agile approaches to software development consider design and implementation to be
the central activities in the software process. They incorporate other activities, such as
requirements elicitation and testing, into design and implementation. By contrast, a
plan-driven approach to software engineering identifies separate stages in the soft-
ware process with outputs associated with each stage. The outputs from one stage are
used as a basis for planning the following process activity. Figure 3.2 shows the dis-
tinctions between plan-driven and agile approaches to system specification.
In a plan-driven approach, iteration occurs within activities with formal docu-
ments used to communicate between stages of the process. For example, the require-
ments will evolve and, ultimately, a requirements specification will be produced.
This is then an input to the design and implementation process. In an agile approach,
iteration occurs across activities. Therefore, the requirements and the design are
developed together, rather than separately.