Early Delivery Part 2 (from my old blog)

Early delivery has been considered the first commandment of agile.  In the principles behind the Afile Manifesto, the first paragraphs says:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Early and Continuous delivery of valuable software…  I take this to mean that we are going to structure a project (or delivery stream), such that usable software “features” are completed as frequently as possible.  The shortens the feedback loop and allows the customer to decide when sufficient value has been delivered to justify a deployment or distribution event.

Different software development situations, call for different decisions regarding deployment:

1) For a company whose primary presence is via software and/or the web, especially where the revenue is driven by the software (think yahoo or google), the frequent delivery of new or enhanced features is a way to drive customer satisfaction.  The product manager responsible for these decisions, strike a balance between new ideas, and enhancements or fixes to existing.  
2) For a more enterprise software application, used by employees of a company, the cost of deploying and retraining staff on new software features, and the criticality of correctness.  The business process change management around delivery of new software features may drive a very different roll-out cycle.
3) A software vendor, selling software to business units within an enterprise, or small businesses, may have yet another model for making decisions about deployment.  They may be driven by demands from new customers, and prospects, as well as a backlog of requests from existing customers.  
4) Software that is to be “embedded” in a physical device may have a completely different decisions cycle, and a much more rigid schedule.  The delivery of the rest of the device into which the software is to be embedded, and the revenue derived from the sales of the devices, completely determine the schedule.  In this model, partial delivery has little or minimal value.
5) Software that is deployed in industries that are heavily regulated (blood bank) or that have critical quality requirements (military/aerospace) may have much more rigid schedules that are driven by decisions made well before the development starts.  In this model, the ultra-high cost of quality assuranceand regulatory certification reduces the value of partial delivery to near zero.

It is easy to see why the value of agile principles is readily apparent to some, and a complete mystery to others.  It is the decision model that works in between need and deployment that determines the value of early or frequent delivery.  From a whole project perspective, this is clear.  But let’s look from a intraproject perspective.