Background to Agile Methods

Agile methods are part of a software development model known as Iterative and Incremental Development (IID). IID was used in projects dating back to the early 1960’s. For example, developers on the NASA Mercury space project (1962) used short half-day iterations to develop its software systems.

The term “Agile Methods” refers to a group of software development methods that evolved during the mid 1990’s, such as: Scrum; Adaptive Software Development; Dynamic Systems Development Method DSDM (1995); eXteme Programming and Crystal Clear (1996).

These approaches were referred to initially as “lightweight” methods to distinguish them from the traditional “heavyweight” approach that usually involves a long waterfall type life-cycle and extensive project planning. After the Agile Manifesto was produced (see below) the “lightweight” methods were rebranded as Agile Methods.

Not much in these agile methods is actually new – what they do is bring a fresh approach to iterative development.

The Agile Manifesto

In 2001, a number of experts in the field of agile development gathered in Utah to discuss ways in which software could be developed in a more efficient, people-oriented manner. They captured their ideas through the Agile Manifesto(1), generally regarded as the essence of agile development and its principles. Some of the people involved in this meeting formed the Agile Alliance(2), a non-profit organisation promoting the agile approach.

The Agile manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

(1) www.agilemanifesto.org
(2) www.agilealliance.org

Characteristics of Agile Methods

Agile methods contain a number of common characteristics:

• Iterative Development – working software is produced in short cycles, called iterations, typically one to four weeks. The number of iterations varies with the size of the project. The final iteration should produce a fully functioning system.
• Customer Requirements are not fully understood and/or are subject to change. Agile proponents feel that this situation represents most projects in the real world.
• New Tools or Technologies make the software development process unpredictable. Development staff take more time to adapt to new tools or technologies because of their inexperience, compared to tools or technologies that they are familiar with.
• Regular Project Meetings – project meetings are usually held daily, often at the start of the day. The meetings are usually short, and are designed to check progress. The role of the project manager in these meetings is to ensure is one organising these meetings and in resolving any problems that are impeding the team’s progress.

Where is the Agile Approach Not Proven?

The agile approach is not proven in the following types of projects:

• Large project teams (greater than around eight people)
• Less experienced development staff
• Teams that are distributed by e.g. different offices/buildings, sub-contracted teams, different geographical locations etc
• Safety-critical systems e.g. medical devices, aircraft systems

Boehm and Turner(3) have suggested that these projects may be more suited to a plan-driven approach using more traditional project plans. Although agile methods are usually aimed at smaller project teams, several methods, such as Scrum for example, do tackle larger projects by breaking them down into smaller pieces of work, co-ordinated by an overall leader.

(3) Boehm, B. & Turner R. Balancing Agility and Discipline – a Guide for the Perplexed (Addison-Wesley, 2004)