Thank you for your comments G.L.

Software development is about creating a solution. The solution, be it the autopilot for the Airbus 380 or the subsystem that causes elevators to chime at every floor, is the objective. The methodology is a by-product of pursuing your objective. The methodology must help you meet your objective while minimizing risk, cost, and delivery time.

What I love about the Agile Manifesto is it’s a philosophy rather then a set of rigid directions. You are free, nay encouraged, to use your intelligence to achieve the project objective. This is a subtle yet important difference from BDUF1,2  which generally asks for thinking upfront by the specifications team followed by coding-by-numbers by the development team. This of course implies that developers are mutually exclusive of business analysts. This I believe is a throwback to the Revenge of the Nerds days. At the dawn of the PC, developers were not inaccurately characterized as social misfits. Appropriately we were not trusted to design system interfaces. Fortunately the expert developer has evolved on par with Moore’s law. We’ve shed our propeller caps and bandaged glasses for Hugo Boss jackets and YSL purses. But more on this later.

As you have hinted, Agile is not without its shortcomings. Paired-programming for instance excels at reducing bug count, but does nothing at ensuring the solution matches the need. Refactoring without planning opens the door to sloppy programming. Fortunately Agile doesn’t encourage these behaviours. Paired-programming is only one of 12 XP practices and all Agile disciplines promote intelligence-behind-the-keyboard. The point is these mistakes happen, regardless of the methodology, when one becomes too focused on process and loses sight of objectives. Agile disciplines are not immune. BUT, the Agile philosophy (sorry I hate the word Manifesto – I have this vision of a left-wing reactionary faction. ...You will use Agile methods or we will pluck out your letter “A” key and remove the glide pads from the bottom of your mouse…) elevates the behaviours which lead to successful outcomes.

If we look at the continuum of methodologies we have write-once-right on one end of the spectrum with iterate-and-repeat on the other end. The reality is you simply can’t write-once for any project of significance. But, you can’t go on iterating forever. Sooner or later you must freeze the specifications and move to delivery. Regardless of where your methodology lies in this continuum there is one universal: A bright project team who stay focused on the objective is a sure bet for maximizing success.

We started the other day by saying one size doesn’t fit all1,2. Today we added the axioms that (1) focus on objectives and (2) people, i.e. intelligent developers, are more import than the selection of methodology. We can now have some fun and wrap this up into a neat little analogy:

Methodology is a tool used to deliver a solution. It is a tool which when used properly can be very beneficial. Like any tool, it is only as good as the hands that hold it. It is only a tool and at the end of the day it is what you build with the tool that counts. Different jobs demand different tools.

Fortunately for me this leads nicely into another management philosophy of mine, “Situational Empathy”. The best tool in the brightest hands can undoubtedly build a beautiful rocking chair, but if the client’s vision was a Lazy Boy the end product ain’t no success. In Situational Empathy we’ll look at how to REALLY get inside the client’s mind.


------------------------------------------------------
I have mentioned the Agile Manifesto several times. Since it is really a philosophy it CAN be applied to BDUF methodologies. Regardless of how you choose to develop code I can promise you that embracing the Agile principals will improve your solutions:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Oops, the hyperlinks didn't come through in the comments of Feb 7. Here they are:

• http://www.martinfowler.com/articles/newMethodology.html#FlavorsOfAgileDevelopment
• http://www.joelonsoftware.com/articles/AardvarkSpec.html
• http://haacked.com/archive/2005/08/18/9543.aspx
• http://www.xprogramming.com/what_is_xp.htm
• http://www.stsc.hill.af.mil/crosstalk/2002/10/highsmith.html
• http://blogs.technet.com/cdnitmanagers/archive/2006/01/31/418366.aspx
• http://www.pmthink.com/2005/08/rolling-wave-scheduling-vs-bduf.htm
• http://agilemanifesto.org/
• http://www.tenstep.com/open/0.0.8.5CompareTenSteptoAgileDevelopment.htm