When first meeting with a team, or team of teams, it’s exciting to dig into their environment and make sense of what is happening. After a short period of observation, it’s very common to make recommendations which will include at least some intrusive type change.
What if, as a first step, there is an easier way to increase the flow of value?
Intrusive Change
I admit to being someone who, when first working with a team, will be seduced by more sweeping change. Making a big impact.
Some examples:
- if I find a high level of dependencies often a recommendation is to re-organize teams.
- another common recommendation is to rework the process flow. Examining and redefining things like work item types, workflow states and policies such as Definition of Done.
- I believe self-organizing teams naturally “break-down” the skills silos within teams, doing what is necessary to complete the work regardless of title. Yet, very often, management requests an examination of existing roles and responsibilities.
Often such change recommendations are met with resistance. The changes are seen as overreaching or too intrusive.
Some change recommendations can cause people to feel threatened. People often feel a sense of worth based on their profession and ways of working. Larger changes, such as redefining roles or workflow, can be received as condemnation of what they, or the team, have been doing.
Determining Work In Progress (WIP)
Work-In-Progress, or WIP, are the work items “in flight”. They are the work items that are between not yet started and done (as defined by this team). Different teams, and teams of teams, will have different workflows and definitions of when work is done from their perspective. For example, in a software development team done may mean “released to production” for one team and “ready for release” for another team.

To determine WIP simply count the number of work items between these two states – not yet started (To Do) and Done. In this image, the WIP count is 5. There are three items In Progress and two items in Testing.
Effects of High WIP
People intuitively understand the effects of high WIP. We experience it often. A busy highway, long checkout lines at the grocery store, a maxed CPU on your computer slowing everything down are a few common examples. Our brains are no different.
Nearly every team, group of teams, program and even at the organization level, I encounter has a lot going on. All the time. There is a relentless push to go faster, to “do more with less” and similar strategies to get more and more out of people.
In such situations it’s common for people and teams to take on more than is possible. To try to juggle multiple efforts at once. To become better at “multi-tasking”.
For many years people believed they were great at multi-tasking, or doing more than one thing at a time. Many still believe this, it’s on a lot of resumes and LinkedIn profiles. Yet recent science indicates that people are not capable of “multi-tasking”. The brain actually shuts off one item while it services another, then switches back. As much as you think you’re doing more than one thing effectively at a time you are not.
“multitasking may seem efficient on the surface but may actually take more time in the end and involve more error. Meyer has said that even brief mental blocks created by shifting between tasks can cost as much as 40 percent of someone’s productive time.”
American Psychological Association
For the full article click here.
In order for your brain to service multiple items, it performs what is commonly known as “context switching”. The “context”, or knowledge, skills, effort, etc of one item are set aside and a new “context” is loaded into your brain to service the next task or effort. This repeats continuously.

Other research into context switching indicate that for every additional task/project you are working on, a time loss of 20% occurs. That means that if you are working on 2 things, 20% of your time is spent context switching, not adding value. It gets worse the more you attempt to juggle. At 3 projects the time loss is 40%. More than 3 projects? More than half your time is spent simply switching between efforts. That is a huge hit against value delivery.
It’s All About Flow
Back when I was a kid we used to play with the water hose in the summer to cool off. Since we didn’t have a pool we would spray each other or run through a sprinkler. Simply holding out a hose and pointing it at someone didn’t work very well. I didn’t know it at the time but we were experiencing the Bernoulli Principle.
Very simply, by putting my thumb over the end of the hose I was constricting the flow of water, thus causing it to move faster, and with more pressure, to escape the hose. See the header image for this post and the below video as examples.
In this context, the water flowing through the hose represents work items. The water is what is being processed, the hose is the workflow.
When the hose isn’t restricted, the water doesn’t flow with much speed. It certainly isn’t useful for spraying someone or washing a car. By restricting the flow the work item (water) accelerates with more force so the stream goes much further.
In our work context, high levels of WIP cause work to sit and wait to be serviced. People are busy doing other items also in WIP. Pressure is often applied, perhaps as vanity deadlines, to each different effort so people respond by trying to make progress on each a little bit at a time. Flow slows tremendously, the water is just sort of trickling out of the hose.
Remember the time loss when switching between all these various activities? That is also contributing to the slowdown of progress on all items.
Limiting WIP – Start Simple
Going back to where this started, initial steps in helping a team or team of teams, WIP should be the first factor considered to improve flow. Evaluate the number of items being worked in parallel. How many people are juggling several different tasks all the time? Is the team continually interrupted and being asked the status of all the different work items? How about “priority interrupts” to inject even more WIP?
One of the 6 General Practices of Kanban is Limiting WIP. It’s actually number 2, right after Visualizing the work. Why would this be a core practice? If you guessed it’s to increase flow through the system you’d be right.
The most effective organizations focus on flow of value. They put much less emphasis on keeping everyone busy every moment of the day (high utilization).
When people are fully busy all day, juggling multiple tasks, flow decreases within the system. A key way to unblock flow is to lower the amount of work within the system. This is known as limiting WIP.
As a first step working with the team, limiting WIP in the overall system is an effective technique to improve flow. Examine the recent data. How much WIP is typically in the system?
Use experiments to evaluate lower WIP values. For example, if the current average system WIP is 20, try reducing it to 10 or 12. Give that experiment some time to run and assess the results. Did lowering the WIP improve the flow? Were people happier jugging fewer work items? Continue to form new hypothesis around WIP limits. Try limiting WIP on individual workflow states as well as overall within the system. More on that in future posts.
If your teams are using Scrum you are already indirectly limiting WIP by selecting only a set amount of stories, or points, into the Sprint. There is nothing stopping you, however, from setting up WIP limits on individual workflow states.
If the team suffers from all work piling up in QA the last day or two of the Sprint, try limiting the development states. That should provide a steadier stream of work that is ready to be tested. There are of course other techniques to apply in this case but lowering WIP limits upstream of the testing is the least intrusive and threatening.
Wrapping Up
When beginning with a new team it’s understandable to try something “big” for a big reward.
Instead, consider limiting system WIP as the first step for these reasons:
- it’s a non-threatening change. It does not challenge the team’s current way of working or anyone’s sense of self worth. It’s simply doing what they have been doing, just less of it in parallel.
- It is the first step towards building a “pull system”. Pull systems are preferred over “push systems” because it maintains a more consistent state. As one thing finishes the next item is “pulled” into the system.
- it’s a proven practice to increase flow. What better way to start with a team than to help them increase the flow of value!
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
