No Really, What is Agile?

[Note: updated on 1/9/08 to take some of the comments into account.]

You may not like my definition of Agile. That's fine with me. I don't like it either! I'm much more interested in discussing what Agile brings to the table than trying to nail down an exact definition. Sometimes I think that it may be pointless to define Agile development. It may be better to just talk about the concepts and the practices and say "these things are worth learning about regardless of what you call it or how you define the overarching concept." I still think it is worth a shot so as to establish a starting point for discussion. So, let's discuss the definition of Agile a bit and then move on to the nitty-gritty.

Giving a concise definition of Agile is far from easy, probably because Agile is actually an umbrella for a wide variety of methodologies. Some will say that "it isn't about methodologies, it is a philosophy." Philosophies are a fine place to start, but at the end of the day you have to get down to brass tacks in order to actually bring about change. Personally, I'm not particularly interested in going around in semantic circles.

And then on the other hand there are folks that are tired of the endless semi-mystical descriptions of Agile and quickly turn away. That's a shame, because there really is something new, different, and of significant benefit to software development to be found in Agile. I've experienced both sides of this.

Because there are so many practices associated with Agile development, I prefer to define Agile in terms of benefits. It is not a perfect way to do it, but for now it is the best way that I know how to do it.

I also define Agile in terms of traditional development because there would be no point in doing Agile development unless it was better! I consider waterfall to be part of traditional development, but I use the phrase "traditional development" instead of waterfall because there are many shops which would say "we're not doing Agile, but we're not waterfall either."

Unfortunately, while Agile has the potential for producing better software, it seems that for many shops getting to the benefits of Agile has been an elusive goal. But, having experienced those benefits firsthand (see Jolt Award posting) I know that it is a goal both worthy and attainable.

In comparison to "traditional development ", Agile provides the benefits of "More flexibility/options, Higher ROI, Faster realization of that ROI, Higher quality, and Higher visibility."

More Flexibility/Options
The sort of flexibility that is meant here is the flexibility gained by having short iterations where "short" means 30 days or less and at the end of that iteration you have software which is shippable. When that is true it means you can now work on whatever makes sense at the end of the iteration. With traditional development the software may look like a construction site: some parts are done, others are not, but the building is not currently usable at all. Changing plans would mean ripping out work in progress and possibly work that is done but depends on other work that is not done.

Higher ROI
Because you have more flexibility you can change your plans to take into account the current market conditions instead of what seemed like a good idea when you started working on the release. So, if traditional development would have released after 6 months and had features A, B, and C which had an ROI of 9 during planning at release has an ROI of 7, Agile might produce A, B, and D in the same timeframe which has an ROI of 11. The idea is that while C looked like a good idea at the beginning it turned out later to be worth less than expected and D came along which had much more ROI so we did that instead.

Faster Realization of that ROI
Since you can decide to ship at the end of any iteration you can start realizing that ROI whenever you like.

Higher Quality
In a traditional project, the elapsed time from start to finish from the perspective of any individual work item is very long. There is no consistent process applied to each and every work item. Instead, work items are fused together into “the release” and the quality of “the release” is measured. One consequence of this is that QA gets a big dump of functionality near the end of a release and has to figure out how to best use the time remaining which is often less than originally planned. That means taking shortcuts and the "most important" new features get very thorough testing and the rest get a "spot check." Another problem with traditional projects is that since much of the test writing and execution is left to the end, problems hide out for long periods of time and thus there is a long time between introduction of a problem and the detection and fixing of that problem.

In an Agile project, the elapsed time from start to finish from the perspective of any individual work item is very short. Test plans and automated tests are created throughout the project and each work item is given the amount of QA resources that is appropriate for it. Because problems are found and fixed faster, there is less chance of the quality of a project being poor for long stretches of time. Code is written on a stable base and is more likely to be stable itself because there will be accurate and timely feedback on the results of the changes.

Higher Visibility
Instead of the classic "we're still on target" all the way up to the end of the release, you know at the end of every iteration exactly where you are because the work is either completely done or it is not. You have monthly or even weekly feedback about what really works.

Next: Primary vs. Secondary Benefits of Agile Development