Jack Be Agile ... But Not Too Quick

To be agile or not to be agile? Despite the great debate, I don't think that's the question. Who wouldn't want to be agile—especially when you consider that the opposite of agile is awkward, oafish, ponderous, stiff, or torpid? The real question is how best to build products that provide sufficient business value to their various stakeholders. Agile methodologies incorporate different strategies than traditional approaches, and we can have endless debates about each of their merits and shortcomings. They’re all heading in the same direction, though: choosing an appropriate set of practices, tools, and methods to help each project maximize the business value it delivers (and, with any luck, have fun along the way).

But before you jump onto the Agile bandwagon, ask yourself three questions:

1. What does success mean on this project?
2. What's currently standing between us and this success?
3. Is Agile the best approach for this project?

How Do You Spell Success?
Begin by understanding the balance of functionality, quality, delivery time, development cost, and lifetime cost that will provide the optimum business value. It doesn't matter if you deliver a product on time and on budget if the customers hate it. It doesn't matter if you deliver an increment of working functionality every two weeks if your users can't take advantage of that functionality. I once was involved with a project to replace a heavily used legacy application. An incremental release strategy was inappropriate in this case because the new system required a critical mass of capability before users could cut over to it. If we had delivered ten percent of the ultimate functionality within one month, it would have sat idle because our users would have had to use both the old and the new systems to get their job done.

What's Standing in Our Way?
Before you conclude that Agile is the answer, ask yourself why your project teams are not presently able to achieve the desired business objectives. I'm a fan of root cause analysis, a simple process of asking "Why?" enough times to get at the underlying causes of some problem. Agile methodologies include some sound practices, but you need to make sure those practices will indeed address your current barriers to improved performance. I find it irritating that some Agile advocates try to sell a better mousetrap by essentially telling me how stupid I am to keep using my old mousetrap. You should examine what problems Agile will solve so you can see the value of adopting these methods in your situation—or not.

Is Agile Right for This Project?
Each project has specific development and project management practices that will best suit its objectives, constraints, culture, and environment. It is naïve to assume that any single software development strategy will work in every situation. And it's fool hardy to discard approaches that work well in some situations as being useless in all.

For instance, pair programming works great with some teams but could be a disaster with others. Having an onsite customer is a great idea, but how are you going to pull this off in a team where analysts and developers are not permitted to talk directly to their customers? Or where the product has five user classes and no single individual can make decisions on behalf of them all? Or where the assigned customer representative lacks the knowledge, time, or inclination to do the job? A colleague once told me, "One [customer representative] sat in our midst and still managed to avoid us all."

Stop Debating. Start Delivering.
The goal of software process improvement is to reduce the cost of