Incremental delivery and the need for speed

Digital AI’s annual State of Agile report is a survey that has global participation from small, medium-sized and large companies. It asks questions such as what Agile frameworks are being used, and what are the biggest problems Agile teams face. But one of the most interesting questions - to me - that they ask is this: Why are you using Agile? In almost every single one of those years the number one answer has been SPEED.

But why? After all, Agile teams don’t code any faster than traditional teams.

No, Agile doesn't covey any magical powers, but the way we work in Agile is different. The difference is incremental delivery.

What is incremental delivery?

Incremental delivery means that every Sprint, the team delivers something usable and valuable — not just partial progress on isolated components, but a complete, end-to-end piece of functionality that stakeholders or customers could potentially use.

It’s the difference between waiting until everything is done before anything can be used, versus delivering working, valuable pieces early and often.

It means if you are delivering a website, maybe in your first Sprint you deliver a 'hello world' page to the test environment. If you are delivering hardware, maybe in your first Sprint you deliver a model. If you are delivering a data processing application, maybe in your first Sprint you simply pass the data through the system and display it in a report, without manipulating the data at all. No, you don't have to release any of these things to your customers, but delivering value this way will uncover issues, and will allow you to get feedback from your internal stakeholders at least.

The Skateboard-to-Car Example

One of the clearest illustrations of this idea is Henrik Kniberg’s famous car drawing.

In the traditional approach, the team focuses solely on delivering the complete car. The customer gets nothing usable until the very end.

In the Agile approach, the team delivers something usable with every increment: first a skateboard, then a scooter, bicycle, motorcycle, and eventually the full car.

The lesson is this: instead of fixating only on the final deliverable, we must continually ask, “What is the next smallest usable thing we can deliver?”

If you think about it, it makes sense because Agile teams are innovators. They are delivering something new every Sprint. And innovation in the real world happens incrementally. We didn’t jump straight from the horse to a Ferrari. The same is true for complex product development: we have to solve problems and innovate Sprint after Sprint, getting frequent feedback from stakeholders and customers so we don’t go too far down the wrong path. That's why Agile is a better fit for developing complex products than waterfall, because it is a more natural approach to this type of work.

Back to the State of Agile Report

Year after year, the # 1 reason organizations adopt Agile is always the same. Some years they call it to deliver value sooner, some years its accelerate software delivery but it always has to do with SPEED.

To satisfy the need for speed, we have to deliver value incrementally. It can be hard for newer Agile teams to do this well. It takes practice to approach our work differently. But in the end incremental delivery is the power behind the Agile throne. This is what enables Agile teams to deliver value sooner.