Sirens' call: Agile

I consider myself an early adopter; I am usually the first to try new things. When it comes to Agile software development, however, I have pretty much waited until it entered the mainstream. We are there now. Large, respectable companies are moving to some form of Agile. They had to. It is clear that what we have been doing hasn't led, in general, to higher quality, predictability, efficiency and effectiveness. The systems are too complex and the world is changing too quickly.

One of the reasons I didn't adopt right away, is that Agile seemed like a step in the wrong direction, for the wrong reasons. If you haven't seen the Agile Manifesto, check it out at http://www.agilemanifesto.org/principles.html.

The first principle I struggle with is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." The statement is true, and frankly, is the reason developers love Agile. Many developers I have worked with view documentation as a non-value-add activity. My aversion to this principle is that it ignores a huge problem in software development, which is keeping maintenance costs and quality under control. One of my clients had over 5 million lines of code and no idea how it worked. The people who created it had left the organization. The reasons why things had been done certain ways were lost. Adding anything which required change to the base code was a recipe for unquantifiable risk to the entire release, and many hours debugging under stressful conditions. I'm sure you developers out there will say that documentation is best buried in the code. The problem with that argument is that only developers will read it; and if I may say so, despite their technical prowess, I have seen some incredible oversights committed by developers (including myself).

The second principle I struggle with is that we should "welcome changing requirements, even late in development". It is clear that requirements do change and will change and we must adapt. But I fear that without attention to detail in requirements, people will be lazy about thinking things through, and any organization which behaves that way will waste inordinate amounts of energy refactoring.

Now that I've shown my negativity towards the principles, let me state that I think Agile brings a lot to the table. The number one thing it brings in my opinion has nothing to do with efficiency; it is risk management. In an out-of-control Agile environment, you may have the artist's problem - "it will be done when it's done, and I can't tell you when that is". Assuming you don't have that environment, then you have planned what you need and when you need it to meet your customer's requirements. Using Agile, you define mini-releases along the way to get there. Each mini release could actually solve the customer's challenge in some useful way. Now, if something ends up harder than you planned, and it will, you still have something to ship. You still have goals, you still have a sense of urgency.

My point is this: if you approach this as a potential efficiency drain to create the extra releases, but know that in return you have a ship date that you have confidence in, as well as feedback along the way about how "done" you really are, then delivering "working software frequently" is totally worth it.