Delivering Sooner by Starting Later

A counter-intuitive approach to product delivery that gains higher value generation without working any harder.

This is a transcript of a talk from the 13th of November.

I’m an Agile Coach and I have the pleasure today talking about one of the topics that I’m most passionate about. I’m going to talk about how it is possible to deliver faster, earlier and more high-quality work in product development.

But I’m not going to talk about life hacks that allow you to work faster. I want to talk about something that usually is not taken into consideration when talking about delivering great features. But before I reveal all the dirty secrets I want to get to know you better:

Who of you has ever experienced that pressure was put on him or her in order to get things done faster?

Who of you had ever had the feeling of being overwhelmed by all the work that needs to be done?

If you spend 25 minutes of your valuable time listening to me you’re going to notice five flawed assumptions associated with delivering great software products. By noticing those flaws — which unintentionally make your life harder — you are going to recognize ways to adjust your working practices slightly to gain results that will release the pressure from you and increase the speed of your team’s delivery.

Moreover, I am going to give you five kick-start tips that likely change your productivity by tomorrow — and always remember, no “working harder” needed.

Since I have only little time let’s come straight to the point:
Starting work too early is the root of all evil. How is that?

Let’s take a look at the first flawed assumption when dealing with product development work.

Flawed assumption one: Starting early means finishing early

We assume that starting early leads to early finish time. This assumption is flawed since it will only be true if we are dealing with one single work item at a time. But is this your experienced work reality?

We have more work items on our plate than just one. And everything changes as soon as we take more work items into the equation.

Since we all know by now that multitasking is a fad we might realize that as soon as we have more than one work item on our plate we start shuffling around those items. This means all those work items in the process start stealing away capacity from the other work items. Not talking about the capacity that is drained due to the shuffling itself.

Flawed assumption two: We can meet the demand if we try hard enough

The second flawed assumption is that we have a chance of meeting all the demand if we just try hard enough. I myself often wish this to be true.

However, this assumption is rooted in the physical world where the production capacity could exceed the incoming demand. This is no longer true in the realm of knowledge work since we, the knowledge worker, are inventing the work. And believe me. We always will be able to come up with more ideas than we can deliver. Not talking about all the other people around us who come up with great ideas for us to be delivered.

Flawed assumption three: We have to start immediately

The third flawed assumption is that we have to start with a lot of work immediately in order to be responsive and that we have not the right or the power to postpone the start of work.

This assumption is flawed since the people putting a demand on us and the team value delivery responsiveness more than starting responsiveness. And it is a flawed assumption since starting later does not mean delivering later.

Flawed assumption four: We have to work harder to deliver more

Graphic taken from

The fourth flawed assumption is that we have to work harder in order to deliver more. Let’s approach that assumption scientifically. In order for this assumption to be true some other assumptions have to be true as well:

  • First, working harder increases the progress of a work item.
  • Secondly, value-adding “Touch Time” must be the major part of the whole “Flow Time” for work items.

Mhh, turns out that none of those underlying assumptions is actually true in the realm of knowledge work.

Help me out quickly: Does working harder always increase the progress of a work item, say a feature?

What about the second underlying assumption. Is the “Touch Time” the major time contributor to the “Flow Time” — from start to finish a work item?

Graphic taken from

People like Agile Coaches use the term “Flow Efficiency” to express the ratio between “Touch Time” and “Flow Time”.

“Flow Time” consists of queue-time, blocked time and all sorts of “Waiting Time” plus the value adding “Touch Time”. Those people tossing around those words are also not shy of using the term “Throughput” which basically describes the amount of work that gets done in a certain period of time. This amount of work is usually expressed in a certain unit, like Euro.

Now that we know the terminology let’s come back to our fourth assumption. In most companies dealing with knowledge-work, Flow Efficiency is typically between 3–7%. So there is not much to gain when targeting the little percentage taken by Touch Time.

Graphic taken from

So simply to get the point lets make a tiny calculation:

When reducing Touch Time by 20% — which is like crazy — Throughput will increase by a mere 1%; but when reducing Wait Time by the same amount, Throughput will increase by 23%!

I told you that something else then “work harder” is doing the trick!

So, we see that Waiting Time is the real killer. Ok then, how do we address the Waiting Time? First of all, I assume, we have to make the Waiting Time visible.

What do you think, where does the Waiting Time hide? Where does a work item accumulate Waiting Time?

As I said before. Flow Efficiency is usually low. Up to 3–7% which means that work is waiting 93–97% of the whole work process time. If you take it to the extreme this time could almost be eliminated. Which would make the delivery 90% faster. Crazy right?

