Introduction
Kanban is one of the two most commonly used implementations of the Agile program (the second being “Scrum“). This framework focuses on visualization of work to do and work in progress. Unlike Scrum, Kanban has a continuous flow of work. Some of the most recognizable practices of Scrum include: visualization of the flow of work, limitation of work in progress, continuous improvements on work flow, and incorporation of feedback loops.
Theory
Kanban is based on a continuous workflow structure that keeps teams relatively light and quick to adapt. It particularly shines for teams that have a notable amount of incoming requests that vary in priority and scope — e.g. it focuses more on going with the flow as opposed to exercising a high degree of control over what is in scope. Generally, Kanban leverages the principles of “just-in-time” and “work-in-progress” matched to your team’s capacity.
Framed another way, it is just like when a manufacturer decreases or increases the amount of inventory and materials stocked to meet production demand.
In turn, this enables team to focus on only the work actively in progress, shorten development cycle time, reduce operational bottlenecks, better visualize opportunities to improve team efficiency and effectiveness, and continuously deliver value to their customers.
Execution
Kanban is conceptualized into two key aspects: the Kanban board and Kanban cards.
Kanban boards are what the team uses to visualize work and to optimize the flow of work among the team. Each board is segmented into columns that represent the flow of work from state to state. Most commonly, you’ll see the following columns, from left to right.
- To Do – A list of items the team must address and resolve
- In Progress – A list of items currently being worked on by the team
- Under Review – A list of completed items pending validation (is it actually done?)
- Done – A list of completed items validated to be truly done
The board is then filled with cards, each of which is used to track the progress of work through the team’s workflow. Generally, the cards give the entire team an understanding of:
- What that work item is
- How long it should take to complete
- Who is working on the item
Conclusion
In terms of product development and management, Kanban is an excellent framework to use — particularly for teams in which a somewhat unstructured, continuous flow of work in and out is more beneficial to the team than the iterative structure of Agile. For example, scenarios where requirements can change at any given time call for the use of Kanban.
Because of this, especially if you’ve been reading some of my other musings on this site, Kanban is a tool meant to be used or set aside depending on what the situation calls for. Thus, while I recommend to start with one framework, I do also recommend over time to try out other frameworks in the interest of expanding your tool kit and getting you ready for whatever scenarios the real world puts you in.