3 . Idle Work vs Idle Workers
Focus on Getting the Baton Across the Finish Line
By Daniel Kemp
IDLE
- Adjective that descends from Middle English idle which means “empty.”
- Something idle is not active. If your car is idling, it is running but not moving.
- If someone calls you idle, it either means they think you do not have enough to do or that you are just plain lazy.
- Idle can also mean having no value or purpose: idle rumors are rumors that people make up when they are bored, but have no grounding in fact.
- As a verb, idle can also refer to a car engine that is running while the vehicle is not moving.
I recently read Essential Scrum by Kenneth Rubin, an excellent overview book of Scrum. One notable principle Rubin taught is to “Focus on Idle Work, Not Idle Workers.”
Traditional thinking says that if we hire someone to do a certain job description, we expect them to do such work 100% of the time. If they are not being utilized 100% of the time on a certain product/project, we can throw them on another team to ensure 100% worker utilization. This leads to better business results, right?
It may help the manager sleep at night, but it creates a bigger problem than idle workers.
Idle Work
Rubin defines idle work as work that we want to do but ca not do because something is preventing us. He uses a 4×100 meter relay to illustrate his point.
In a relay, there are lots of idle workers. Three out of the four runners are not being utilized 100%! So, let’s have them run another race (start/work on another project) while they wait.
The problem with this is that when the baton is ready to be passed, the runner is not there. He is off on some other race. “Hold on!” He shouts from the other race. “I’ll get to this as soon as I finish my leg of the race here.”
Meanwhile, the baton (our product) is sitting on the ground idle, and the competition is running by.
Within companies, this problem can scale. Employees are not being utilized 100%, so we add them to different teams, start new initiatives, etc. I recently heard a story of a consultant that helped a company with over 180 simultaneous initiatives going on, and over half did not even align with their top business objectives! The company was severely struggling to ship. The batons were merely inching around the track.
So, if we should not think about worker utilization, what should we focus on?
Focus on the Baton
An important Scrum value to remember is focus. A team (more than a group of people who do some work together) needs to remain focused on achieving their sprint goals and, ultimately, their product goal.
Focus keeps the baton moving. Leadership must remain focused on getting the baton across the finish line, not if the runners are running 100% of the time or not. The team needs to ship the increment to (in)validate their assumptions and deliver value to their users.
Removing impediments that hinder the team from delivering and ensuring teams are cross-functional should be some of leadership’s top priorities.
If teams have to wait for other teams to work on something, the solution is not to move the team that is waiting to another initiative but to ensure that the team has no dependencies / impediments so that the baton is never dropped. We do not send runners away to different races but remove the hurdles in their way.
So, focus on getting the baton across the finish line. Focus on the completion of sprint goals and, ultimately, the product goal. And more, focus on ensuring the increment is valuable and useful once it is shipped.
On Ken Rubin’s Own Words…
The largest cost in software product development is the people…which is why budget almost always equals headcount.
Everybody is interested in eliminating waste, but the issue of course, is that within organizations there are multiple forms of waste. And these types of waste typically trade off, meaning it is usually impossible to simultaneously eliminate all forms of waste.
So, what people tend to do is they go after the waste they can see. And since we said the largest cost in software product development is people, then a visible obvious form of waste would be underutilization of people. Meaning, if I hire someone to do testing and I pay them 100% salary, there is an expectation that that person is going to test 100% of the time.
So, to solve the problem, I am going to do the obvious. I am probably going to assign that person to a second project, which will lead them up 30%. Okay, I now have them at 90% utilization – but there is still a 10% underutilization – well, it worked so well for two projects, let’s try three. Okay, clever me. I have now eliminated idle tester waste. I have driven underutilization of my tester to 0. They are 100% utilized. So I have eliminated that form of waste.
Here is the problem: as we keep people that busy, chances are they are going to need to start blocking work.
As an obvious example, I have assigned that person to work on 3 separate teams. It is very likely, at any point in time, that person is blocking two teams. They are working on one of the projects and the other two are waiting. That means, the work is now idle.
So what you end up seeing is this inventory that is building up all over product development. Inventory being blocked, work sitting in queues, waiting to get done. And the problem is that blocked work, that inventory, is causing huge economic damage. And people do not focus on it because that is an invisible form of waste.
The people are still 100% busy, so it looks like the system is working at capacity. The problem is that if you examine what happens in large companies, at scale, if you look at how work flows across their organization, across the system, the collection of teams they put together to get the job done, what you often find is up to 90% of the time, the work is blocked.
IN SHORT
Many product development organizations focus more on eliminating the waste of idle workers than on the waste of idle work. For example, in traditional thinking, if I hire you to be a tester, I expect you to spend 100% of your time testing. If you spend less than 100% of your time testing, I incur waste (you are idle when you could be testing).
To avoid this problem, I will find you more testing work to do—perhaps by assigning you to multiple projects—to get your utilization up to 100%.
Unfortunately, this approach reduces one form of waste (idle-worker waste) while simultaneously increasing another form of waste (idle-work waste). And most of the time, the cost of the idle work is far greater than the cost of an idle worker.
Mature teams are acutely aware that finding the bottlenecks in the workflow and focusing efforts on eliminating them is a far more economically sensible activity than trying to keep everyone 100% busy.
What’s your experience? Have you been in a situation like the story mentioned above? Have you experienced a work culture where there was a lack of focus? Or maybe a culture that was highly focused? What was that like?
I am Daniel Kemp and these are my agile-thoughts
2021 © Cincinnati, Ohio, USA by Daniel Kemp
Daniel has years of experience leading and serving people and teams. He started his work in the non-profit world doing ministry, where he spent time helping people learn, grow, and develop. Now, he is beginning his career in the Agile community and is eager to help organizations, teams, and their customers realize the benefits of Agility.
In his free time, he loves to read, play sand volleyball, eat peanut butter, and spend time with God, his family, and his church community.
Also, I will be starting a new position very soon, so be on the lookout on LinkedIn for when that comes through.
Interesting, isn’t it?