Early Delivery (from my old blog)

Glen Alleman of the Herding Cats Blog in his post “Make Speed Not Haste” has once again taken an agile concept out of context.  In this case, it is about “early delivery”.  

“Instead if seeking to be early how about seeking to On Time. The planned need time. The date that the plan shows we need this item? Just having that date is not sufficient of course. The date needs to have cost and schedule margin. How much, that needs to thought through as well.
    Having worked on large complex projects with software, firmware, hardware and humans all interacting a critical question is always asked:

If we show up early can all the other elements of the project to the right of this date, be shifted to the left?

If not, it’s a waste of effort to show up early. And there is likely a downside to doing so.”

In Glen’s post, he sounds like he equates early delivery as equating to “ahead of schedule”.  This is not, in fact, what the agile community means or intends.  Agilists who talk about early delivery are describing the process of scheduling incremental delivery to expedite the most valuable, risky, or juicy features of a software product so that they can be deployed, tested, or sold, as early as possible.  The notion is that a – the shorter the timeline between business need and delivery, the less likelihood that the business will have changed out from under the requirements.  The faster we can deliver product, the faster we get paid.  The faster we get something working, the faster we can validate our design assumptions and incorporate feedback into the remaining features.

Most of all early delivery is about arranging the sequence in the schedule, not working out of sequence, or ahead of shedule. 

Not too long ago, I saw an e-book “Rocks into Gold” by Clark Ching that ties this notion of early delivery to creative solutions for the economic crisis.  

The perceived evils that the concept of early delivery is trying to address occur in projects with long timeframes between the identification if business need and the delivery of value.  The evils that can be pervasive in this context are:

1) Your product is obsolete before it is delivered – this occurs when the business need changes but your deliverable does not.  Risks around too little, too late.  

2) Your project is canceled before it is complete – market or economic conditions call for reduced spending, and the project’s doesn’t show return on investment meaningful ROI until the company is projected to be bankrupt.

3) Your product is delivered, and is not well received in the market or user community, you are then required to make many modifications that delay the delivery of additional value, and reduce the return on investment.  (Think windows vista).

No Comments

Leave a Reply