You’ve probably heard the big news: multitasking is a myth. And yet, virtually everyone is guilty of switching between several projects at once — all while responding to emails, drive-by conversations, phone calls, and more. When pressed to deliver faster, we often overwhelm ourselves by attempting to take on more tasks, inadvertently diluting our focus and slowing ourselves down — a lot.
At Fortezza Consulting, I help teams achieve dramatic improvements in performance — sometimes by 3x or more. The key building block is single-tasking: Focusing intently on delivering quality work, one piece at a time. The impact of single-tasking is dramatic at the individual level, and transformational at the organizational level.
In complex, fast-paced organizations, single-tasking is impossible to implement without a disciplined approach. This is where WIP (work-in-process) targets come in. Keep reading and watch this webinar recording to learn the Lean and Kanban reasoning for why WIP targets work, and how to apply them at the enterprise scale.
Lean, Kanban, and WIP
A key principle of Lean and Kanban is visualizing the actual flow of work. By visualizing their work, teams are able to continuously identify opportunities for improvement. Kanban boards help teams visualize the priority, status, assigned team members, due dates, and more of any piece of work. They can also see issues blocking the flow of work — like bottlenecks and blockers — and can work to improve their process in order to achieve continuous flow. It’s through this process of continuous improvement that teams can drive toward their performance goals.
Another important element of practicing Kanban involves using a pull system — meaning that teams pull work into their system as they have capacity (rather than having work “pushed” on them without regard to their workload). In order to have a pull system, teams must have a prioritized backlog and a clear process for prioritization. This enables any member of the team to be able to pull prioritized work into the system as he or she has capacity.
It also enables the team to implement WIP limits — or ideally, WIP targets. Limiting WIP allows teams to focus on improving the quality and speed of their work. WIP targets unlock a new level of performance through the power of single-tasking, fostering a culture of experimentation and collaboration that can be a catalyst for reaching ever-higher performance goals.
What You’ll Learn
In this webinar, I introduce the concept of WIP targets and their application at enterprise scale, and address key questions such as:
- How can we recognize when it’s time to optimize WIP?
- How do we know what the right WIP target really is?
- How do we use WIP targets to foster stronger team autonomy and self-management?
- How do we help both leaders and knowledge workers make the necessary shift in mindset?
- How do we scale the application of WIP targets across the enterprise?
You’ll learn how to foster experimentation and collaboration and reach unprecedented levels of performance with your team.
Watch the Recording
Flip through my slide deck here.
10 Common Questions about WIP Targets
Q: For a team of 20 paired programmers, are you saying they should just pick a Team WIP Target of 10?
A: Yes! For those who may not be familiar with paired programming, it simply means that two software developers (programmers) are teamed up with each other for every task. So, it makes sense that a team of 20 would have a Team WIP Target of 10.
However, if one or two members of that team of 10 are senior experts who can better help improve team flow by “floating” to whichever pair of programmers might need help accelerating things, then that team may find benefit in exploring a Team WIP Target of 9, or perhaps even 8.
Q: With so many teams each having so much team autonomy, how would you scale this across a large organization with any level of consistency?
A: The aspect that requires non-negotiable consistency is the “How might we…?” culture, based on the foundation of single-task discipline—and everything that might be done to promote and reinforce that culture.
If each individual team comes up with radically different Team WIP targets—but each are based on strong single-task discipline—then you’ve likely just achieved something truly amazing.
The next step for project-centric environments is elevating the concept of Team WIP Targets to the project portfolio level (project-level WIP). Getting both task-level WIP and project-level WIP in line with capacity is the best recipe I know for dramatic gains in the throughput of project completions.
Q: How can I create buy-in from my teams?
A: I like to start by inviting folks to play the single-tasking game described on the slide shown below — it takes only about 10 minutes to play, and maybe 10-15 minutes to discuss the experience and learnings, so under 30 minutes total.
Usually, people are quite amazed at the difference in both speed and reliability. Then, share with them my story about the Rubik’s cube puzzles, and ask them if they agree that the speed difference is likely even bigger when performing complex knowledge tasks. Then ask, “What if we were only ever able to get halfway to some ideal single-task focus environment?” and “What if we were only able to do this for our most senior, expert, “bottleneck” resources working the most complex tasks?”
Be prepared for a mix of reactions—spanning from highly intrigued to severely skeptical—the point isn’t necessarily to convince anyone of anything during this first conversation, but only to get the conversation started. Then ask to continue the conversation, perhaps by adding the game to the agenda for an upcoming team meeting, or asking if anyone saw the latest study on single-tasking. Key here is not to look at it as a “buy-in” process in which you’re “selling” or pushing anything, but as a genuine start to a “How might we…?” type of conversation. You may well get some interesting and creative suggestions that have nothing to do with single-tasking, but which could nonetheless be well worth trying.
Q: How can we motivate people to engage in more cross-functional projects and teams? (ie. inside sales involved in material handling projects, production engineers involved in quality projects, quality involved in sales projects, etc.)
A: I like to put the entire cross-functional team on a single, simple ToDo/Doing/Done board whenever feasible, and then use Card Types to reflect the full spectrum of skills required. Even if you’re in a highly segmented, phase-gated environment, it can be quite an eye-opener for folks across the various functions to actually see the work that everyone has before them. And with Planview AgilePlace, it’s easy to filter out by Card Type when you just need to focus in on your team’s function. It’s also easy to run some analysis on where the biggest bottleneck issues are in the end-to-end process.
If such a single cross-functional board isn’t feasible, then I love that Planview AgilePlace offers Card Connections to show the connection between cards—whether on the same board or many different boards. It can take a bit of extra overhead to have folks make such connections explicit, but after a few people start doing this, it gets a bit contagious.
One more very important item on this — Planview AgilePlace’s Advanced and Enterprise editions also offer great analytics for cross-board reporting. So for those folks who may support multiple boards, we can run single-tasking reports to see just how many tasks they’re juggling at any one time, and then ask “How might we help get this number closer to one at a time?” Without this reporting feature, you’d have to check each multi-board user’s tasks on each of their assigned boards.
Q: The first question teams ask me is “what should our WIP limit be?” What’s good advice beyond “so low it feels kind of painful.”
A: I encourage you to start with the notion that pursuit of a single-task-focused environment is desirable — and if folks don’t agree that it might be, then see my response to the third question (about getting buy-in from your teams).
Once people start to see that it could really be a key enabler of both speed and reliability, then all you have to do is make sure that the WIP Target is no higher than the number of workers. As the team gets closer and closer to true single-task behaviors, you can then challenge the team to experiment with its own WIP Targets, which should always be lower than the number of workers.
Key here is to make sure everyone knows that, as far from the target as the team may be today, with WIP piled high, it’s OK as long as the board accurately reflects reality, and as long as we’re genuinely challenging ourselves with “How might we work WIP levels down closer to our single-tasking target?”
Resist the temptation as a leader to say “Hey, how come you have 5 tasks open—I told you we need to single-task!” If you do this, you will suddenly see a board with artificial harmony: The board will magically show perfect single-task discipline overnight, even though that is probably not at all reflective of reality…if this happens, you will have taken a giant step backward and may have to start over.
Q: We have high volumes of product flow through our system. We have implemented Lean, but we struggle with single-part processing.
A: If I understand the issue correctly here, it’s that high volumes are constantly pushing WIP levels well beyond capacity, and that “capacity” in this context is best achieved through single-part processing, consistent with Lean’s notion of single-piece flow.
If such single-part processing is executed mostly by humans in this example, then we know that our WIP Target should reflect single-task behavior, and so my advice on letting the team experiment with different WIP targets holds. If such single-part processing is mostly automated or machine-executed, then it’s important to understand whether single-part processing is truly what would yield maximum throughput. For example, for a single-lane highway, one car at a time is usually optimal, but for a 12-lane highway, we have the capacity to handle 12 cars in parallel.
Q: Can this apply to the development of physical products, too?
A: As long as it’s a human-centered or knowledge-work environment (as opposed to a machine-centered or mostly automated environment), then this works just as effectively with physical products as with software or other “invisible” end items. In fact, it probably works better for physical products, given that it’s often easier to see where the bottleneck is with physical products — just look at which processing step physical work products (i.e., “inventory”) are piling up the most, and that’s usually where the end-to-end bottleneck lies.
Q: Do WIP limit calculations require cycle time? And how much data do you need?
A: Technically, yes, but some organizations over-complicate this. To keep things simple, I like to just use cumulative flow diagrams like that shown this slide:
It shows cycle times—it’s just the horizontal or X-axis dimension, which Planview AgilePlace calculates for you. There are other Planview AgilePlace reports that zero in on cycle times more explicitly as well, so as long as the board reflects reality, then cycle times are captured just fine. The key here is that the slope of the CFD should grow ever-steeper, which can only happen if cycle times are shrinking (assuming overall capacity remains stable).
I’ve seen many examples of teams pursuing X% cycle-time reduction, and perhaps even claiming success on some target reduction, yet overall flow looks about the same—this is a strong indicator that the “local optimum” target may have been achieved only at the expense of overall or “global” flow.
Q: How do we manage and scale WIP?
A: Hopefully I covered the “scale issue” adequately on the slide below, but if not, here’s a quick summary.
First, propagate via “copy/paste” across multiple teams, with executive-level champions reinforcing the “How might we…?” culture every chance they get; also, as mentioned in my response to the third question above (about getting buy-in from your teams), consider consolidating into fewer and fewer boards, getting closer and closer to a true end-to-end process view for each major process in your organization.
Second, for project-centric environments, elevate the notion of WIP Targets to the project level, and assess whether lower volumes of simultaneous projects result in higher throughput of project completions (hint: it’s exceedingly rare that lower project WIP would not result in higher throughput — I’ve only ever seen it once, and that was after an aggressive reduction in project WIP that simply went just a bit too far).
Third, consider applying staggering concepts from Critical Chain Project Management as a great way to zero in on optimal levels of project WIP (learn more about Critical Chain Project Management in my new book, The CIO’s Guide to Breakthrough Project Portfolio Management).
Q: How do you measure WIP in the phase preceding development work?
A: I like to identify “preceding phase” work as different Card Types on the same board, with a simple ToDo/Doing/Done construct. This way, we have a true picture of overall team WIP levels, and can even zero in on which functions or sub-teams are closer to single-task discipline than others, and then have them share how they achieved that with the other functions or sub-teams.
Also, for cross-trained team members, it’s easier to see where someone on, say, the testing team is suffering from an impediment that a member of the development team may be able to help with in the name of improving overall team flow. This is consistent with Scrum principles of an integrated team that gets better and better at overall team flow through effective collaboration and cross-training, while individuals still maintain their primary roles and areas of specialization.
