A topic of interest that seems to be gaining some steam around the agile community and with some of our clients is Kanban. Kanban is a Japanese term that is literally translated ‘signboard’, often cited as ‘card wall’. The practice of using a Kanban has permeated many agile frameworks, and is sourced from lean methods, which originates from lean manufacturing. As opposed to the manufacturing side where lean and Kanban are leveraged as inventory control systems, the software side utilizes this as a scheduling system.
Most folks identify Agile with Scrum. So, in order to best describe Kanban, I will juxtapose it with Scrum.
Both methods are empirical insofar as a inferred or explicit ability to experiment with the process.
Both methods are adaptive, rather than prescriptive.
Both methods provide visibility into ‘what is being worked on’.
Both methods empower the team to make determinations around the process itself.
Both methods are fueled by cadence and continuous flow.
Both methods operate as a ‘pull process’(we have bandwidth, pull the next one in), rather than a ‘push process’ (wait for a staged gate before proceeding)
Scrum condones the use of time-boxed iterations called “Sprints”. (Our bucket is only ‘so’ big)
Kanban leverages work-limits by each workflow state. (Little’s Law)
Scrum creates a feedback loop at the end of each sprint for review and retrospection.
Kanban creates a feedback loop at the completion of each work product with regard to queues and lead time.
Scrum leans on different roles to facilitate the process and ceremonies.
Kanban doesn’t require* the creation of any roles outside of the folks doing the work. *but doesn’t say you can’t either J
Scrum resists change within an iteration. (planning, then commitment to a body of work)
Kanban welcomes change at any given time. (next addition to the work states, adherence to the WIP limits)
Scrum seeks to establish a velocity to understand how much (and when) a body of work can be completed.
Kanban develops a cycle time for work in order to provide information back to the customer as a baseline SLA.
Scrum leverages the burndown chart and velocity metrics as the standard of reporting.
Kanban makes no prescription for reporting, but rather empowers the team to report on what make sense for the team.
The crux of Kanban is to have a constantly evolving backlog of work that flows into queues of limited sizes, that are updated each time something moves from one queue to the next. Based upon completion, the team develops a sense of lead time, and how many items are optimal for each queue. That’s it.
Neither approach is more right than the other, and there are great cases for taking a bit from each and using the pieces that work best for your organization. Some folks, highly prizing both the cadence and ceremony of Scrum, and the visibility and flexibility of being able to respond to work requests of Kanban, operate in a hybrid called Scrumban.
Just keep swimming…