There are two teams. Both develop the same feature. In both cases, developing the feature takes 15 Person Days. In both cases, the feature provides the same value over time after it has been deployed.

The only difference is how long it takes them to deploy the feature to production: Team 1 needs two weeks in total, but it takes six weeks for team 2.

Which team produced a better result, financially, for their organization?

Let’s assume, for this article, that the waiting time after team 2 has finished the feature has 0 cost attached to it. This is quite unrealistic, but I don’t want to further complicate the topic here.

Uuhmm… Aren’t They the Same?

Now, the introduction to this article sounds like a silly question. Same cost, same benefit, so it should be the same result for both teams. Right?

No, because being slower is expensive on its own! Read on to learn why…

Both teams even have the same output: Both deliver four finished user stories to production at the end of each sprint. For team 1, it’s the stories they have been working on right now:

Team 2 delivers four stories to production at the end of each sprint, too, but everything happenes two weeks later.

The only difference here is the lead time - how long it takes the teams to bring a change from idea to production. Everything else is exaclty the same, for simplicity’s sake.

Now let me ask again: When both teams deliver the same features at the same cost providing the same value over time and even have the same output (four features per sprint),

Did one of them perform better, financially?

Value Earned

How much value does the feature earn for the organization? When the value earned is the same at every point in time, but team 1 deliveres two sprints earlier than team 2, team 1 has earned more value at every point in time.

But at least there comes a point where team 2 is no longer falling further behind - when they deliver the feature.

In this scenario, team 1 did perform better, even though at some point, team 2 stops falling behind.

But—and this is a big but— what if the value earned is not linear?

Then there is no point in time when team 2 stops falling behind! Team 1 does not only keep their head start, they get further ahead over time, without having to invest anything!

Note that, what I drew here is not some crazy exponential growth. The curve just raises slightly faster than linear.

In this scenario, team 1 did perform better and they keep pulling ahead as long as this feature’s value is increasing. And even if the value stops increasing in value at some point in time, we are back at the first scenario, where they keep their head start from that point on.

Ok, value earned might level out some time in the future, e.g. when the feature becomes obsolete, which would allow team 2 to catch up. But I would not bet my business on that…

So, ist it linear or non-linear? How can the value provided be non-linear?

1. The team can leverage the value they created earlier and invest it into more experiments and development that can lead to even more value created—e.g. by implementing features that make the existing features more valuable to users or the organization.
2. The feature can become more valuable on its own—e.g. by attracting more users leading to network effects which attracts even more users.
3. The team can react to feedback better. In the best case, they receive feedback hours or days after they finished working on a feature, not weeks. Their memory is still fresh, and the code has not changed yet because of other features.
4. The release date itself often matters: Before/after black friday, christmas, when a competitor releases a new version, …
5. …

To Conclude

There is a cost attached to being slow. Slower organizations earn the value generated by their software later, so they did already perform worse than the faster ones.

And if the value created over time is not linear, there is no point in time where they stop falling behind.

But that’s a cost many organizations ignore, because both teams finished “on time” (delivering 4 features per sprint) and “within budget” (spending 15 person days to complete the features).

In this post I only showed you why speed is key. There is more I could write about this topic, but that has to wait for future blog posts. In the mean time, if you have feedback or any questions, pleas contact me on Twitter or via Email

If this post reminded you of my blog post / video “Slow Down to Move Faster”, it’s because it is a related topic. This post could be both a prequel or a sequel to my earlier video.

Thank you Tim Bourguignon and Paul Lanzerstorfer for your feedback on an early draft!