A pile of empty pizza boxes!

WIP limits are needed to stop waiting in queues.

Recently a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together. In a previous entry we began describing how kanban or Scrumban could be leveraged to help teams identify issues with how they work and then to fix them.  We conclude with the last two steps in a simple approach to leveraging kanban or Scrumban:

  1.   Establish beginning WIP limits for each task. Work in Process (WIP) limits indicate how many items any specific task should control at a time (being worked on or waiting in queue). An easy approach to determining an initial WIP limit for a task is to count the number of people whose primary responsibility is to perform that task (Joe is a primarily a coder – count 1 coder) under the assumption that a person can only do one thing at time (good assumption), and then use the count of people as the WIP limit. Roles that are spread across multiple people are a tad messier, but start by summing the fraction of time each person that does the role typically spends in that function (round to the nearest whole person for the WIP limit).  The initial WIP limit is merely a starting point and should be tuned as constraints and bottlenecks are observed (see the next step).

As the team is determining the WIP limits, think about whether there are tasks that only one person can perform that are necessary for a story to get to production. These steps are potential bottlenecks or constraints.  When developing the WIP limits identify alternates that can perform tasks (remember T-shaped people!).  If members of a silo can participate only in their own silo it will be difficult for them to help fellow team members outside their silo, which can be harmful to team morale.  This type of issue suggests a need for cross training (or pair-programming or mob programming) to begin knowledge transfer.  

  1.   Pull stories from the backlog and get to work! Pull highest priority stories into the first task or tasks (if you have multiple independent workflows you will have multiple entry points into the flow).  When a story is complete it should be pulled into the next task, if that task has not reached its WIP limit.   If a task can’t be pulled into the next step, it will have to wait.  When stories have to wait, there is a bottleneck and a learning opportunity for the team.

As soon as stories begin to queue up waiting to get to the next step in the flow, hold an ad-hoc retrospective.  Ask the team to determine why there is a bottleneck. One problem might be that the WIP limit of the previous task is too high.  Ask them how to solve the problem.  If they need help getting started ask if the queue of stories is due to a temporary problem (for example, Joe is out due to the flu) and then ask if there is more capacity to tide things over.  If the reason is not temporary (for example, only a single person can do a specific task, or stories are too large and tend to get stuck) ask the team to identify a solution that can be implemented and tested.  The goal is to have the team identify the solution rather than have the solution imposed on them from someone else (think buy-in).

Using kanban or Scrumban to identify and generate solutions to how teams work facilitates the development of good teams. Good Agile teams exhibit three attributes:

  • Bounded – Team members belong to the team and the relationships that they develop will be “sticky.”
  • Cross-functional – Cross-functional teams spend less time negotiating hand-offs and tracking down who can or should do any piece of work, thereby reducing the potential for bottlenecks.
  • Self-organized and self-managed – Self-organized and self-managed teams don’t need to wait for permission to make the decisions needed to remove bottlenecks or process constraints.

Overlaying kanban or Scrumban on top of the team’s current process does not change anything. . . .to start with. But it does position the team to take action when they SEE a problem.  Visualization of how work is flowing will show the team where bottlenecks occur. The scrum master or coach then needs to challenge the team to eliminate those bottlenecks, promoting the health of the team in the process.