Page 78 -

3.1 Agile methods 61

5. Many organizations, especially large companies, have spent years changing
their culture so that processes are defined and followed. It is difficult for them to
move to a working model in which processes are informal and defined by devel-
opment teams.

Another non-technical problem—that is a general problem with incremental
development and delivery—occurs when the system customer uses an outside organ-
ization for system development. The software requirements document is usually part
of the contract between the customer and the supplier. Because incremental specifi-
cation is inherent in agile methods, writing contracts for this type of development
may be difficult.
Consequently, agile methods have to rely on contracts in which the customer pays
for the time required for system development rather than the development of a spe-
cific set of requirements. So long as all goes well, this benefits both the customer and
the developer. However, if problems arise then there may be difficult disputes over
who is to blame and who should pay for the extra time and resources required to
resolve the problems.
Most books and papers that describe agile methods and experiences with agile
methods talk about the use of these methods for new systems development.
However, as I explain in Chapter 9, a huge amount of software engineering effort
goes into the maintenance and evolution of existing software systems. There are only
a small number of experience reports on using agile methods for software mainte-
nance (Poole and Huisman, 2001). There are two questions that should be consid-
ered when considering agile methods and maintenance:

1. Are systems that are developed using an agile approach maintainable, given the
emphasis in the development process of minimizing formal documentation?

2. Can agile methods be used effectively for evolving a system in response to cus-
tomer change requests?

Formal documentation is supposed to describe the system and so make it easier
for people changing the system to understand. In practice, however, formal docu-
mentation is often not kept up to date and so does not accurately reflect the program
code. For this reason, agile methods enthusiasts argue that it is a waste of time to
write this documentation and that the key to implementing maintainable software is
to produce high-quality, readable code. Agile practices therefore emphasize the
importance of writing well-structured code and investing effort in code improve-
ment. Therefore, the lack of documentation should not be a problem in maintaining
systems developed using an agile approach.
However, my experience of system maintenance suggests that the key document
is the system requirements document, which tells the software engineer what the
system is supposed to do. Without such knowledge, it is difficult to assess the impact
of proposed system changes. Many agile methods collect requirements informally
and incrementally and do not create a coherent requirements document. In this