Iterative, incremental delivery is critical to a successful Agile team. Without it, Agile is really just window dressing.
What is iterative, incremental delivery?
Iterative 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.
Here are five examples that illustrate the concept of iterative, incremental delivery. No example is perfect. Let me know what you think in the comments and if you have another way to explain these concepts.
The mile-long peanut butter and jelly sandwich
One way to describe iterative, incremental delivery is to imagine a team whose goal is to deliver a mine-long peanut butter and jelly sandwich.
A team using a more traditional approach like waterfall might try to deliver the sandwich in one - very large - deliverable. They might break up the job by using separate teams to focus on making the bread, jelly, peanut butter, and assembly.
A team using incremental, iterative delivery would supply the sandwich in smaller “bites.” The team would all work together to deliver each bite.
Is this a good example?
The strength of this example is that it nicely demonstrates how work is cut differently with an iterative, incremental approach. The weakness of this example is that it is impractical. When have YOU ever had to deliver a mile-long peanut butter and jelly sandwich?
A software development lifecycle perspective
Another way to discuss iterative, incremental delivery is to look at it from the software development life cycle (SDLC) perspective. The diagram below shows the SDLC for a typical waterfall approach compared to Agile product development. As you can see, Agile teams might perform all of the standard steps in the SDLC, but they might do this work in smaller pieces.
Is this a good example?
The strength of this example is that it speaks well to folks who are involved in software development. Its weakness is that this example may not translate well to teams who are not supporting a software-based product. It does not fully address the concept of incremental delivery or illustrate that the work must be fully usable and potentially releasable.
The hexagon
Another way to discuss iterative, incremental delivery is to generalize the product by depicting it as a simple hexagon. The image below shows an individual trying to deliver a hexagon in one deliverable. The second part of the image shows an individual using incremental delivery to deliver a hexagon. Each of the smaller deliveries is a complete, usable hexagon.
Is this a good example?
The strength of this example is that it is easy to understand. It clearly demonstrates the concept of delivering value in smaller pieces. It also speaks to the idea of providing end-to-end functionality (because the deliveries are small hexagons). The weakness of this example is that some individuals may not understand the message of the small hexagons being end-to-end deliveries because of how they are stacked in the image.
Web Form
I often use this explanation in my classes because it is similar to an actual product that I have worked on with an Agile team. This real-world example compares a team delivering value using an iterative, incremental approach to a team using a traditional method. The goal in this example is to produce an online application form.
Is this a good example?
The strength of this example is that it is realistic. It shows how work that solves a real business problem can be cut differently to allow iterative, incremental delivery. Because we have all used online forms at one point or another, even those not familiar with software development can understand the value of developing forms this way.
The famous car example
This is one of my favorite examples because it clearly shows how Agile frameworks deliver work differently than waterfall frameworks. In this example, the goal is to deliver transportation to the customer. In a traditional approach, the team doesn’t deliver anything to the customer until they build a car. However, using an iterative, incremental process, the customer receives value along the way to developing a car.
Is this a good example?
The strengths of this example are that it is easily understandable and really “drives” home the idea that the product the team delivers must be completely done and usable. Critics have pointed out that the product is not consistent: a skateboard is not part of the same industry as a car. Additionally, the example is not exactly realistic (although it is much more realistic than a mile-long peanut butter and jelly sandwich).
Conclusion
The concept of iterative, incremental delivery is central to an Agile team’s success, and it is one of the hardest to implement.
Simple examples are helpful for explaining complex ideas. We’ve examined five here that can be used to illustrate iterative, incremental delivery.
Do any of these examples hit the mark? Please share your thoughts in the comments below.
Work Smarter, Not Harder with "Illustrated Scrum Myths"
Cut out the bad practices that drag down value delivery.
“Illustrated Scrum Myths” is written by Mary Iqbal, organizer of Scrum Day Madison and founder of Rebel Scrum. “Illustrated Scrum Myths” is easy to read and packed with 100 thought-provoking illustrations that throw peanuts at the most harmful Scrum myths.
Don’t fall for the myths. Get more value from your Scrum team.
