In a recent post, we provided an in-depth introduction to agile methodology and one of it’s most popular frameworks, i.e. Scrum. There are tons of agile frameworks available to choose from—like Crystal Clear methods and Extreme Programming (XP)—and each having something unique to offer. One framework often compared to Scrum, and sometimes even combined with it, is Kanban.
Kanban dates back more than 50 years to the Toyota factories of the late 1940’s. At the time, Toyota’s car factories were changing their production methods to emulate supermarket models wherein they stock only enough product to meet consumer demand.
Seems straightforward today, but at the time, car orders were placed in bulk upon release based on lofty sales projections. When real-world demand didn’t meet those projections, factories had to house excess inventory until it was eventually sold or disassembled back into parts to be used for future products. This method is obviously pretty inefficient, which is why they were in need of a way to match inventory levels with consumption.
To communicate capacity levels in real-time on the factory floor, workers devised a card, or “kanban,” system. Whenever a bin of materials was empty, a kanban was passed to the warehouse ordering more. The warehouse would send a new bin to the factory floor, and in turn, send their own kanban to notify the supplier.
The supplier would then ship more materials to the warehouse. While the kanban themselves are no longer physical notes sent between workstations, the chain of communication for producing stock “just in time” (or JIT) is still the same.
While almost any industry can use this framework, agile software development teams have taken a particular liking to it. Teams today use these same JIT principles to match the amount of work in progress (WIP) to the team’s capacity.
The Kanban board
Instead of physically passing notes back and forth between members, teams today organize these stages of production requests using a kanban board. This board could be a physical whiteboard with sticky notes or digital board, like the ones often incorporated into project management tools.
Physical boards tend to lose their usefulness once a project becomes too complex, as they can’t provide much in the way of context compared to a virtual board with features for adding things like documents and screenshots. Virtual boards also make it easy to archive and retrieve cards at a later date, whereas post-its tend to get thrown out or lost. Even if you do keep them, they’re likely a nightmare to organize and retrieve information from at a later date. Virtual boards allow for more traceability and context, with the added bonus of being accessible from any location with a wi-fi connection.
Most boards incorporate three basic stages into their workflow: To Do, In Progress, and Done. Development teams also often include a Code Review stage. However, teams can customize their boards to whatever workflow is best for them.
The stage names are not as important as the board itself is. The purpose of the board is to visualize teamwork, standardize workflow, and make blockers more easily identified and resolved.
The kanban board is also dependent on all team members taking responsibility for being transparent about their work and communicating their capacity in real-time. The board is only as good as the integrity of the information it represents.
Across each stage designated on the kanban board, cards are placed to represent different work items currently in that stage of production. Cards can contain a lot of important information like who is responsible for each item of work, a description of the task and any relevant documents for context, a time estimate, and more.
Again, relevant information can be customized to each team’s needs. As a stage is completed, the card is moved across the board until it reaches the final stage.
The benefits of Kanban
Kanban teams are more productive because they are only focused on work that is actively in progress.
Items are pulled from the top of the backlog to be worked on, and those items are the only things that concern the team until they are complete. Then they move onto the next items that have moved up to the top of the backlog.
If teams choose to assign a designated Product Owner, they are responsible for organizing this backlog and can do so freely since the team is only concerned with items in progress. Backlog changes don’t cause interruption or distraction for the rest of the team.
Overlapping skill sets mean teams are also able to deliver work in shortened cycle times, a key metric for Kanban teams. Cycle time is the amount of time it takes for one unit of work to make its way through the entire team workflow from start to finish.
When only one or two people have the skillset to complete certain tasks, cycle time often slows. To-do items begin to create a bottleneck in the workflow, and the system breaks down. In Kanban, teams have shared skills, which means that things like testing aren’t just left to QA, developers can step in when necessary, too. It’s the entire team’s responsibility to move items through the workflow.
An important metric of Kanban is ‘work in progress,’ or WIP. Teams set limits to the number of items that can be in any given stage to prevent a bottleneck from arising. If a certain stage reaches capacity, team members refocus their energy and swarm that stage to help clear the way and move items along the workflow faster. Addressing issues and delays are therefore built into the system itself.
Tracking this process not only helps teams improve as they go, but it also helps them more confidently forecast delivery estimates in the future.
The final benefit we’ll mention is that of continuous delivery. Continuous delivery often referred to by its acronym CD, is the practice of releasing work regularly and often.
Some teams release work daily or even hourly. As long as the item has gone through the full workflow, it can be released. The faster a team delivers innovation, the more competitive their product is in the current market.
Kanban provides teams a high level of visibility into their work, keeps individuals focused on just a few tasks at a time, and incorporates identifying and addressing problems right into the cycle itself. It’s hard to argue with benefits like that.
And if you’re thinking to yourself, Kanban seems like it would actually pair well with Scrum, you’re not wrong! Many teams actually blend the working styles together in what’s cleverly called “Scrumban.” But we’ll save more on that for another time.