In each item the proposal on the left is favoured over the traditional idea on the right. The participants to this conference later formed a non-profit organisation called The Agile Alliance with the purpose of promoting and advancing agile development processes. Several companies also offer “certification courses” aimed at formalising training for agile development processes4.
By aligning many different “alternative” approaches and iterative practices, the group could also develop their image and branding and thus market this approach in the software development community. A coordinated front was also required to give legitimacy to an ap- proach that would be involved in large-scale projects. Many traditional company executives would not be comfortable trusting their development processes to a “group of independent thinkers”. The formalisation of the alliance could quell some of these concerns.
The Agile Alliance currently has more than 4 000 members and is also responsible for the organisation of an annual conference and several smaller “programmes”(AgileAlliance, 2010b). The goal of this alliance is not to design a single unified methodology, but rather to coordinate the myriad of independent methodologies adhering to the agreed set of tenets and principles accepted by the members of the alliance.
3.2
Background
As noted in earlier chapters, there is intense disagreement on the exact definition and delim- itation of the concept “agile development”. Indeed many authors5 have argued that agile development is not really a separate type of development methodology, but rather a natu- ral evolution of existing practices. Many academic debates have grappled with this issue, including the well-known feature articles in Cutter IT Journal - The Great Methodologies Debate: Part 1 and Part 26.
It is important to bear in mind that the use of agile development processes does not preclude any other methodologies. Many organisations successfully apply a wide range of different development styles. In fact Hawrysh & Ruprecht (2000), indicate that a single
4
The Agile Alliance has a position paper on the matter discussing the relative merits of different types of certification. The Alliance itself does not provide or endorse any certification. (AgileAlliance, 2010a).
5
Listed and argued at length by ˚Agerfalk & Fitzgerald (2006).
6
Cutter IT Journal, November (Vol. 14, No. 11), December 2001 (Vol. 14, No. 12) and January 2002 (Vol. 15, No. 1)
Figure 3.1: The Planning Spectrum
SOURCE: Boehm (2002, p. 65)
methodology is likely to fail and advise that project managers should carefully consider the specific project before selecting a development approach7.
Boehm (2002, p. 65) argues that all development (especially plan-based methodologies) are located on a spectrum of increasing emphasis on plan (reproduced in Figure 3.1). Agile methods are of course more unstructured than micromanaged milestone planning (in his terms “inch-pebble ironbound contract planning”), but still more rigid than disorganised hacking. Also note the scope of the CMM with regards to the planning spectrum.
3.2.1 Central themes
The “tenets” listed in the agile manifesto can be further expanded as central themes relevant to all approaches grouped under the umbrella term agile.
Individuals and interactions
The first important shift is the move away from a central planning process completed in advance. Key decisions are now made by the developers and other team members as they become important. This shift not only means greater communality between developers, but also improved ownership of the project by ordinary developers.
A golden thread running through agile development discussions is the newfound empha- sis being placed on the human factor involved in software development. In fact Cockburn & Highsmith (2001), go as far as to say “agile development teams focus on individual com-
7
3.2 — Background 32
petency as a critical factor in project success”. This brings about a shift in the conceptual- isation of the “software programmer”. The amount of decision making (and concomitantly responsibility) devolved to the individual developer is greatly increased.
Highsmith & Cockburn (2001, p. 121) comment that “what is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and manoeuvrability. This yields a new combination of values and principles that define an agile world view.”
This is an important break with the conception of the “worker” promoted in scientific or behaviourist management. Gone is the notion that the worker is a generic “factor of production” that can be replaced or interchanged whenever necessary (Taylor, 1919).
It also breaks with neo-classical economics and idea of homo economicus. Human beings, workers, team members are now recognised as idiosyncratic individuals with their own skills, ideas, strengths and weaknesses. Team structure and functioning are adapted to harness these differences, rather than attempting to mould individual workers to fit in pre-defined job descriptions.
While this certainly conforms to the distributed management model in use in agile projects, it does also pose certain challenges. For example, Constantine (2001, p. 68) identifies a problem: “There are only so many Kent Becks in the world to lead the team. All of agile methods put a premium on having premium people. . . ”. Boehm (2002) poignantly adds to this by noting the statistical dilemma of 49.99999 per cent of programmers being below average8.
The quality (in terms of skills, ability and tacit knowledge) of the individuals involved in the agile development project is largely responsible for the adaptability achieved by electing these development approaches. Moving decision making from some prepared plan to an individual, presupposes that the individual will be able to handle the added responsibilities. In practice, this does mean that some exceptional (or at least above-average) developers are required to effectively run an agile project.
8
Whether this statistical observation is relevant and sensible or just a rhetorical device is left to the reader.
Working software
The second important distinction of agile development is the (infamous) reduction in doc- umentation vis-`a-vis traditional approaches. The guiding principle is that working code is more valuable than planning documents. To cope with quality concerns, agile development introduces the notion of continual testing of all completed modules. Highsmith & Cockburn (2001, p. 121) lists “the unforgiving honesty of working code” as one of the basic concepts of agile development:
Working code tells the developers and sponsors what they really have in front of them — as opposed to promises as to what they will have in front of then. The working code can be shipped, modified, or scrapped, but it is always real.
An additional benefit of avoiding copious documentation is the promotion of simplicity. For example, one of the traps avoided by agile development is referred to as YAGNI (“You Aren’t Going to Need It”) (Boehm, 2002)9.
To compensate for the lack of formal documentation, agile development once again relies on the human developers involved in the project. The close and frequent interaction between members, brought about by the organisational structure and processes of an agile team, fills the gaps left by the lack of documentation. This is also augmented by the strong focus on continual testing and refactoring, enabling future developers to understand the source code directly, rather than having to rely on external documentation.
Additionally proponents of agile development employ the concept of “self-documenting code”. By using meaningful variable names, classes and structures, the functioning of the code becomes apparent without the need to resort to formal documentation.
Customer collaboration
Agile development gives precedence to customer collaboration over contract negotiation. This does not mean that contracts are no longer needed. On the contrary, the importance of the contract increases commensurately with the size of the project (Abrahamsson et al.,
9Here Boehm, however, notes that this approach only works well when you assume an unstable and
changing environment. In relatively stable environments it may indeed be quite sensible and responsible to do the planning and architecture of new systems in advance. This fundamental assumption of uncertainly becomes a contentious issue within the field of software development in general.
3.2 — Background 34
2002). The shift is that the contract negotiation session itself becomes part of building a relationship with the customer.
By directly involving the customer in the development process, many changes and adap- tations can be effected as soon as they become apparent. This constant interaction (com- bined with rigorous procedures for limiting changes during a development session) assists the developers in creating products that are as close to customer expectations as possible.
Responding to change
The final (and possibly best known) theme found in agile development implementations is the deep concern with adaptability to change. Instead of the change management pro- cesses followed in traditional development methodologies, development team members and customer representatives are empowered to constantly adapt the project to keep up with changing real-world requirements.
Boehm’s life cycle cost differentials theory explains that the cost of change increases throughout the project’s development life cycle. To minimise the cost of producing a relevant and useful product, it therefore become essential that necessary changes are made as soon as they become apparent (Highsmith & Cockburn, 2001). Agile development enables these quick changes by devolving decision making authority to the developers, rather than requiring higher level approval.
At the core of this responsiveness to change, is the iterative development paradigm (Favare, 2002). By accepting change and improvement and fundamental presuppositions of any development process, it becomes easier to adapt without falling into the trap of shifting targets.
This sensitivity to change not only allows for greater adaptability, but also shortens the life-cycle of the project. Miller (2001) explains this compression by referring to nine characteristics of this development approach:
1. Modularity on development process level
2. Iterative with short cycles enabling fast verifications and corrections 3. Time-bound with iteration cycles from one to six weeks
5. Adaptive with possible emergent new risks
6. Incremental process approach that allows functioning application building in small steps
7. Convergent (and incremental) approach minimises the risks
8. People-oriented, i.e. agile processes favour people over processes and technology 9. Collaborative and communicative working style