How to Create Kanban Boards for Your Enterprise Agility Campaign - dummies

How to Create Kanban Boards for Your Enterprise Agility Campaign

By Doug Rose

As part of your enterprise agility initiative, create a Kanban board for each process in that stream. Delegate the responsibility for creating Kanban boards to the team or teams involved in each process.

You can use any of several methods to create a Kanban board, including the following:

  • Use a whiteboard (or a wall near your team), a roll of colored masking tape, and a marker to create and label the queues.
  • Use a spreadsheet program or create a table using a word processor, such as Microsoft Word.
  • Use a graphics program.
  • Use team-management software, such as Trello, to create your Kanban board. Every project-management software package includes a Kanban feature for creating and sharing the board with team members.

Create a separate queue for each step in the value stream and add a label at the top of each queue that describes that step. For example, software development teams typically create five queues:

  • Input
  • Analysis
  • Development
  • Test
  • Release

You now have a Kanban board. However, you may want to make a couple modifications, such as splitting queues and adding work in progress (WIP) limits, as discussed next.

Splitting queues

To break down stages of a process further, consider splitting one or more queues. Software development teams often split Analysis and Development into two sub-processes: “In Progress” and “Done.” (You’ll probably need to widen a queue before splitting it.) Then, they split the queues using a different colored line to separate the two.

Some teams prefer to create buffer queues. For example, they may add a queue to the right of “Analysis” labeled “Dev Ready,” to the right of “Development” labeled “Build Ready,” and to the right of “Test” labeled “Release Ready.” The buffer queue enables them to move items out of their queue without “pushing” those items to the next team before the next team is ready for them.

Although many experts discourage teams from splitting queues, because it leads to a more cluttered Kanban board, the buffer queues may make it easier for your team to pinpoint bottlenecks. For example, if a lot of work items are stuck in “Build Ready,” the problem that needs to be addressed is probably in the next step (testing) and not in development.

Without that buffer queue, everything would be stuck in development, making it less clear whether the problem is related to a slowdown in development or testing. In other words, if something is stuck in the buffer, it’s much more likely the backup is related to where the work item is going than where it came from.

When your team is creating its Kanban board, strive to create a healthy balance between simplicity and detail. Do you want a board that has more information but is a little bit more difficult to read? Or do you want a simpler board with less information that gives you a clearer high-level view of the process? More information increases visibility, whereas less information improves readability.

Adding work-in-progress limits

Near the top of each queue heading, write the number that reflects the team’s WIP limit. This is typically the number of work items a team can handle at one time — its work capacity. For example, if a team thinks it can handle five jobs at a time, its WIP limit is 5. Have each team make its best guess. You can adjust WIP limits up or down later.

Some experts suggest that ideally, the WIP limit should be equal to the number of people on a team, because each person should be able to take responsibility for one work item in the queue.

WIP limits are somewhat arbitrary, and they don’t account for fluctuations and changes in workloads over time, so you may need to adjust them later. Demands fluctuate and, at times, may exceed the capacity of a team to meet those demands. With a Kanban board, a team can tell the organization, “Enough is enough! Here’s how much work we can handle at one time. we won’t accept any more than that,” and the team sets a WIP limit to reflect that.

Size work items

Basing WIP limits solely on the number of work items is problematic, because not all work items require the same amount of work. The best way to handle this is to break down work items so they’re more uniform in size. You want each work item to represent a task that can be completed within a few hours.

If that approach doesn’t work for you, consider basing your WIP limits on the total amount of work your team can handle at one time. For example, your team may decide that it can handle eight hours of work per day. You can then size your work items according to the number of hours you estimate each will require. A big job will take eight hours, a medium job four hours, and a small job two hours. That means the team can handle any of the following combinations of work items without exceeding its WIP limit of eight:

One large job = 8

One medium job and two small jobs = 4 + 2+ 2 = 8

Four small jobs = 2 + 2 + 2 + 2 = 8

More important, you can see how this would affect the number of cards a team could have in its queue — only one card for a large job, three cards for a medium job and two small jobs, or four cards for four small jobs.

Imagine workflow in terms of traffic crossing a bridge. You have motorcycles, cars, and trucks crossing the bridge, but the bridge has a weight capacity, so it can carry a lot of motorcycles at a time, several cars at a time, or a few trucks at a time. It can also carry a mixture of motorcycles, cars, and trucks, as long as their combined weight doesn’t exceed the bridge’s capacity.

Using swim lanes to group work items

You can enhance your Kanban board by adding swim lanes — rows that cut across the queues and enable you to categorize related work items. For example, you can create three swim lanes to set the priority of work items or service-level classes, such as “Changes,” “Maintenance,” and “Defects”; to group them by deadline; to set off blocked work items from those that are currently in process; or to track supporting work that runs parallel to development but is not part of the actual product.

Consider using a swim lane to move high-priority work items faster through the process. Think of such a swim lane as the commuter lane in rush-hour traffic. It allows certain work items to bypass items that move more slowly through the process.

You can also assign a WIP limit to a swim lane to indicate the maximum number of work items that can be in that swim lane at one time. Just write the WIP limit near the label that describes that swim lane.