Delivering Sooner by Starting Later

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

10 min readNov 13, 2019

This blog post 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 will 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 usually not considered when 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 pressure being put on him or her to get things done faster?

Who of you 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 outstanding software products. By seeing those flaws — which unintentionally make your life harder — you will 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 will give you five kick-start tips that will likely change your productivity by tomorrow — and always remember, no “working harder” is needed.

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

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

Flawed assumption one: Starting early means finishing early

Graphic from https://leanpub.com/workflow

We assume that starting work early leads to an early finish time. This assumption is flawed since it will only be valid if we deal 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 whenever we have more than one work item on our plate, we start shuffling around those items. Work items in process steal capacity from the other work items. Moreover, capacity is wasted 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 demands 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 paradigm is no longer valid 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 to be responsive and that we do not have the right or the power to postpone the start of work.

This assumption is flawed since the people putting 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

The fourth flawed assumption is that we must work harder to deliver more. Let’s approach that assumption scientifically. For this assumption to be valid, some other assumptions have to be valid as well:

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

It turns out that none of those underlying assumptions is 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?

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 describes the amount of work done in a specific time, and this work is usually expressed in a particular unit, like Euro.

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

So to make the point, let’s make a little 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 other than “working 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 to get work done

But of course, if that were 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 to get work done. That’s a tough one. We believe that people have to be busy to get work done.

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

Why? Because most companies don’t earn their money from busy people but by selling 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.

I told you that you could get up to 30% more value without working harder in my talk announcement. 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 change 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 to 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”?

Five reasons 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”.

You have to know those reasons to recognize them if you trap in one of those. However, I know that addressing you personally is cheap talk, and I will not bear the load on you alone. Instead, I would like to give you the five tips I mentioned earlier on how you can support yourself in 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. Many 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 terrible, as we’ve recognized.

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

Tip three: Finish what’s started

Once we start 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, and move it to the finish line as focused as you can. Avoid multitasking and ticket switching.

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

Tip four: 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 Flow Time and allows support and learning across the team, making 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, 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.

Summary

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.

Consequently, this might lead to saying “NO” or “NO, maybe later” more often. Still, 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 only to 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 when you simulate the underlying assumptions.