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.

Next Appearance... sharing the stage with...

I'll be appearing on a panel on Process Discipline alongside David Anderson this coming Sunday (May 21st) at the IRMA 2006 International Conference being held this year in Washington, DC.

Although I won't be able to attend any more of the conference than the session we're in, I'm really looking forward to the discussion and the conversations that it will hopefully generate in the broader marketplace/industry.

If you're there, please say 'hi'!

Duh! Presentation I didn't include...

OK, that was lame of me.

Here is the presentation I gave at ASQ.

I guess it was well-received if speaker evaluations mean anything. The results came in at a score of 3.93 out of 5 -- which I'm told is pretty good. Like "they" say: You can't please all the people all of the time. I guess some of the lower scores reflect that people had very different expectations of what our session would be about.

Appearance and thoughts from ASQ World Conference

Earlier this week I attended ASQ's world conference. I wasn't able to enjoy much of what was offered on account of several other things going on in my work and home life, but I was able to hear the opening speaker's remarks.

David Kohler of the company bearing his name spoke on how quality "shows up" in their company and how they manifest quality as both a concept and a strategic enabler.

("quality" has many definitions, but in this entry, you'll see how it's being used without further elaboration)

What struck me most was how thoroughly this man (and supposedly their company) understood what it takes from leadership to infuse 'quality' into an organization. The level of involvement and commitment by leadership to become and sustain a company where quality isn't just a passing marketing fad was clear:

To be and sustain that kind of company takes leadership who fundamentally understands that:

Quality isn't a single measure, there are many perspectives on quality, including product, process, market, perceptions, and inwardly-oriented measure as well;

Quality doesn't only happen on the manufacturing floor, it happens in marketing, design, product and brand management, executive offices, HR;

Quality takes time to achieve, just like anything that we want to stand the test of time, quality takes time to build, time to get it right, and time to work out the kinks... and time to allow for and expect everything to be continuously revisited and changed to reflect current forces; and,

Quality take commitment, commitment to see it through and to allow it to happen even when it costs time, money, resources or delivers bad news.

Companies that don't understand or have never experienced the kind of commitment it takes to build a quality-focused organization may only ever come to understand what it takes when they truly understand exactly how their companies work. CEOs who parachute into an organization rarely have this kind of knowledge, and even more rarely take the time to get the operations under their own skin. -- Merely directing that quality be a priority without actually knowing what it takes is asking for failure. Successful CEOs will know exactly how shifts at the working level will affect quality and how that will, in turn, affect profit.

A brief conversation with one of Kohler's Quality Engineers on the exhibit floor confirmed for me that quality wasn't a marketing catch-phrase.

Also at ASQ's conference, I delivered a 30 minute talk on CMMI and Agile from the perspective of shifting how people implement quality assurance as a means of broadening the concept of "disciplined processes". It was very well received. One thoughtful question asked afterwards was about Agile methods in government contracting spaces for very large government contractors... that one, unfortunately is still an issue I've yet to fully flesh out... the complications of the way the government writes contracts as well as a host of other attributes makes Agile in the Government Space a tricky matter.
-