Page 92 -

3.5 Scaling agile methods 75

Denning et al. (2008) argue that the only way to avoid common software engineer-
ing problems, such as systems that don’t meet customer needs and budget overruns, is
to find ways of making agile methods work for large systems. Leffingwell (2007) dis-
cusses which agile practices scale to large systems development. Moore and Spens
(2008) report on their experience of using an agile approach to develop a large med-
ical system with 300 developers working in geographically distributed teams.
Large software system development is different from small system development
in a number of ways:

1. Large systems are usually collections of separate, communicating systems,
where separate teams develop each system. Frequently, these teams are working
in different places, sometimes in different time zones. It is practically impossi-
ble for each team to have a view of the whole system. Consequently, their prior-
ities are usually to complete their part of the system without regard for wider
systems issues.
2. Large systems are ‘brownfield systems’ (Hopkins and Jenkins, 2008); that is
they include and interact with a number of existing systems. Many of the system
requirements are concerned with this interaction and so don’t really lend them-
selves to flexibility and incremental development. Political issues can also be
significant here—often the easiest solution to a problem is to change an existing
system. However, this requires negotiation with the managers of that system to
convince them that the changes can be implemented without risk to the system’s
operation.

3. Where several systems are integrated to create a system, a significant fraction of
the development is concerned with system configuration rather than original
code development. This is not necessarily compatible with incremental develop-
ment and frequent system integration.

4. Large systems and their development processes are often constrained by exter-
nal rules and regulations limiting the way that they can be developed, that
require certain types of system documentation to be produced, etc.
5. Large systems have a long procurement and development time. It is difficult to
maintain coherent teams who know about the system over that period as,
inevitably, people move on to other jobs and projects.

6. Large systems usually have a diverse set of stakeholders. For example, nurses and
administrators may be the end-users of a medical system but senior medical staff,
hospital managers, etc. are also stakeholders in the system. It is practically impos-
sible to involve all of these different stakeholders in the development process.

There are two perspectives on the scaling of agile methods:

1. A ‘scaling up’ perspective, which is concerned with using these methods for
developing large software systems that cannot be developed by a small team.