Remembering why WIP limits are important

I recently found myself in a position where I needed to explain the fundamentals of WIP-limits and collaborative development to someone. What surprised me was that I've come to take these concepts for granted and haven't thought of the reasons behind them for years.

One of the managers I work with has a group of 9 reports (yeah I know it is too many) who currently has five deliverables in flight. Looking at their work allocations, it seems like 0.5 to 2.5 people are working on each deliverable. One can safely conclude that people are shared across tasks and that some work in isolation.

This approach is sub-optimal as causes invisible* side-effects which slow down overall delivery of the team.

  • People that are shared across tasks cause situations where one group waits for the shared person, which slows delivery down. What makes this worse is that one person wait it has a knock-on effect causing others to wait (think of a trsffic jam).
  • One of the reasons we often shared people across work is because they are subject-matter experts (knows a problem or module), or specialists (like quality assistance). In this case, there are two risks:
    • The shared persons’ own ability to contribute is reduced because they are spending a lot of time switching work.
    • The goal of mentoring the team is reduced because they are only working with a small subset and also not for the whole time.
    • It also drives "hero culture" which in itself causes people to pool knowledge, which comes at the expense of others' growth. This constrains flow even more.
  • Quality is typically lower because people are working in isolation which means their mistakes are only detected when bugs are discovered during testing or in production. Quality is everyone’s responsibility, and our goal is to prevent bugs from happening in the first place.
  • The team never really forms as a unit because people are always working as individuals which means they never get to the point where they build the deep trust required for high-performance and innovation.
  • Drive for resource-efficiency (busyness) instead of flow-efficiency (throughput).

Solutions to consider:

  • Reduce work in flight to one per team
  • With team think of a group of people who work on one piece of business value together.
  • The ideal team size is anything from 4-7 people, which means you probably have two teams. Other teams at Serko call these pods.
  • Focus everyones' effort on finishing work as opposed to starting. With finishing the goal should be achieving business objectives, instead of simply deploying production software.

Other observations:

  • The team is also assigning work to people at the beginning of the week, which means that people doesn't get the opportunity to choose the best person for the task when the task is picked up.
  • *The idea of a Kanban board is to make these things visible so that people can manage flow and prevent flow impediments early. The team has numerous kanban boards which means they are unable to identify these flow problems effectively. Each cohesive team should ideally have one Kanban board and one only.

Further reading:

Thanks to Dave Nunes, Mark Pearl, Matthew Crosswell, Eduardo Maino, Aurelien Beraud for their feedback and input on this post! :-)