Are you Waiting for Work or is Work Waiting for You?
What if we could become more efficient without a lot of effort or big improvement projects? What if we could give people more space on our teams, so they are not fully busy all the time? What if both of those things were possible at the same time? Sounds too good to be true?
Read on to learn why I think this is not only possible, but not even that hard to achieve.
Waiting for a Developer…
We can turn the “item is waiting for a developer” approach into a “developer waiting for an item” one.
This statement was made by a developer during our last retrospective after we inspected the wait times in our workflow.
While it was meant as a joke, it’s exactly what we should be doing if we want to increase efficiency. Instead of keeping people busy, we rather have people waiting and make sure that the work is not waiting.
In order to do that, the first step is to be aware about where and how long work currently waits in your workflow.
What are Wait Times?
If you are not familiar yet with the measures of flow as described in the Kanban Guide, I highly recommend reading up on them. One of those four measures is Cycle Time, which the guide describes as follows:
Cycle Time: The amount of elapsed time between when a work item started and when a work item finished.
So it’s the “total time” that an item was in progress. This total can be split into two different amounts of elapsed times: Work Time and Wait Time.
Work Time is the time when there is active work being done on an item. That might be someone clarifying the scope of the item, a group of developers writing code for it, some documentation that is updated in the scope of it, or whatever else is part of your workflow that needs to be done so that the work can be considered done.
Wait Time is the time in which the item is in progress, but nobody is actively working on it. So the time when we
- Waited for someone to clarify the scope
- Waited for a developer to start writing code for it
- Waited for someone to get started with the documentation
About Efficiency
Wikipedia describes efficiency as follows:
Efficiency is the often measurable ability to avoid wasting materials, energy, efforts, money, and time while performing a task
When our work item is waiting, we are wasting time, and that’s not efficient. Instead of “throwing more people on the problem” or thinking about tooling, a rather simple way of optimizing your efficiency is to reduce wait times.
Note: You will most likely not manage to prevent items from ever waiting in your process. But, especially when you get started looking at them, there might be long wait times that can be reduced by rather simple actions.
According to the Kanban Guide, “Kanban is a strategy for optimizing the flow of value through a process”. When work is waiting for someone to work on it, that is the opposite of optimized. Instead, the focus is often in making sure people are busy. It’s seen as waste if people would be “idle”.
Many teams and organizations favor a higher work in progress over actually finishing things. People need to be occupied with work. Work is waiting for people, so they never are “out of something to do”.
In order to reduce wait times, this has to change. People have to wait for work instead. That way we can reduce the wait time of a work item and it will be closed faster.
To be honest with you, this felt like a strange concept for me at first. It’s simply not what we’re used to doing. Then again, “we’ve always done it like that” is not a valid reason to keep doing things the same way.
Embrace “High-Availability”
In our retrospective, someone came up with a nice term for this approach. While “idle” suggests that people might be doing whatever, they should be doing something that they can interrupt right away and support others to make the work flow. They become “highly available” to support others.
It’s not simply the label that changes from “idle” to “highly available”. It influences my attitude. Being highly available to support others gives my work more value. In comparison, being idle sounds like I’m not adding anything
— Developer on the team when discussing the term “highly available”
They can clean up that part of the code that is a bit messy. Or Improve some unit tests. Maybe read a book on test automation, write a blog post about wait times, watch a video about the latest front-end framework, or listen to a podcast.
Speaking of Podcasts, Philip Ledgerwood has a nice episode about the same topic and I recommend you to listen to it when you’re ̶i̶d̶l̶e̶ highly available the next time:
The important part is, that whatever they are doing, they can stop right away and refocus on work that is waiting for people.
So if you have to sell the concept to your manager or stakeholders, maybe use “high-availability” over “idle”.
Measuring Wait Times
Before you can improve your wait times, you should know what your baseline is and where you currently spend your time.
What you might already be doing is to measure your Cycle Time. This contains your wait time, but it does not tell you whether you the item spent most of it’s time being worked on or waiting. For example, you might have an item that has a Cycle Time of 10 days, but it doesn’t tell you if it the time it waited was 1 day or 8 days.
You should see a drop in Cycle Time once your items spend less time waiting, but to analyze it, it’s not the right metric.
When you have a well-defined workflow, the chances are that you have various stages (aka “columns”) on a board. If that’s the case, you can measure how long each item spends in a specific column and visualize this:
Note: We’re using Azure DevOps and rely on FlowViz by Nicolas Brown for visualizing Wait Times among other things.
In the above example, you can see that most time is spent on “Implementation in Progress”. While that seems reasonable, the second highest bar is the one in “Waiting for Verification”. That smells like a lot of potential for improvement.
Column Names
You might have noticed that we use the following pattern for our columns:
- Waiting for X
- X in Progress
This idea is taken from Steve Tendon’s Book “The Book of TameFlow: Theory of Constraints Applied to Knowledge-Work Management”.
Another option often used is to split the column into Doing and Done:
- X / Doing
- X / Done
One of the main downsides with this approach is that X / Done does not indicate as clearly that the item is waiting. It’s done which seems good. With the Waiting for X, it’s more obvious that it’s currently not actively being worked on and we’re wasting time. When it’s waiting, it’s a better indication that we should become active.
I recommend reading Steve’s book to learn more.
Improving Wait Times
Back to our retrospective where the developers mentioned that people should wait for work rather than work waiting for people. When we looked at our wait times, we saw that items often spend a lot of time waiting. Instead of trusting your gut feeling, having actual data allows for a much better inspection. You can have better discussions with the team if you see just how much things are waiting, as well as when you see where it is waiting.
The actions you take of course depend highly on your context. In our example, we’ve identified various problems:
- It’s not always known to the team that something is in fact waiting for verification
- It’s not always clear who can verify (what skill level is needed for an item).
- Not all team members have access to test environments and thus cannot support well with the verification
All of those things are things that are not necessarily hard to solve, and we could start addressing them right away.
Impact
We agreed that we notify each other every time any item is moved in a Waiting For column. That has helped us trigger a discussion right away about who can look into this. What might have gone unnoticed before until the next daily is now made transparent right away.
As we have the data, we can easily inspect if the changes had the desired effect. Ten days after our retrospective, the wait time has reduced by almost 50% already. We also saw the cycle time overall decrease. Of course, 10 days is not a big sample size and we should keep inspecting it. But it sure looks like a good efficiency improvement for some simple actions.
Conclusion
“We don’t want to be more efficient” — I never heard anyone say that so far in a work environment. However, you might have heard that people need to be busy or prevented from being idle. Or experienced that people are just busy all the time, not having time to support others.
I hope you’ve seen that having people busy always is a path that can lead to inefficiency. Instead, focus on the work moving through the system, and measure where it is waiting around without being actively worked. Teach our team about the fact that it’s better to be “highly available” and prevent wait times and focus on where it currently waits most.
Special thanks to Grzegorz Barczyk for the inspiration and Peter Zylka-Greger, Matt DiBerardino, and Florin Manolescu for reviewing the post! 🍻