Flawed assumption five: People have to be busy in order to get work done

But of course, if that would be so easy, everybody would do it that way. Which leads us to the fifth pretty nasty flawed assumption.

We still believe that people have to be busy in order to get work done. That’s a tough one. We believe that people have to be busy in order to get work done.

High performing organizations, on the other hand, let workers be waiting for work, rather than work waiting for workers. Those organizations focus on emptying the queues, not on keeping the workers busy!

Why? Because most companies don’t earn their money by busy people but by sold finished goods and services. To increase the rate of finished goods you have to reduce the Waiting Time in your value delivery process. But to do that you have to increase the responsiveness of your value generating teams. This ultimately leads to the need for a drastically reduced busyness of teams and individuals.

In other words: “We do not mind if workers wait for work, but we will be hypersensitive and intolerant to any kind of multitasking and parallelism.” That’s what High performing organizations say.

In my talk announcement, I told you that you could get up to 30% more value without working harder. But that was a lie. You can get more than 200% more value. But you would not have believed me and might have skipped the talk. Pardon me!

OK. Now let’s assume we buy all those thoughts on flawed assumptions and we are eager to alter our habits to make use of those new findings. I still can promise you that this will be way harder to alter habits than it may sound.

Why? Because these new findings require saying “NO” or “Not now but maybe later”, and that is hard. It’s funny if you think about how much recognition people receive for planning and starting work and how little recognition people receive for finishing work. This overemphasizes talking about ideas and plans which basically means starting work. But I get distracted…

Why do you think this is? Why is it hard to say “NO”?

5 reasons taken from “Making Work Visible: Exposing Time Theft to Optimize Work & flow” by Dominica Degrandis

Let me add five specific reasons why it is so hard to say “NO”.

I think you have to know those reasons in order to recognize them if you trap into one of those. However, I know that addressing you directly is cheap talk. I am not going to bear the load onto you alone. Instead, I would like to give you the five tips I mentioned earlier on how you can support yourself starting work in the right amount at the right rate.

Tip one: Make starting explicit.

Make the moment of starting work as explicit as possible. A lot of teams believe that entering the backlog shall begin the work on a work item. But since this moment is not totally under the team’s control this cannot be the starting point.

Commit every work item within the team explicitly and don’t let blurry starting lines create false expectations on whether you’ve started the work or not.

Tip two: Defer commitment. Don’t accumulate unfinished work.

Defer the commitment to the latest responsible moment — the later the better. Don’t accumulate work on work items that are not needed to be worked on. I’ve seen so many Boards with loads of “planned” tickets on them. This all counts as Waiting Time which is bad, as we’ve recognized by now.

Only start work if you really have a chance of completing the work in one fell swoop.

Tip three: Finish what’s started …

Once started working on an item, we should bend over backward to get it done. Try to stick to the work item as closely as possible. Don’t get distracted. Move it to the finish line as focused as you can. Avoid multitasking and ticket switching.

Don’t start a new work item if this work item is blocked. Support removing the blocker or at least move another work item that is close to done to finish it entirely.

Tip four: … and limit work in progress.

Limit the work in progress for your whole team and not only for one particular work process column. And yes, enforce those WIP Limits. This reduces the overall Flow Time and allows support and learning across the team which makes even faster delivery possible in the near future.

Tip five: Make Waiting Times explicit.

Make Waiting Times explicit in your workflow and monitor them carefully. If you use a workflow board then you might want to introduce “waiting for” columns.

Perform retrospectives in which you analyze the tickets of the last weeks and try to figure out what increased the overall Flow Time of a ticket that has been started.

Try to remove obstacles that introduce Waiting Time into your workflow. Removing obstacles is often far more valuable than starting new work.


Limit work in process and postpone commitment, reduce Wait Times inside the actual value-adding process and improve flow efficiency without changing the work process.

This might lead to saying “NO” or “NO, maybe later” more often but you know what five reasons lead you to say “Yes” and how to build a supporting structure that makes it easier for you and your team to only take the right amount of work and increase overall Throughput without reducing quality or working harder.

Simulation Results

Unfortunately, we don’t have time to dive deep into it. However just one brief overview of how this looks like when you simulate the underlying assumptions.

On my account

Feel free to follow me on Twitter or LinkedIn to regularly receive excerpts of related content.

Deep dive sources

Präsentation online

Former Scrum, Kanban and Management Consultant | Agile Coach | TOC Enthusiast | idealo Internet | I believe that a humane global economy is possible.