Kanban is a method formulated by David J. Anderson for managing the workflow of an incremental and evolutionary process. Influenced by the Toyota Just-In-Iime model, the method is based on visualizing the workflow and, from there, acting on the process so as not to overload the system and team members.
Through a visual management approach to the value chain, the process, from its initial stage to the delivery of the work, is exposed to team members. Typically the value chain is represented on whiteboards with post-it notes or online tools. Process, work items, as well as workers are visually represented on these boards, commonly called kanban boards, or kanban (that’s right, the method and board name are confused). Kanban makes it easier for the team to decide what, by whom, when, and how much to produce.
In software development, a small task typically takes hours to days to complete. Also, you cannot see how many requirements are currently under review; or how many requirements are currently being coded or tested. The fact is, we can’t “see” the software-related work item, and how it moves through the steps of the process, until it’s ready. Here’s where it all starts: kanban makes such under-construction items visible!
1. Visualize the workflow
The main idea of kanban is to put the workflow in front of everyone. For example on a whiteboard, or on the wall itself. Below is a kanban photo taken of a software development team.
Because the wall is a two-dimensional surface, the kanban is presented in a tabular format, where the work steps are column headings, and work items, photos of people, and other work-related tags fill the space on the wall. These cards can be arranged in a horizontal line or not. It all depends on the team and how they represent and organize their work on the wall.
work steps and items
2. Limit WIP
Limiting work-in-progress, or work-in-progress WIP in English, implies that kanban follows a pull system. Work in each step of the process is limited so that new work is only “pulled” to the next step when there is available capacity within the WIP limit of that step. WIP constraints identify bottlenecks and problem areas in the process, helping the team make decisions to resolve them. Limiting WIP is the great differentiator of the Kanban method. Such a ruse is the watershed between task boards, or visual boards – as they were known before the influence of David Anderson with the dissemination of the Kanban method – and the kanban boards.
3. Keep improving the workflow
According to David Anderson, the whole point of implementing a kanban is to create positive change. Before creating this change the team has to know what to change. The team needs to figure this out by looking at how work items are flowing through the process, and analyzing the problem areas where the work bottlenecks. Hence, make changes in the work process to solve such problems.
And so on; identifying problems, and acting to solve them. All this based on the kanban view and WIP limits. Improving the work and the process, in the continuous search for greater efficiency.
Conclusion
Kanban can be seen as a communication tool to quickly acquire and disseminate knowledge among team members. The main objective is to give all team members a shared view of the process and the current state of work. To this end, kanban has visual representations for work phases, people, and work.
But the kanban method goes beyond that. From a simple approach: workflow visualization and WIP limits, the team works in a pull system, which helps the team to identify bottlenecks and act on problem areas in the process. As such, kanban provides the team: a tool, a practice, and a process of continuous improvement.
