Agile vs. Plan-Driven Panel Discussion

The IRMA conference was thus far the most "academic" engagement I've spoken in front of.  (Not that I've done so many speaking engagements, mind you.)

The format had each panelist give a 10-15 minute pitch on their position and then take a question or two from the audience.  After that, the moderator tossed in a question, a few more questions from the audience and then a wrap-up.  The "academic" aspect was reflected in a few ways: the organization of the event, the timing, and of course who came.  I hope David Anderson blogs about his early morning networking experience.

But what one really should consider is the context in which our panel session was conducted.  The panel was held on a SUNDAY at 1300h (1pm).  Outside, the weather was spectacular.  Say what you want about Washington, DC, but in good weather (and also after a good solid snow fall), there are fewer cities that have the attraction that pulls you out of your homes and onto the streets, promenades, and squares.  In many parts, DC is a city where it's nice to just walk around with no destination in mind.

So you can imagine what conference attendees would rather do given the choice to sit in a small hotel meeting room or go out exploring.

Including the moderator, we were very happy that the five-member panel was out-numbered by more than 3:1.  At first we thought we wouldn't break parity!

So... what about the topic?

Needless to say, there were existing opinions (both on the panel and in the audience) on where, how, and whether Agile and Plan-driven software development have their place and compatibilities.

David Anderson spoke about trust as a leading component of agile and productive software development. 

Jonathan Adelston of UpStart Systems gave a few examples of successful and large development efforts that would have been considered "agile".  Although on many points we would agree, he wasn't a fan (or didn't fully grok, or simply misunderstood) the idea of incremental development, saying that partially completed software is missing important features such as security or error-handling.  He also expressed the opinion that much of the Agile content is intended to spur discussion and that when faced with actual customer expectations, Agilists are open to backing off their otherwise staunch position on process.

[FWIW, here's an example of how software can be functional even if missing functions: a program that's supposed to be a simple 4-function calculator that is delivered with only addition and subtraction operational will work with only those functions. If you need a userID and password to get into the program, that piece ought to be there regardless of whether the multiplication and division functions have been delivered.]

Dr. Lars Mathiassen currently with Georgia State University presented a theoretical analysis of a particular organization's effort to balance "responsiveness" and "robustness" in development. Although he worked with and said he's very friendly with Alistair Cockburn, he argued that "plan-driven" development had a basis in science, study, and methodology whereas Agile's was grass-roots and lacked the "science" to back-up the claims. No suprise, although he saw definite validity to the faults found with too much reliance on planning and process, he, too, seemed to believe the implication of Agile approaches was to not have the rigor needed to be repeatable.  He pointed to a work done in 1999 by Stephan Haeckel, Adaptive Enterprise: Creating and Leading Sense-And-Respond Organizations which I've now ordered, in which Mr. Haeckel outlines an approach to add rigor to agility.

The audience was a mix of practitioners, consultants, and academics.  Heavy on the academic side.  I was also under the impression that some of the consultants were professors taking consulting opportunities because of their field of research.

Without attempting to reproduce the conversation, I think a quick summary of the discussion would be that there is a time and place for Agile and for Plan-Driven approaches alike.  In many ways, they can occupy the same time and place, however, one must understand the goals and needs of the project and the stakeholders, one must understand what constitutes the "project" and one cannot throw any type of process (agile, plan-driven or otherwise) at a development effort and expect it to succeed without taking the time to understand how work actually gets done.