This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.
At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.
The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.
- Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
- Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
- Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.
In other words, we want to flow value through capability teams.
Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.
- Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
- Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
- Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
- Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
- Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.
While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.
While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board, or team-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?
A Kanban System visualises some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualising the current tasks.
A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.
A Kanban System deals with these units of value through the whole system, from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.
By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.
One of the metaphors I use when I talk why a kanban system has work-in-progress (WIP) limits, is traffic jams. The greater the WIP, the lower the throughput, and this effect can be seen when too many cars clog up a motorway. Watching the BBC’s “Britain from Above” last night, they had an interesting section on this subject, including a nice simulation on how a bottleneck ripples back as it frees up, explaining how traffic jams can seem to appear and disappear for now apparent reason.
You can seen the clip here – the simulation is about 3 minutes in.
I expect you get the same effect in software development value streams, although I would also expect that software development value streams are short enough for the effect to be unnoticeable.