Agile also means fall early and get up

I was discussing the notion, the other day, that a defect in design may be expensive, but a defect in the fundamental assumptions of a project can be catastrophic.  In other words, if you are doing the thing wrong, you can fix it, but if you are doing the wrong thing, you get to start over.

So when, in a meeting on Enterprise Architecture, the speaker asked the audience if anyone has ever delivered a project only to find, a short time later, that it failed, I was not surprised when a good percentage of folks raised their hands.  We've all been on projects where we thought we were doing the right thing, and doing it well, only to find out after delivery that we had screwed up.

One thing that did surprise me, though, was one gentleman who mentioned that he had been on a project that delivered, and he didn't find out for six months that the project had failed... not because he was "out of the loop" or took a very long vacation, but because the customer didn't know that the project was a failure for that long.

That is scary.

It occurs to me that I haven't seen anything like that on agile projects.  The hallmark of an agile project is that you stop, OFTEN, and show the results to the customer.  Not the marketing person.  Not the project manager... the customer.  You get feedback.  And you make changes.  Change is embraced, not avoided.

So, if you are doing the wrong thing, it should be obvious early.  In fact, it could become obvious so early that the team hasn't spent the lion's share of the original funds yet... still time enough to fix something and get back on track.  This is Great!  If you are going to waste money, find out early and stop.  Then, reorient the investment.  It is far worse to develop the entirely wrong application than it is to develop what you can of a good one. 

That doesn't happen with waterfall projects.  On the other hand, the waterfall project has the advantage of delivering the wrong thing.  Teams get rewarded on the quality of the delivery, not the alignment between the delivery and the actual needs.  Developers get gifts and good marks for "getting it done right" but not for "getting the right thing done".  That won't be discovered until later, and then the dev team will deflect the blame to the analysts who collected the requirements.

And this works against the Agile methods.  Even though Agile methods spend money better, they don't get to that end-date when everyone throws up their hands for joy and says "We Got It Done."  They don't get the prize at the end that people crave: the promotion out of waterfall h_ll.  The right to go home on time.  The plasticine trophy for the windowsill.

So if you want to know why agile methods aren't fostered more often, or more closely, look no further than the "ship party" that roundly celebrates the delivery of a dead horse. 

To this end, I propose a new practice for agilists: the kill party... where everyone celebrates when a bad idea is killed before it consumes buckets of shareholder's cash.

Comments

• Anonymous
  July 25, 2005
  The comment has been removed
• Anonymous
  July 25, 2005
  The comment has been removed
• Anonymous
  July 29, 2005
  Great and funny thoughts!
  Let's all make a few big killer parties!