This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: How do you know if your project is Agile?
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
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. 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 will some success and some failure.
It's probably more useful to talk about the properties that an agile approach produces, 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.
Previous Topic
