The New Methodology

　　Other Sources

　　Recently we've seen two good books appear which look at the broad topic of agile methods from Alistair Cockburn and Jim Highsmith.

　　There are a number of other papers and discussions about this theme of agile methods. While these may not be full methodologies, they do offer insights into this growing field.

　　The Patterns Language of Programming conferences has often contained material that touches on this subject, if only because many of the folks interested in patterns are also interested in more adaptive and humane methods. A leading early paper was Jim Coplien's paper at PLoP1. Ward Cunningham's Episodes pattern language appeared in PLoP2. Jim Coplein now hosts the OrgPatterns site, a wiki which collects together patterns for organizational patterns.

　　Dirk Riehle sent a paper to XP2000 that compares the value systems of XP and Adaptive Software Development. The July edition of the Coad letter compares XP to FDD. The July edition of IEEE Software includes several articles on "process diversity" which touch on these methodologies.

　　Mary Poppendieck wrote a fascinating article comparing agile methodologies with lean manufacturing.

Should you go agile?

　　Using a agile method is not for everyone. There are a number of things to bear in mind if you decide to follow this path. However I certainly believe that these new methodologies are widely applicable and should be used by more people than currently consider them.

　　In today's environment, the most common methodology is code and fix. Applying more discipline than chaos will almost certainly help, and the agile approach has the advantage that it is much less of a step than using a heavyweight method. Here much of the advantage of the agile methods is indeed their light weight. Simpler processes are more likely to be followed when you are used to no process at all.

　　One of the biggest limitations to these new methodologies is how they handle larger teams. Like many new approaches they tend to be used first on a small scale rather than a larger scale. Also often they've been created with an emphasis on small teams. Extreme Programming explicitly says that it is designed for teams of up to around twenty people. It's worth remembering that many software teams could be reduced in size without reducing the overall productivity.

　　Other agile approaches are intended for larger sized teams. FDD was originally designed around a fifty person project. ThoughtWorks has used XP influenced projects with a team of around a 100 in three continents. Scrum's been used to handle similar sized product teams.

　　Hopefully one message that's clear from this article is that adaptive approaches are good when your requirements are uncertain or volatile. If you don't have stable requirements, then you aren't in the position to have a stable design and follow a planned process. In these situations an adaptive process may be less comfortable, but it will be more effective. Often the biggest barrier here is the customer. In my view it's important for the customer to understand that following a predictive process when requirements change is risky to them just as much as it is to development.

　　If you are going to take the adaptive route, you need to trust your developers and involve them in the decision. Adaptive processes rely on you trusting your developers, so if you consider your developers to be of low quality and motivation then you should use a predictive approach.

　　So to summarize. The following factors suggest an adaptive process

　　Uncertain or volatile requirements
Responsible and motivated developers
Customer who understands and will get involved.
These factors suggest a predictive process

　　A team of over a hundred
Fixed price, or more correctly a fixed scope, contract