Zen stone path

Background

Kanban comes from the Japanese “Kan” 看 sign, and “Ban” 板 a board. It was first formulated by Taiichi Ōno at Toyota as a way to reduce waste and increase productivity. It was very successful indeed, earning Ōno promotions to executive vice president in 1975. The idea is simple enough: cards were used to signal and track demand, thus creating a system of on-demand production of parts and final product.

In the early turn of this century, Kanban became popular in software development. It hitched a ride on the back of Agile and even modified the scrum methodology into Scrumban. However, it does not have to be linked with it. At its core, the principles are simple.

How does it work?

First create a simple board with to-do, doing, and done column.

All your new tasks, or cards, go into the to-do column. Next are ordered in order of priority, with the most urgent at the top. Cards move from the left (to-do) to the right (done) of the board. When you find yourself finished with a card, you move it into the done column. Then, you offer your help on the top-level card in the doing column, going down the list until you find something you can help with. If nothing is suitable, you can pick the top-level card in the to-do, own it, and move it to doing.

Clearly, this is the simplest possible board you can have. You could (read: should) add an In-Test (where testing/SQA happens), a Refinement (where the three amigos happen), and a Review (where reviews before merging happen) to the list. The flow would then be:

To-Do ­→ Refinement ­→ Implementation (Doing) → In-Test → Review → Done.

This is a workflow I used many times to deliver complex software successfully.

One thing I did not mention is the idea of Work-In-Progress (WIP) limits. Each column should have a maximum number of cards in it. If that number is reached, you cannot add a card there. Therefore, it is imperative that you help someone move a card onward. This ensures that things get done.

One final thing is the idea of a swim lane: A lane above the rest, where super urgent things go and take priority over all the other cards, whatever their statues. The WIP of this should be one: only one card can be that special!

The Good

Visualization of Workflow: Kanban uses a visual board to represent work items and their current status. This makes it easier for team members to understand the state of the project, identify bottlenecks, and see the progress of individual cards. Of course, too many cards can make this difficult and overwhelming.

Promotes Continuous Delivery: Kanban encourages the continuous delivery of software by limiting the amount of work in progress (WIP). This helps to ensure that cards are completed and delivered to the client or end-user as quickly as possible. A side effect of this is that since in-flight will get done, you never abandon a card because priorities change.

Increases Efficiency and Productivity: By limiting WIP and focusing on completing cards before starting new ones, Kanban can help to increase the efficiency and productivity of the team. It also reduces the need for context-switching, which can be a significant drain on productivity.

Flexibility and Adaptability: Kanban is a highly flexible and adaptable methodology. It does not prescribe a specific set of roles, ceremonies, or artefacts, which means it can be easily adapted to fit the needs of the team and the project. Changes can be made to the process at any time, allowing for continuous improvement.

Improves Collaboration and Communication: The Kanban board serves as a centralised hub of information for the team. This can help to improve collaboration and communication, as team members are always aware of what others are working on and the current state of the project. Regular stand-up meetings around the Kanban board can further enhance this communication.

Velocity: Each card must have a story point, or t-shirt size, or some other metric. Generally, this is assigned in the Refinement column. Then, the velocity per card size in days can be evaluated and statistics done on this until you have a 95% confidence interval that an 8-story points card will be done between 4–6 days — random numbers!

The Bad

Lack of Structure: Kanban is a highly flexible and adaptable methodology, which can be a double-edged sword. While it allows teams to tailor the process to their needs, it can also lead to a lack of structure and clarity, especially for teams that are new to the methodology.

Risk of Overburdening: One of the key principles of Kanban is to limit work in progress (WIP). However, if the WIP limits are not set or enforced properly, team members can end up with too many cards, leading to stress, burnout, and decreased productivity.

Not Suitable for All Projects: Kanban is best suited for projects with a steady, predictable flow of work. It may not be as effective for projects with a lot of uncertainty, complex dependencies, or a fixed deadline, as it does not have a built-in mechanism for handling these types of challenges.

Requires a Culture of Continuous Improvement: Kanban relies heavily on the team’s ability and willingness to continuously improve the process. If the team does not have a culture of continuous improvement, or if team members are resistant to change, it can be difficult to fully realise the benefits of Kanban.

A single flow: The most important flaw in kanban is that it is a flow, not a cycle. Sometimes, cards must go from In-Test back to Implementation since there is some significant development bug. Every so often, a card will be stalled on external dependencies such as hardware not ready if you are writing a driver, or waiting for a resource outside your control to be ready. This can wreak havoc on WIP limits!

Should you adopt it?

This depends on your team and upper management buy-in. One of the nice things about Kanban is the ease to create and use. Try it for a project, or an iteration, and see if it works for you. If you need more guidance, why not contact us as we can help adapt Kanban into your processes.