Agile: Turning on a Dime

If you've read any of my previous posts, the title of this post might make you think my blog has been hacked and somebody else is now posting in my stead. But actually, it is just that I had an epiphany. I still have the same beliefs as before, but I realize now that my (let's be frank) negative reaction to Agile is not actually directed at Agile itself, but rather at specific individual practices.

I've done lots more reading and thinking about development methodologies and have come to the following conclusion: the key benefits of Agile development derive from the Agile practice of short iterations. In my opinion, everything else is simply an enabler. For instance, writing tests first is a good way to make sure that you keep the quality of the frequent releases high. But, as long as you are able to consistently do short iterations, it doesn't matter what you do to keep quality high as long as you do it.

So if like me you don't like the idea of using 3x5 cards to manage the contents of a release, fine. Use whatever you want. Use a text file, use Bugzilla, use RallyDev, it doesn't matter. The method you use is inconsequential as long as you are doing short iterations.

The vocabulary doesn't matter either. I don't happen to like the idea of creating new words when there are perfectly good words that mean the same thing. I prefer to talk about issues rather than stories. As long as I'm using short iterations, that's fine, the benefits remain the same.

As to the benefits, I believe that the key benefits of Agile development are: shorter time to value and accelerated maturation of product changes. I say shorter time to value rather than shorter time to market because realizing value (via revenues ) is much more important than availability of new features.

Product quality is an ongoing effort. No matter how much testing you do, users will find ways to use your product that you didn't think of. For any change, whether it is a bug fix or a new feature, you don't really know the impact until customers start using it. That means that the maturation of a change doesn't really start until the change ships. If you have a long release cycle, you will have changes that are made early that are basically "sitting on the shelf" until you ship. You can't really say that they are tested until you test the whole product as it will ship, so again, true maturation doesn't start until you ship.

An important aspect of maturation is customer feedback. By using short iterations, you get customer feedback sooner. Instead of releasing a major new feature all at once, if you break it up into logical pieces (assuming that it can be done for a particular feature), you can find out sooner which pieces are taking the feature in the right direction and which are not and adjust your plans accordingly. For example, let's say that the perfect implementation of a new feature has 12 sub-components. Of course, you can't know in advance what that perfect implementation is. Using a traditional approach, you implement the first version in a year and it includes 12 sub-components. It turns out that 6 are exactly what was desired and 6 are completely wrong (even though that's what was asked for). So, a year later you release the second version and now you've got 9 out of 12 correct... and so on.

Using small iterations, you could have released a component a month, getting feedback once a month instead of once a year. Logically, you will converge on the correct solution much faster using a tighter feedback loop.

Another way to look at short iterations is as the turning radius of an organization. The shorter the iterations, the smaller the turning radius and the greater the agility.

Of course, agility is not the only important measure of an organization. Small teams may feel that their agility gives them the ability to outperform a larger team. It seems that Agile is primarily used by small teams today and so that's probably true today up to a point. However, I see no reason to believe that Agile is just for small groups. I believe that as Agile sheds the fetters of small-scale practices such as using 3x5 cards, larger and larger projects will adopt it and enjoy its benefits.

For reference, here is the reading material that steered me in this direction (so to speak) in the order that I read them:

Integrating Agile Development in the Real World, Peter Schuh
An excellent survey of most of the Agile methods.

Extreme Programming Explained - 2nd Edition, Kent Beck
Whether you agree with the idea of 3x5 cards or not, Kent's book is a short and easy read that is well worth the effort. A seminal book on Agile development.

Lean Six Sigma, Michael L. George
I read this book because I was interested in learning more about Six Sigma. However, I selected this book because the idea of "Lean" was appealing. The way that the problem and solutions for finished product sitting on a factory floor is explained immediately suggested parallels to finished features sitting in the source repository waiting for release.

Lean Software Development, Mary Poppendieck and Tom Poppendieck
These folks have done an excellent job of taking the lessons of Lean manufacturing, pioneered by the Toyota Production System, and translating them to software development. I read "Lean Six Sigma" first and on my next trip to the book store "Lean Software Development" became an obvious choice. Reading this book was the tipping point for me.

Agile Project Management with Scrum, Ken Schwaber
If you are already familiar with Scrum, this is a treasure trove of examples of how it has been applied in the real world.