Does this sound familiar: Everyone is busy. In fact, everyone is productive. And yet projects just seem to take forever.
There are a lot of meaty topics we could delve into in this area, ranging from the Cost of Delay to the Theory of Constraints. But today I’d like to plant a related image in your mind: The president’s doctor.
Your doctor
But first, let’s look at what happens when you visit your own doctor. You go to book an appointment, but the next available time is only in three weeks! You wait, and arrive dutifully fifteen minutes beforehand. But when your time comes, you end up waiting some more.
Despite being three weeks after the time that you wanted to see them, you have to wait even longer because your doctor is still busy with other patients! Eventually, after what seems an eternity you actually get to see your doctor. Phew.
Your productive doctor
From your doctor’s perspective, they saw you as quickly as they could. They couldn’t possibly have seen you any sooner, they say! For the last three weeks they’ve been seeing patients, diagnosing issues, one after the other with barely a break for lunch!
They’ve been busy, nay! They’ve been productive! Every hour of every day.
And it’s true. They have been productive. But not for you.
The president’s doctor
Contrast this with the president’s experience. They need to see their doctor. “Of course Mr President, when are you available? We’ll send the doctor straight away.”
The president’s doctor isn’t busy with other patients. They sit, and wait, and maybe read a paper on The Correlation Between Presidential Tenure And Grey Hair. They do nothing but be ready for when the president needs them.
Worker vs work-unit efficiency
Yes, you guessed it, there are some thinly-veiled product development concepts hidden amongst these analogies. Let’s define some terms:
- Worker: the person doing the work (the doctor, designer, developer)
- Work-unit: the thing to be done (seeing patients, wireframes, features)
Your doctor optimises their time to be as productive as possible. They optimise for worker efficiency.
The president’s doctor optimises the president’s time. They optimise for work-unit efficiency.
Worker efficiency is king?
Almost all businesses optimise for worker-efficiency. Because the opposite is scary. The opposite means workers can be sitting, waiting, twiddling their thumbs. That’s money ticking over for nothing. The horror!
And it’s true. From a certain point of view.
But a busy worker means work-units wait. A lot. A busy doctor means most patients wait. A lot. And a busy developer, well, you know the drill.
Work-unit efficiency: the counter-intuitive saviour
If we
- know which work-unit is most important to work on
- and we always work on that
- and we continually re-prioritise so that the next work-unit is always the highest priority
- and once we start a work-unit we don’t do anything else until it’s Done
- and if the next most important work-unit isn’t ready yet, we wait
- then we maximise the value for our business.
But hey! You might be thinking: Haven’t you literally just described “Agile”? Isn’t this The Toyota Way?
And it’s true. The prevalence of Kanban and a pull-based model of work exists because it’s a great solution to the problem of “everyone is busy, but nothing is getting done. Certainly not the most important things!”
Does that make you a president’s doctor? Maybe, kind of? Sure!
Kanban to the rescue
If you’re not there already, the first, most powerful step you can take is to adopt a kanban-y process for your product development.
The board is your source of truth for all work. Any work to-do is in a single, prioritised list, with the most important work-units at the top.
When a worker is available, they pull the first work-unit from the top of the list and start working on it. When they’re done, it moves across to the next stage of the pipeline (eg. Review) which will be picked up by another worker.
A multi-stage workflow
So far, our analogies have been using a single-stage workflow. A patient sees a doctor while another patient waits to see the same doctor. Once they see the doctor, the job (task / work-unit / patient appointment) is complete. This is akin to an individual’s to-do list which takes the form: To Do > Doing > Done.
In reality, most product development processes use a multi-stage workflow. In order to get to Done, there are many steps. The usual suspects might be: Up Next > In Progress > Review > Testing > Shipped.
A worker will be responsible for an individual stage. Once they’ve completed their stage, the work-unit moves along to the next stage.
The – ideal – goal
The important thing to point out is that in an ideal process, to optimise the efficiency of each work-unit, each stage must have a dedicated worker.
Why? Because this means as soon as a work-unit reaches their stage, they are ready and waiting to serve, “thank you, Mr President!”.
A shared-worker workflow
Now consider your typical reality. You have many workers, multiple work-units being processed at once and no dedicated workers per stage.
Let’s take the simplest option: A two-worker team. Two developers, who review each other’s work, test their work and deploy their work.
Meet Chuck and Patty
Chuck and Patty work at thoughtburgers, home to the tastiest and most thought provoking burgers!
They’ve been tasked with a top secret project, the details of which have been redacted, but the implications for a shared-worker workflow remain. Let’s follow along:
- They’ve planned well and have a backlog of work to get through
- Chuck takes the first task from the top and gets started
- Patty, not to be outdone, takes the next task
- What happens when Chuck completes his task and moves it to Ready for Review?
- Well Patty is still busy with her task so she can’t review it right now
- So Chuck, not to be twiddling his thumbs on company time, starts on another task from the top of the backlog
- Now we have the highest priority task sitting in Review, waiting
- The next day Patty finishes her task and moves it to Ready for Review
- Patty is free, and being a good developer, she sees there’s already a task waiting for review so she reviews it
- Now that task is ready for testing but Chuck is focused on his new task instead. So it waits, again
- Patty’s task also waits for a review so she picks up a new task from the backlog
- Let’s pause for a moment
- Now we have 2 developers, trying to complete 4 tasks, none of which are done. The agreed highest priority task (that was originally at the top) is waiting while other work is being focused on instead
- And remember, at no point did Chuck or Patty stop to do anything other than work on the tasks for their top secret project.
This is a basic example. But multiply this by a larger team, with maybe even multiple parallel projects attempting to be juggled at the same time, and you can quickly see how work slows down!
From a task’s point of view
Let’s visualise this from the perspective of Task 1:
- It waits a little bit at the start before work commences
- Then it’s in progress
- It waits for a review
- Then it is reviewed
- Again it waits to be tested
- Then it is tested
- It waits some more while it’s ready to ship
- Finally it’s shipped!
What might task 1’s journey look like with some president’s doctors?
- Whoah!
- That’s half the time!
- And this is for a very minimal example.
- Waiting is insidious, mostly invisible, and can often represent a much larger proportion of a task’s life than active work time.
Waiting takes many forms
So far we’ve looked at a simple example, and a pretty healthy project team. Chuck and Patty were diligent; always actively working on their project. They weren’t spending the afternoon watching cat videos or doom scrolling on Reddit.
But there are many forms of waiting, and we need to be on the lookout for all of them!
Waiting in queue
A work-unit waits because another work-unit is already in progress. This is the most common and least concerning form of waiting.
To optimise this waiting we only need to do one thing: Ensure our queue of work-units are in priority order. This means whenever something waits, it waits because the current work in progress provides more value.
Waiting because blocked
A work-unit waits because it is blocked from continuing. There are many reasons why work can be blocked. Perhaps the requirements are ambiguous, maybe it needs an answer from legal, or it might be that CI is broken.
A blocked work-unit can wait, a lot. It often deceptively sits “in progress” although nothing is getting done. If you tracked the true “waiting” of each work-unit you would be horrified at how quickly a week is lost.
- Monday: Start work and make some good progress, note some ambiguities
- Tuesday: Raise ambiguities during daily sync, team agree and seek clarification from external department. Work blocked and move on to next instead
- Wednesday: It’s not even been 24 hours yet, let’s give them some more time to respond
- Thursday: Blimey, it’s been nearly 2 days, let’s give them a friendly nudge :)
- Friday: Answer received, thanks, we’ll get back to that once our current work is shipped
- Next Monday: Current work is taking longer than expected, we still need to get back to the unblocked task…
This is a contrived example. The reality is often much worse.
Waiting because “multitasking”
Doing more than one thing at the same time is impossible. I know this because I need to turn down the radio when I look at a map.
But really, when you see two or more tasks in-progress assigned to the same person, it’s a lie - a big red-faced one. What it really means is that something is waiting. It might say it’s “in progress” but it’s not. It’s sitting, waiting, twiddling its little work-unit thumbs and dreaming of a ship to take it home.
Waiting because of invisible work
The nefarious version of multitask-waiting. You know that situation where something just doesn’t seem to be progressing but you don’t know why?
You don your Deerstalker hat, magnifying glass in hand, prodding, prying, questioning until eventually lightning strikes. Elementary! It’s not moving because Chuck has been corralled by another department to work on something else, unbeknownst to the rest of the team! “It’ll be quick”, they say.
Meanwhile, our original work-unit waits “in progress”.
Multi-stage multipliers
Now that you understand the many forms of waiting, it’s important to recognise that each of these multiplies by the number of stages in your workflow. This is not a good thing. It is terrifying!
Work waits in progress, in review, in testing and to be shipped. Each type of waiting happens at each stage too.
In a shared-worker workflow, work also waits while a worker works elsewhere eg. a work-unit In progress, so worker is unavailable to pick up the Review work-unit.
Team size + 1 = waiting
The moment you have more work in progress than your team size, things wait. With Chuck and Patty, a 2-person team, everything except 2 tasks wait.
That long list of “In Progress” work you’re smelling isn’t just smoke, it’s a giant, raging fire. A fire of waiting; a fire of waste; a fire that burns the book of throughput & productivity. It’s the answer to the question: “How on earth is this not done yet!?”
Macro and micro
The fun doesn’t stop just yet. We’ve been focusing on the task level, but the same rules of waiting apply at the epic / project / initiative level too!
Are you trying to do more than one project with a single team? Why? Which one provides more value? Focus solely on doing that first. Otherwise work will wait and both projects will suffer.
2 + 2 = 4 until it doesn’t. As an example:
- Project A should take around 2 weeks
- Project B should take around 2 weeks
- That’s 4 weeks to complete them both
- But only if they’re done in sequence!
- If you try to do them at the same time, with the same team, don’t be surprised if it ends up taking 6 weeks!
It would be wrong to attribute all the extra time to bad estimation. The attempt to juggle means things wait.
Say it with me now: If you’re trying to do more than one thing at once, something is waiting. And it just might be the most important thing.
Death by a thousand waits
Remember task 1’s point of view? Consider that for projects over the span of quarters and years!
Normal project, lots of waiting
Project optimised for work-unit efficiency. No waiting
Waiting for solutions
I hope I’ve convinced you of the counterintuitive nature of worker-efficiency and the pervasive evil of waiting. Now let’s explore what to do about it!
Right to left
You’ve just shipped something? Great! Pick something new from “Up Next”, right? No! You’ve just created more work in progress.
Instead, always move from right to left. There’s a task in Testing, can I help move that along? There are tasks in Review, let’s review them. There are existing tasks In Progress, can I pair?
If the work to do “Next” is prioritised, then it follows that any work already in progress (which was originally higher up the “Next” list) is higher priority than anything else. Getting this work done sooner will provide value earlier.
Rapidly unblock
Are you blocked? More specifically, is a work-unit blocked?
Do everything you can to unblock it. Fast!
Don’t send an email and then move on to something else. That leads to our enemy: waiting. Prod and poke. Is there a workaround? Do that. Really blocked? Attack the problem until it’s cleared. Put that “Blocked” label on it and don’t stop shouting about it until it’s unblocked.
During the early development of this post I spun out a manifesto on work, waste, cost and value which goes like this:
- Before a task is shipped it provides zero value.
- Any work in progress is pure cost.
- Two tasks in progress adds cost, for no value.
- Only after shipping do you create value. Always ship.
- One task shipped is infinitely better than 4 tasks “almost done”.
- Ship something of value first. Then begin something new.
I would add one more line to it:
- Work “in progress” spends most of its time waiting. Rapidly unblock.
Radical focus
Only do one thing at a time. Do nothing but that one thing until it is done.
This applies equally at the task level and the project level. Don’t try to do more than one task at once. Don’t try to complete more than one project at the same time.
If you’re struggling with this (it’s hard, honestly), experiment with work in progress (WIP) limits. You set a limit to the amount of work that can be at any stage of a workflow at any one time. It feels weird, but go with it. It’s a forcing function for focus.
Fight the inertia of multitasking. Optimise for the work-unit, not the worker.
Small is good
Break work up into the smallest possible work-units of value.
The smaller the work, the less time it takes: to code, to review, to test, and to deploy. Reducing the size reduces the opportunity for waiting, to be blocked and allows work to be shipped faster. That’s real value in users hands sooner!
Remember, it’s never too late to split a task into multiple smaller tasks. Even if it’s already in progress. Extract some scope, reduce the size, then watch your throughput flow.
Don’t rush, just don’t wait
This isn’t a call-to-arms to ship at all costs. It does not mean we should forgo our best practices and beliefs around writing tests, reviewing code, and deploying safely. But it does mean we should actively seek, and proactively cull, any waiting that we see.
Some pragmatism required
Should you be a real president’s doctor? That means truly waiting and doing nothing until, say, your code is reviewed. It depends.
If you know that code reviews in your team typically take 2 days, then standing your ground on the purity of work-unit efficiency isn’t going to win you any favours. “Sorry, I can’t do any work, I’m optimising for work-unit efficiency!”, come on now.
But it would be well worth your while to shout about the time it takes everyone on your team to get their code reviewed. That is, how long those top priority work-units are waiting. That delay has a cost, and the cumulative effect adds up quickly.
So, what’s waiting?
Sometimes it makes sense to do nothing. Sit back, relax, feet up, have a generically-themed wafer-based chocolate. Be more president’s doctor.
But the real trick is to identify and stamp out all of the waiting that you see. Think about your work-units and their journey. Don’t. Let. Them. Wait.
