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.
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.