22 May 2006

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.

7 Comments:

At 26 May, 2006 09:31 , Anonymous Anonymous said...

Actually the title should be "Continuous Planning vs. Plan-Driven" as agile is not a rejection of planning, but a means to do ongoing planning.

In my limitted experience, I have found that agile development spends more time with more people on planning. In plan-driven approaches, the time spent and people available is usually restricted. In a government contract arena, a proposal often is completed in 1 week, with the proposed plan often done by 1 person over a couple of days with much the effort concerned with the format. In other types of work, the plan is usually written by the project manager in the first 1 - 2 weeks of the project. Though proponents say that the plan should be updated, I have never seen it happen.

One of the shocks when doing agile development is the amount of planning involved. It is often difficult to convince the customer to commit time and people to the endeavor and once committed, to truly address scope, cost, and schedule trade-offs. Too many want to play Jon-Luc Picard, sit back and say "Make it so", and expect a solution on the doorstep in 6 - 12 months.

Decomposing a task into a series of valuable iterations is hard work. The benefit, though, is a far more "scientific" means of tracking progress than using a 500 line GANTT chart with highly subjective WBS completion criteria. Agile development is not a rejection of planning, rather, it is an approach that actually addresses many of the academic planning issues discussed in sources such as the PMI PMBOK.

P.S. Thanks for the kind words about D.C. I have also spent my career working both in downtown D.C. and Northern Va.

 
At 28 May, 2006 04:22 , Blogger Hillel said...

THANKS SO MUCH for this comment, Wayne!
I absolutely agree that what's different about planning in Agile vs. "other" approaches is the abstraction of what is a plan and what is planned. In fact, one comment made (by David A.) at the panel was that the concept of what constitutes a "project" is what changes when "traditional" development managers switch to an "Agile" paradigm.

In sum, you are describing exactly the battles I fight with PMBoK slaves when trying to help them see that Agile appoaches do everything they're expecting to see, only they do it *a lot more* often and keep doing it from "big picture" down to "tiny details"... with many more of the right people involved -- right there. So taking a lot of time to get it "right" on paper is seldom time well spent. (Which doesn't change the FAR or those enslaved to it.)

 
At 30 May, 2006 11:37 , Anonymous Anonymous said...

The criticism that agile methods are not based on science is a common one, and it always strikes me as funny, in a way. Maybe not "ha-ha" funny, but instructive about people's assumptions and values.

What is the science behind traditional methods? The Chaos Report, among other analyses, strongly suggests there has been something very, very wrong with IT methods for many, many years. Doesn't sound very inspiring to me.

Anecdotally, I've received comments from satisfied customers of agile projects in the last 3 years that I could never have imagined in the preceding 25 years of using traditional methods. At the conclusion of his project, one customer said that he had been working with IT departments on projects for 32 years, and this (agile) was the first methodology he had seen that had actually worked. Ever.

When I run the numbers on the projects we've completed at our company, the financial results from the agile projects speak for themselves. We've consistently delivered an average of 9 times the ROI of our traditional IT group. That's not a scientific study. It's just a fact. It's really hard to counter that sort of information with academic studies and management "science."

Funny.

 
At 30 May, 2006 16:09 , Blogger Hillel said...

Yeah, I 'bout fell out of my seat when he said agile methods lack the "scientific" backing... I was thinking that "traditional" development has plenty of "scientific" evidence that it doesn't always work!

 
At 28 June, 2006 22:07 , Blogger Scott W, Ambler said...

A couple of comments:
1. Wayne is absolutely right, with agile approaches you do far more planning. The main difference is that you do it just in time, and that the people doing the work are the ones doing the planning.
2. In the traditional world there are some good project managers, but they're few and far between. Most traditional project managers, particularly the PMP crowd, are often oblivious to the incredible amount of waste inherent in their approaches. A couple of weeks ago I ran into a lady who was struggling with the agile approach, and it mostly had to do with planning. She wanted to plan everything up front because she was convinced that this was the way to go. So I asked her when she did this detailed planning, what happened during the project. It seems that the developers would do the right thing regardless of what was in the plan, tell her what they actually did, and then she would update the plan accordingly to reflect the actuals. She thought this was a good idea (and to be fair, honestly reporting actuals is a good idea) but what she couldn't see was the inherent waste in her approach. I suggested that she just do high-level planning to identify major dependencies, and then do detailed planning with the developers just in time. That way the plan would be accurate and she would need to fool around updating the schedule with actuals later on. Sadly, she couldn't comprehend how this would work.
3. The "scientific proof" argument is invariably nonsense. When you look at the so-called proof you often see that the assumptions made by the studies are naive at best, or that the proof is out of context (e.g. they assume a serial, low-collaborative environment staffed by hamburger flippers). Instead of throwing useless paperwork at the problem perhaps it would be better to simply not make those mistakes to begin with.

- Scott
http://www.ambysoft.com/scottAmbler.html

 
At 31 August, 2006 06:34 , Anonymous Anonymous said...

Very interesting discussion., I have linked this post to http://projectized.com
Agile vs Plan Driven section

 
At 23 April, 2007 15:57 , Blogger Ross said...

Wayne,

I'm not sure I agree that agile development projects do more planning than plan-driven projects. I have seen literally YEARS of planning go into a plan-driven project, without any output produced. There are some plan-driven projects that have had too little planning and some that have had too much.

The valid point is that the planning is different between the two approaches. The agile approach allows the planning to occur upfront to set goals and a broad outline, and then we also plan continuously based upon what we learn in the process. The plan-driven approach views this learning as an uncomfortable occurrence and only reluctantly modifies plans to accommodate what was "missed".

 

Post a Comment

Subscribe to Post Comments [Atom]

<< Home