When Not to Use Kanban Swim Lanes
Choosing the best tool for a particular task is not always easy, and we are often biased towards the wrong solution. This is especially true when we consider our positive bias towards complexity. A more complex tool might often look more appealing just on the merit of the fact that it supposedly has more features. Unfortunately, we often fail to realize that redundant features are almost always a hindrance. In Lean, we call this Overprocessing.
Such is the case with Kanban swim lanes. Many of us view them as a bonus and a feature, without taking into account that one of Kanban’s main advantages is its simplicity. This means that simplicity should be sacrificed only when this leads to a real benefit.
Undeniably, using swim lanes on your Kanban board might often be quite beneficial. After all, the concept was developed to add value, depth and utility when needed, and there are many implementations that are extremely successful. But the fact that we have the option to use swim lanes doesn’t mean that we should.
So here are a few cases when using swim lanes would actually be the wrong thing to do:
Each Team Member Has Their Own Swim Lane
Broadly speaking, having a separate Kanban swim lane for each team member defies the purpose of having a Kanban board altogether.
First of all, a Kanban board is supposed to simplify communication and teamwork. Separating each individual team member into their own swim lane inhibits collaboration on both a psychological and a practical level. First of all, in any industry that might benefit from having a Kanban board, there will often be tasks that are handled by more than one individual. Per-person swim lanes make this impossible to visualize, so the task ends up with one individual, possibly creating tension while making the board less informative and useful. On top of this set of practical problems, having this setup will lead to individualism, and most team members will start caring about their own tasks and success, instead of fighting for the team.
Secondly, individual swim lanes per team member usually destroy the concept of WIP limitations. When the allowed number of tasks in the Work in Progress column is lower than the number of team members, people are going to have to work together, collaborate and share experience. In this way, everybody will have to view the team as a unit, and would be compelled to act in the team’s best interests, not their own.
Swim Lanes Represent Different Phases
The main purpose of a Kanban board is to visualize the process in question in a comprehensive way. Each task should start on one side, and move through all the steps in the process, so it can reach completion on the other side. Swim lanes are a bit dangerous, because they allow for forks in the road, and often get misused. One of the most common mistakes while implementing them is having different phases of the same process represented as different swim lanes.
A tell-tale sign of this problem is when tasks reach the end of one swim lane, and then instead of going to the “Done” column, they start their journey all over again in a different swim lane. For instance, a software development company might have a Kanban board with the standard three columns To Do, Doing, and Done, and three swim lanes Design, Development and Testing. Obviously, each task will start in the Design swim lane, and then move through Development and then Testing before it lands in the Done column.
This will obviously create problems and is not a good way to visualize the flow. Swim lanes should not be sequential but parallel, and if they aren’t, they are just obscuring the big picture. Our development company example needs to expand the number of columns to properly represent the sequential nature of design, development and testing, and eliminate the pointless swim lanes from their Kanban board.
Swim Lanes Don’t Need to Be on the Same Kanban Board
A Kanban board should be practical and easy to use, so the larger a board gets, the more impractical it can become. When trying to implement a Kanban board in a large or diverse organization, it can become too cumbersome. That often gets handled by adding more and more swim lanes for different teams. That can sometimes benefit the organization by making the big picture universally visible, but most of the time, it only creates clutter. This happens when each swim lane actually represents a distinctly different process handled by a different team. If this is the case, it might often be a much better idea to create multiple Kanban boards for the different parts of the organization.
Generally speaking, a board that attempts to encompass disparate processes is unlikely to do a very efficient job. If there isn’t a good reason to keep the processes together on the same board, separating them will allow each department to use their own board with a heightened level of efficiency. In this way, each Kanban board can be customized to better represent each team’s workflow. This will lead to faster process improvement and tighter collaboration. If the organization still requires interdepartmental communication and coordination, an additional Kanban board can be created to handle that task explicitly.
So Should You Use Swim Lanes?
In the end, each organization is different, and the Kanban boards they implement should reflect their specific needs and workflows. While the recommendations or warnings in this article should help you avoid overusing Kanban swim lanes, the final decision should be based on achieving the best results in your specific situation. Just make sure you are not using swim lanes from the sake of complexity, and implement them only when they are adding real value to your Kanban implementation.