The concept of iterative, incremental Product delivery is included in the Scrum guide. But did you know that the Agile Manifesto refers to incremental, iterative delivery in at least 3 of the principles? (Share your thoughts in the comments below - are there other principles or values which allude to iterative, incremental delivery?)
What is iterative, incremental delivery?
Iterative delivery means that a team delivers work frequently rather than all at once. Incremental means that they deliver it in small packets of end-to-end functionality which is usable. After all, the only thing better than a great product is a great product that gets better frequently.
Incremental delivery enables organizations to have greater visibility into what is being delivered, decreases risks faster, delivers value sooner and allows organizations to change direction faster. And yet, it seems like in situation after situation, the practice of actually delivering upon Incremental delivery well is easier said than done.
The authors of the Agile Manifesto must have seen this coming a mile away, because the concept of Incremental delivery is alluded to in at least 3 separate principles of the Agile Manifesto, which means that a full 25% of the principles included in the Agile Manifesto are restatements of the benefits of incremental delivery.
We will discuss each of these three principles below.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Unlike waterfall or other traditional project management approaches, Agile teams deliver early and continuously. Agile teams do not produce software once in one large delivery. Instead, we're delivering it frequently—or iteratively. This principle also indicates that what is delivered must be valuable, which means it must be usable, which means that what is delivered is incremental delivery, not just a cog of the machine, but a fully usable piece of functionality is delivered. Taken together, this principle is a re-statement of the definition of iterative, incremental delivery. This principle takes it a step further and also and explains WHY the frequent delivery of valuable software is necessary. It is necessary to satisfy the customer.
3. Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This principle states that product should be delivered frequently, or iteratively, and that the product should be working, which means that what is delivered is usable. In other words, this principle also is a re-statement of the definition of the concept of iterative (frequent), incremental (usable) software. This principle again takes it a step further and states that a shorter timescale is preferable.
7. Working software is the primary measure of progress.
This principle emphasizes the importance of working software, or software that is delivered incrementally. Again, what is delivered cannot just be a cog in a machine, it must be usable, or, in other words, it must be delivered incrementally. The measure of success is the working software itself.
The three principles called out above are each direct re-statements of the concepts behind and the reasons for iterative, incremental delivery. What are your thoughts? Do any of the other principles speak to iterative, incremental delivery? Share your thoughts in the comments below!
If your team is struggling with incremental delivery, discuss it at your next Sprint Retrospective and brainstorm ways that you can better embody the principle. For Product Owners looking for ways to enhance the ability of their teams to deliver value incrementally, signup for Rebel Scrum’s upcoming Professional Scrum Product Owner class.