Imagine it’s late at night, you’re reading a book, and out of nowhere a loved one has a very serious medical emergency. You call 911, the EMTs arrive, do a quick assessment, and tell you they are taking your loved one to the ER.
As they are on the way they are calling ahead to alert the proper care specialists. The doctors, nurses and staff respond using their professional training and expert skills. You feel confident that they will do all they can.
Here’s where events could go one of two ways. I’m not talking about the outcome, I’m talking about the method of providing critical care.
Time is Value
I recently learned a new phrase: time is tissue.
The reference was to patients who had suffered a stroke, or a blood clot in the brain that is cutting off blood supply. The longer tissue is deprived of oxygen the greater the damage.
In our software development context I’m going to state: time is value. But not in the way you might think.
How you decide to invest time directly influences how quickly an individual, team, department or organization delivers value.
The Best of Intentions
I’m in the camp that believes people show up to work every day with the goal of doing the right thing. Doing the best they can given the environment. Many would call this Theory Y thinking.
When faced with the dilemma of work being slow to complete, the conventional, traditional response is to start more work sooner.
I believe that people make this decision with the best intentions, that product owners, managers and even individuals are conditioned to respond in this way. It’s the way we’ve always done things. It’s the way we can tell stakeholders and customers “don’t worry, we’re on it”.
So stakeholders, product people and management add work to people’s plates. People who are already busy and overwhelmed. Then, when even more work piles up and grinds towards a halt, the pressure to “work faster” increases.
Slack Reduces Delay
This is my favorite laptop sticker. It says so much with a simple chart and a few words. But those words are powerful and illustrate an important concept.
The higher the utilization rate, or level of busyness, the more Lead Time increases. And it doesn’t just increase, it increases exponentially.
In everyday terms, this means the busier you are the longer something new must wait (delay) before you have time (availability) to get to that new work.
We know this to be true in normal life. Even with an appointment, when you walk into a medical office and see people in the waiting room, you know you are in for a long delay. Why? Because you know it’s not just these people waiting, it’s all the other people in the small treatment rooms who the medical staff are already juggling. You only see part of the queue.
Work is no different yet we treat it differently. If your people are fully busy, all the time, all new work is delayed. There is simply no availability to address something new immediately. That new work must go to the waiting room (backlog) until there is availability.
Cue the escalation process. Rather than introducing slack into a system, because it is such a foreign concept that goes against traditional thinking, businesses would rather add process to handle this situation.
This can slow work even more because the people already fully busy doing work are now expected to also be involved with tradeoff conversations. Or to provide estimates of the new work and how long current work will be delayed. Perhaps all of that. How much worse can we make things for the people already overburdened?
Context Switching – The Silent Killer
If you are doing knowledge work of any kind I’m certain you have a concept of being “in the zone”. You’re laser focused, the thoughts are flowing and work is flying out.
Then, out of nowhere, bang! Someone says “do you have a second?”
Poof! There goes that stream of consciousness and sense of extreme effectiveness.
But, being the helpful person you are, you stop to assist. Regardless of how long the interruption lasts, you don’t immediately jump back to being “in the zone”. It takes a lot of cognitive power to get back to where you were, or even close to where you were. There is a time & energy price being paid.
The more often you switch focus, the more often this price is paid.
Switching your efforts from one item to another is known as context switching. If you are jumping from one work item to another you are context switching. If you are working on more than one work item you are paying a context switching price.
But what exactly is that price? How does it impact our efforts?
As the image here illustrates, according to this study, that price is 20% per additional context (work item). Each additional task adds a 20% overhead. As you can see, if you are trying to juggle 3 tasks, 40% of your time is being spent just switching between tasks and the cognitive loading/unloading.
That’s a big tax on productivity!
Think about Daily Scrums or Daily Kanban meetings for your teams. Are people reporting on multiple tasks they are juggling? How many tasks are they juggling? How much context switching tax are they paying? Use the graph as your guide.
How much capacity across your organization is being lost to context switching?
If your organization is struggling to keep pace with desires and expectations, do you really need additional people or can you tap into the capacity that is currently being spent context switching?
(none of this addresses other negative impacts of high work-in-progress (WIP) environments such as burnout and lack of any sense of accomplishment of finishing things.)
Unbalanced Flow
In addition to the above, trying to ensure everyone is busy all day long unbalances flow.
The easiest ways to recognize this is when a team will create separate work items for people/skills rather than as single items of value. Teams will then “pull forward” those smaller items out of the normal sequence of work. An example could be to write test cases as a separate work item.
If, during Sprint Planning, you hear something like “and we need a story for Steve or Karen”, this is happening. Unbalanced flow results when keeping everyone busy all day long is the goal.
Doing these work items piecemeal, and usually out of sequence, increases “inventory” (unfinished work) and delays integration to a single unit of value. This increases risk until the rest of the team catches up. Rework is often necessary when early assumptions prove incorrect, adding further delay.
What the Customer Experiences
In an environment where keeping every busy all the time, and attempting to serve as many customers at once as possible, our medical situation looks like this.
Imagine a surgeon who is performing an operation on a patient. After 30 minutes, in order to keep “work” moving on all patients, the surgeon moves on to the next operation they are performing.
But the surgeon doesn’t just walk over to the next OR and begin or resume that surgery. First, they must stabilize the current patient to the point the operation can be “put on hold”. Obviously this comes with increased risk.
Next, the medical staff must remove all their protective gear that was being used on the first patient. They don’t want to risk blood or other forms of contamination to the next patient.
So they scrub again for the next surgery and put on new protective gear and gloves. Only then can they move on to the next patient and start or resume their procedure. The patient may even require additional attention if their condition has degraded from the previous surgical work performed.
This is an example of the time cost and added risk of context switching.
In order to be able to tell all involved parties that “we are attending to your patient” the dance continues. Medical staff move from patient to patient before work is complete. They continually pay the context switching price.
The medical customers (patients & family) are not pleased with the results. Everything takes longer, risks continue to increase the longer work (surgeries) remain incomplete.
Sounds absurd, right?
If your team members are expected to be busy 100% of the time and work multiple items in parallel, this is exactly what is happening in your organization.
Multi-tasking? No such thing. You are paying the context switching price.
Seeing Work From Your Customer’s Perspective
Though software development is nowhere near as dire, remember the medical patient. To each patient (customer) flow of value, in this case critical care, is the primary concern. They appreciate a system where optimization of the flow of value (system) takes precedent over ensuring the medical staff are 100% busy (resource optimized).
When the goal is ensuring everyone is busy every moment of the day the focus is on increasing resource efficiency. I use the term resource when referring to people in this case because the industry does. I don’t personally like it.
The thing is, your stakeholders and customers don’t care if people are busy every minute of the day. They do care about a consistent, more predictable flow of value. They care about reasonable expectations of when things that they care about will complete. They want to be able to rely on and trust the team.
The way to get those things is to view work items from their perspective. When you do that you target increasing flow efficiency. Efforts to increase flow efficiency result in a more predictable, consistent flow of value.
Don’t be a Blood Clot
Time is tissue. Time is value. How time is invested affects flow in both environments.
A blood clot is a coagulation of blood, stopping the critical delivery of oxygen to tissue. It’s a constraint of blood flow within our bodies circulatory system.
High utilization and high WIP are constraints within our software development processes/systems. In this sense they can be thought of as value clots. Work is stuck within the system, reducing value delivery flow.
In the medical sense, responding quickly to a blood clot increases blood flow which saves tissue.
In the software development sense, lowering utilization and context switching increases the flow of value delivery. It increases customer satisfaction by improving the flow of value being delivered.
Optimize to increase the flow of value, not the level of busyness in your teams.
Until next time!
