Happy New Year!

I think we are heading in the same direction as you suggest – some sort of hybrid that keeps the agility that works (routine replanning, production-ready deliveries every 2 weeks), continue trying to get the customers to look at those deliveries, but make sure that there is enough agreed-to requirements up front to see to it that the project ends.

Oh, and of course, the line “It must be delievered by 10/31″ is NOT the requirement that ensures the project ends. :)

Your points are ‘big enough’ that I’m going to respond with an article. I’ll update the thread here when I do. In short – I’ve lived through exactly what you have, seen the same problems, and a couple others. At the end of the day, if you “can’t” get stakeholders to engage in an agile paradigm, you need to stop trying. You’re better off with a well-managed waterfall project and engaged stakeholders than you are with disconnected stakeholders regardless of methodology.

Note to the zealots – when I say “well managed” – I am happy to shamelessly steal good ideas from “agile” and apply them to any delivery model. Waterfall, while it rhymes with “throw it over the wall”, is not always the same thing.

As a developer back in 2005, I was one of the very early advocates for agile development in my organization. The concepts of “working software over comprehensive documentation” changed the way we think about requirements, very much for the better. I’ve since moved into Product Management, and normally, I would have agreed with your post.

The trouble is this – we’ve recently come under heavy fire due to a runaway project with poor business requirements definition. We had a diagram very much like your whiteboard, but as they say – “the devil’s in the details.” Every single time it looks like we’re ready to go live, there’s yet another “showstopper” issue that our lightweight documentation did not capture.

Our assumption was that we could work with the stakeholders on an iteration-by-iteration basis to clarify the up front decisions, but I’m not sure they ever really understood the power of this iterative tool. This leads me to believe that the model you lay out here can ONLY work if all stakeholders truly understand what an agile development process entails.

Our market focused development efforts have no such trouble, since the primary stakeholder is Product Management, and we know the drill. On the other hand, when the goal of a development project is to satisfy the needs of a single cusomter, it is much riskier to run the project using lightweight documentation since the customer does not know how to play the game.

Have you had trouble getting stakeholders who don’t “get it” to operate in an agile world? If you can’t get them to buy in, what do you?