Kanban is a framework for implementing Agile software development. It was developed by Toyota. Yes, the auto manufacturing company.
Toyota developed Kanban after studying how supermarkets stocked shelves.
They noticed that supermarkets had the goal of being “just in time”, meaning that the stocks aren’t continuously overloaded with expired or wasted food. Rather they would be stocked in time with fresh food for consumers to purchase.
Over the years Toyota refined this process for building their cars and now it is used in the software industry to build software.
With Kanban the rules are not as “strict” as Scrum. By this I mean that there aren’t as many defined rituals.
One key concept with Kanban that differentiates it from Scrum is that there are no sprints. Rather, Kanban uses cycles.
With Kanban a team will have a defined schedule for when they release new working code (for example every 2nd Monday). Once the date arrives everything that is completed by that date (falls within the “Done” column) gets launched.
The main tool that is used in Kanban is the Kanban board. A Kanban board has 4 key columns
You may see variations of these columns as some companies and teams will name them differently or add additional columns. This is 100% ok, and in fact encouraged if needed. Modify the processes as needed to fit your team’s needs.
Within each column are tickets with specifications of the work that needs to be done.
So how else does Kanban work?
With Kanban only a certain number of tickets can be in progress at a time. It is up to the team to determine the number or tickets. With time and experience a team will know how many they can handle.
When working in Kanban the implementation team will pick up a ticket from the To do list, work on it, and move it along the columns as it progresses.
So a ticket such as “Enable login with Facebook” will begin in the Backlog (or the To Do column) and work it’s way across to Done once it’s complete.
Backlog > In progress > Tested > Done
Once a developer has moved their ticket to done they then pick up their next item from the backlog. And the cycle continues.
There aren’t any particular meetings that are prescribed with kanban as there are for Scrum. However a team can set recurring meetings if they need to, especially if they are implementing Scrumban (Scrum processes mixed with Kanban).
While working with Kanban a product manager will be responsible for working with their development team to prioritize the backlog and ensure that the most important items sit at the top. This way when a developer completes their work they have clarity on what to work on next.
Kanban focuses on the cycle time.
The cycle time is the amount of time it takes a developer to complete their work (from picking it up In Progress to Done).
While the cycle time is measured and teams constantly strive to increase their output, it’s important to note that there are many things that can impact the cycle time.
For example if a developer does not have domain knowledge on how to perform a particular feature and needs time to perform research then this will lead to an increase in the cycle time. One way to address this is by creating separate tickets for the research portion of this work.
Similar to Scrum, Kanban promotes and enables continuous development.
Once the deadline is reached for the next release then all of the work that falls within the Done column gets shipped. If there are items that are close to complete but are not 100% ready then they are not included in the release.
This enables continuous delivery and immediate customer feedback as customers will continue to receive an improved solution at set intervals.
While Kanban is definitely more relaxed than Scrum it does pose some challenges when it comes to evaluating the time required to develop each item. However with the right tools tracking this information is much easier.
Kanban can be beneficial for development teams because it provides more flexibility.
Since Kanban has fewer meetings than Scrum it also gives developers time to focus on solving hard problems.
However Kanban can be tasking on product managers.
Similar to Scrum, product managers need to constantly groom the backlog. Even moreso with Kanban because once developers have completed their tasks and are ready to work on the next item they need to know what the next highest priority item is.
The backlog should always be groomed to have the highest priority item at the top. Product managers should not become bottlenecks for their teams.
Another difference between Scrum and Kanban is that in a Scrum team when a developer completes their task ahead of time they may use their additional time to assist others on their team (rather than move onto their next ticket).
This is because the entire team works towards accomplishing the sprint goal(s). So unless there’s a good reason to do so they won’t pick up another item from the backlog until the next sprint formally begins.
In Kanban however when a developer completes their current ticket they pick up the next priority ticket on the backlog and begin working on it.
When should Kanban be used as opposed to Scrum or any other Agile framework?
Kanban is a great option for teams that are less concerned about estimations.
Likewise, for teams that are mainly concerned about getting things done quickly and launching as soon as possible.
For example a development team whose main focus is addressing customer support issues and bugs.
Rather than following the Scrum processes and taking the time to obtain detailed estimates for each ticket and following all of the Scrum rituals, use a Kanban board to track the required work and address the bugs as soon as possible.