Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Sunday, August 28, 2005

How do you know if your project is Agile?

Some recent posts about Big Design Up Front being a good thing have stirred the Agile pot. The main problem with a defense of Agile methods today is that there is no definitive statement of what exactly "agile" means. The typical explanations by proponents sounds something like "I know it when I see it."

If as an Agile community we are to clearly communicate, this kind of "bob and weave" argument will have to stand and fight. Skeptics make good points about the dangers of "extremists" in the Agile camp shunning documentation, up front design, solo programming, and other common practices. In turn, agile "thought leaders" make well-reasoned replies, generally of the form "Our community is a big tent, there's room for everyone".

Alistair Cockburn provides the most coherent definition I have seen to date, with his work on Crystal methods, and especially the idea of properties of successful agile projects, not practices.

Most of these properties (e.g. frequent delivery) are easy to measure and to determine if your project is "in the zone" or not. Rather than asking "Do you pair program?", Cockburn asks "Do you deliver software to your users at least once every 3 months?" So a team that has a waterfall style method, but delivers every 3 months, has access to customer experts, communicates well, does automated builds and testing and so on, may still meet the criteria for success, and even agility.

Much of the debate thus far has focused around controversial practices (of XP in particular) such as pair programming and limited design documentation (which although not explicitly stated, is clearly the perception of most practicioners).

In truth, the benefits of agile approaches are easy to see, but the practices are hard to dictate. Can a project produce a lot of clear documentation and still be agile? Can you NOT pair program and still be agile? Can you not do test-first design, aggressively refactor, or have an onsite customer and be agile?

The answers will always depend on the context, the team, the leadership, and the nature of the problem being solved. Trying to codify them into practices may be an exercise in futility. To the credit of the original XP founders, they clearly state that XP is not for every project, and are fairly precise about saying that you are not doing XP if you don't follow all of the practices. However, in the current reality, many teams are practicing variations of XP and other methods with some success and some failure.

It's probably more useful to talk about the properties that an agile approach facilitates, and call any method that generates those outcomes "agile", than to try too hard to define agility as a set of practices.

Then the debate can be about whether a particular property is desirable, instead of whether a certain practice is allowed or not.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


Post a Comment

<< Home