How Do We Control Work-in-Progress (WIP)?

One of the basics of improving our effectiveness is that we should control the amount of work we have in progress (WIP). Overloading people, teams and programs with more work than they can accomplish is a common problem. It causes multiplexing and frequent context switching. It overloads the people doing the work, reduces focus, reduces productivity and throughput, decreases quality and increases wait times for new functionality.

The problem is particularly an issue for knowledge workers in that most of the time WIP is not visible. Knowledge is hidden. The first step is to make it visible so that you can see it. A kanban board displaying how you work is a natural tool to do this.

Once you have done this you will find that WIP has a number of sources:

  • Over-utilization of people. This happen especially when people are focussed on “100% utilization. See What Is Wrong With 100% Utilization Thinking? for more information.
  • Over emphasis on starting. This happens when every project manager, for example, insists that their project is seen to be making progress.
  • Large batch sizes being handed-off between stages. This happens when there are stage gate approvals.
  • Bottlenecks in the process. This happens when people don't understand where the bottlenecks are.
  • Interruptions and other unplanned work. Especially when people just say “yes” and take on all such work.
  • Inability to make decisions. Which lead to lag / bottlenecks in the process
  • Push-based approaches. For example, when the schedule says that “all this must happen now”.
  • The “superhero” culture.
  • Existing large queues of work (inventory).

You then must take proactive action to reduce your WIP:

  • Establish a cadence and synchronize work on that cadence. Done correctly the cadence will naturally mean that you cannot take on too much work (although note that people / teams will still over-commit.)
  • As it is visible, set limits on how much WIP you are willing to take on for this stage. Note that setting a WIP to be the “same as the number of people in the team” just hides the problem - you need to set up a lower constraint so that people really start concentrating on flow.
  • Aggressively triage the work. See How Do We Deal With Product Backlog Explosion? for ideas on how to apply this thinking to a product backlog, but the reality is that this idea can be applied everywhere.
  • Ruthlessly prioritize at all levels. Too much WIP at the program level has a tendency to result in too much WIP at the team level.
  • Only commit when it means something. For example, if you are about to start some work, but have a dependency on another who is not able to do their part for a long time, it makes no sense to start your work now.
  • Focus your work, working sequentially one item at a time.
  • Stop starting and start finishing. This is especially important when you have inherited a huge backlog and people are asking you to take on more. Finish work that you have started before taking on anything new.
  • Bring (flow) work to the teams (not people to the work). If you are planning using a traditional “resource / skills matrix” and planning percentages of FTE's to be assigned to projects, you will have a tendency to increase the amount of WIP.

And, again, begin by making WIP visible.

Use the following URL for manually sending trackbacks:
What Are The Changes in Culture That Need To Happen with Agile? Note: this discussion is closely related to What Are The Changes in Management Approach That Need To Happen with Agile? The “inability to change the organization culture” is listed by most people as the biggest obstacle to implementing a Scrum / Agile approach. Here is a more detailed list of some of the culture changes that need to be made for an organization to become more agile in it approach:
simulating_wip_effects_with_balls_and_a_banana, 2017/05/02 11:53 (Trackback)
Simulating WIP Effects with Balls and a Banana Premise WIP is the silent productivity killer of many organizations. Too much WIP leads to many “bad things”: * Increases overall lead time * Reduces throughput * Increases context switching (and so reduces capacity to apply to work)
how_do_we_deal_with_constant_interruptions, 2017/05/11 16:56 (Trackback)
How Do We Deal With Constant Interruptions? A base I like to ask of newly formed teams is whether they have a feel for amount of work that is truly “interrupt driven” versus work that is “plan-able”. The reason I ask this is that while people say they are reacting to trouble tickets “all the time”, what I have found in a practical sense is that while this might be true from the perspective of the source of work, it is not necessarily true in how we deal with the work. The real question we shou…
You could leave a comment if you were logged in.
  • /home/hpsamios/
  • Last modified: 2018/06/18 13:24
  • by Hans Samios