5 Initiation ↑

No. 38 — Deliver Early and Often

The first Principle behind the Agile Manifesto states:

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

In order to deliver early and often, it is good to familiarize yourself and your team with the following closely related concepts:

• Minimal Marketable Feature (MMF): this is the smallest piece of deliverable functionality that can supply additional value to your customers.

• Minimal Marketable Release (MMR): the smallest new release of your product that your customer will consider worth delivering.

• Minimal Marketable Product (MMP): the smallest initial release of a new product that your customer will consider worth delivering.

Delivering early and often tends to produce all of the following benefits:

1. The development team can gain valuable learnings about product and process by getting more timely and regular feedback from actual usage of working software in the field. This is one example of shortening a feedback loop.

2. By delivering working software sooner, and delivering more often, customers receive increased value through earlier and longer enjoyment of the benefits delivered by the software.

3. Another way of looking at this idea is through the lean concept of inventory as a form of waste. The more money we invest in software before delivering it to our customers, the more “inventory” we accumulate on the shelves of our “software warehouse,” and inventory is a form of waste because it consumes resources without delivery of any value.

4. Short, rapid delivery cycles also breed an atmosphere of trust between you and your customers, and such trust tends to make other aspects of your effort easier and more productive.

5. Such delivery cycles also help with feature prioritization. With long delivery cycles, customers tend to say that everything is top priority, for fear that anything lower on the list will be relegated to a later phase of the project that will never happen. Once customers get used to shorter delivery cycles, though, they become much more open and transparent about identifying which features are really most important. And, of course, by delivering the most important features early, you maximize the length of time your customers can enjoy the benefits that will derive from them.

6. When you shorten delivery cycles, you reduce the size of the batches of work traveling through your development value stream, and smaller batches reduce management overhead, and can be more reliably estimated and delivered.

7. Short, regular delivery cycles tend to highlight problems inhibiting the rapid and easy flow of work through the value stream, and encourage improvements to the way that the work is done. Conversely, long delivery cycles offer plentiful opportunities to hide problems for long periods, and to allow people and processes to work around problems, rather than addressing them.

8. If you also deliver software according to a regular cadence, in sprints of a fixed duration, then your teams will find that many aspects of working together become easier, since team members will all form regular habits based on these sprint durations, and will start to instinctively know what they should be doing when they are at a certain point in each sprint.

It’s useful to consider the total cycle time required for your team to deliver a new feature to your customers. As Mary and Tom Poppendieck state, think of this is as the total duration required “from concept to cash” – in other words, from the date of the inception of the original feature request to the date of delivery of the working software into the hands of your customers, ready for their use. This is one of the more useful metrics for your team to track, since shorter cycle times tend to deliver so many benefits.

Words from Others on this Topic

Next: Execution