The notion of incremental delivery is an essential feature of Scrum. It comes together with the concept of Sprint. In “The Scrum Guide,” its definition reads as follows: “An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.” As logical and straightforward it might sound, it is the most overlooked and misunderstood concepts of all, and the reason why most teams are not doing Scrum (and they should not!).
This topic has been commented on and explained in many other sites, but since it keeps on coming back, I will go ahead and try to offer one more explanation with the hope of helping the ones that still need aid getting into the idea.
What is an increment
Given that “the increment must be usable,” it follows that we do not have many choices when designing and planning our next delivery. For the outside observer, an increment could be a new or updated feature, whatever adds value to the product, but technically, since it must be in “usable condition” we can no longer consider as increments any pieces of code that will not provide stand-alone functionality by themselves.
Based on the previous definition, is it possible to abstract the three properties of an increment:
1. It constitutes a fully functional unit with business value on its own.
2. It is a step forward towards the completion of the product (if “completion” is an applicable concept).
3. Its release can be omitted, its schedule advanced or delayed without affecting the actual (existing) product.
Bug fixing, code improvements, performance improvements, and libraries upgrades are entirely out of the question. By definition, they do not constitute an increment.
One more analogy: the cake
Let’s get out of software development for a moment and think about the cake analogy. Our project is a chocolate cake; we know it should look rounded, dark and delicious. But things could change; therefore we will work with “incremental delivery.” Should the requirements change, then we will inspect and adapt accordingly. Every increment must be an “eatable product.”
What do we need to do to deliver a chocolate cake?: Buy the ingredients, mixed them all, bake the cake. After that, cut into six pieces and serve to the customer. Each step is a “Sprint.”
In a traditional approach, tasks will be organized as stated above: ingredients, mix, baking, serving.
Notice three things: first, not every Sprint is delivering anything in an “eatable condition.” Second, every Sprint depends on the previous one; we cannot reshuffle, skip or postpone any step without failing to deliver the final product. And third, if you cancel (stop) the process at any Sprint except the last one, the customer gets nothing eatable. This approach is waterfall-like, and the Sprint’s schema is bringing no value whatsoever. The focus is on the sequential order, and essentially, it is delivering “parts” that may or may not bring any benefit. In our example, they do not.
Remember: “usable.” Every Sprint has to deliver a working unit that has its value, it is a step forward the completion of the product, and its release could be ignored without affecting the existing product. That alone gives us enough means to outline our next increment.
Now let’s examine the following image. I got it in Linkedin.de some years ago. It was very popular and liked by many people in the Agile community:
The upper row shows a typical example of partial delivery. Every Sprint adds a component, in the end, we get the product. Clearly, not an incremental approach.
But what about the lower row? Every Sprint delivers something better, but also a different product, so you never build on top of what you already have. Every “stage” requires starting from scratch again. It does not qualify as incremental because it does not possess any of the three properties described above. It does not make any sense at all. Maybe the author was trying to communicate the idea of growth or increase, but it just did not work. This unfortunate example is still today being referenced by many enthusiastic Agile fans, but it is a false analogy and a big source of confusion and misunderstanding.
Back to our chocolate cake, if we were to deliver it incrementally, we would have to mix the ingredients, bake and serve one slice at the time. Now we have got ourselves real increments:
1. Every slice is a fully functional unit with its business value (you can eat it!).
2. Every slice is a step forward the completion of the product (five slices to go!).
3. The fate of any single slice will not affect the final product: we could skip, delay or reshuffle the baking order and still get a sweet cake.
But although the concept is simple, it is the most challenging obstacle when developing software with Scrum and it requires overcoming an immense mental gap between paradigms. It is not just a matter of practice; our culture is shaped by the concepts of planning, anticipation, and control. Our daily lives are a constant projection to the future, and so project managers are supposed to be thinking ahead of the events all the time; software developers should write code preventing “any” situation and so on.
The practice of “incremental delivery” is in frontal opposition to these notions and it demands an immense effort to be comprehended and master.
On the technical side of the issue, increments imply higher implementation costs and technical debt. Such a delivery technique means rewriting, adapting, expanding or deleting stuff that took you already a lot of time to develop. Programmers have less time and a reduced big-picture perspective, and quality suffers. Time and effort multiply by the number of times the customer changes his mind or the market shifts course, but that is the price of uncertainty and customer-driven development. Should you have a complete, well-defined product in a stable market, in a world that does not change, then incremental deliveries are not recommended.
Last but not least, it is imperative to understand that this approach is not suitable for every product, and that is why (almost all) airplanes, cars, houses, and still many software products cannot and are not built using Scrum. As I write, many companies are forcing their ways into Scrum or Kanban, based on the old (misguiding) strategy of “divide and conquer” when in fact, incremental delivery has little or no relation to it. The impact in the business is terrible because most teams and products will not fit into the idea of “minimum viable product.” The incremental method is especially convenient for complex, ever-changing environments where you cannot or will not commit far into the future. Tangible goods, heavily law-regulated products (banking, security, etc.) and fully specified software are usually not eligible for it.
In conclusion “incremental delivery” means delivering working software on every Sprint, but it is a concept hard to grasp. It can be beneficial and productive, but like any other tool, it has limitations and conditions. It is crucial to recognize the environment in which increments thrive and the scope of the approach. If your situation is stable, with low uncertainty and the product can be thoroughly specified, incremental delivery makes no sense for you and you should not force the existing production methods to fit into it. Under any other conditions, you should seriously consider how you could benefit from it.