In my last post I discussed How WIP Limits work to help you get more stuff done.
Some folks like to compare Kanban and Scrum, but this is not really an apples to apples comparison. Scrum is a framework with defined roles, activities and artifacts – It gives you a prescriptive formula for how to run a Scrum Team. Kanban on the other hand is a set of Principles and Practices that you apply to whatever process you have (even Scrum) to improve it. These Principles and Practices get somewhat different wording depending on your source, but here are the ones I tend to reference:
Kanban Principles: Keep these in mind whenever making decisions about your process
- Start with what you do now
- Agree to pursue incremental, evolutionary change
- Initially, respect existing roles, responsibilities & job titles
- Every team member is a leader
Kanban Practices: Apply these to you processes
- Make Policies Explicit
- Limit WIP (Work in Process)
- Manage Flow
- Implement Feedback Loops
- Improve Continuously and Collaboratively
So while Scrum is rather prescriptive, Kanban is general non-prescriptive. There are many approaches you can take that are consistent with the Principles. And there are many ways you can apply most of the practices…. well except for one, you either limit WIP or you don’t. But that alone should not convince of the veracity of this blog post’s title. To do that let me take you to Kanban’s roots… in the factory.
The Kanban process started with the Toyota Production System for manufacturing cars in Japan. The term Kanban in Japanese is as follows
..and it means “card” or “sign”. What we call Kanban is actually the Kanban process – a process that uses these Kanban or cards. Here is what a Kanban card in a physical factory might look like (ref)
It specifies a part to be produced and a quantity which to product.
Let’s see how this process works in the factory. In the below diagram (ref) the Green A is the Kanban card. This is one machine in an assembly line, there is another machine downstream (to the right) consuming the widgets made by the machine below.
The Kanban card limits the total number of widgets. The completed widgets sitting there waiting to be consumed by the next machine plus the widgets in process of being manufactured cannot exceed the quantity on the Kanban card. There can be multiple Kanban cards used in which case it can never exceed the total quantity on all the Kanban cards – this is the Work in Process (WIP) limit. Without the Kanban card (and associated WIP limits) this machine would just run and produce widgets even if the next machine cannot keep up. In that case they would just pile up on the floor in front of the machine building up inventory which takes up resources and delivers no value (value is only delivered at the end of the assembly line after all machines have processed the widgets). The Kanban card optimizes flow through the system, and creates a pull system by which this machine only created widgets when the downstream machine requests (or pulls) them.
So now let’s come back to software. Here is what a Kanban board may look like for a software project. The numbers in brackets represent the WIP (Work in Process) limits
Since we know Kanban (看板) means “card”, I will ask, where on this board are the Kanban cards? Are the sticky notes the Kanban cards?
The sticky notes correspond to the work being done. They are the “parts” in the factory being produced. The columns on our Kanban board are the “machines” in the factory. Remember, the Kanban card limits WIP of any given machine.
àThe WIP limit is the Kanban card ß
If we wanted to, instead of writing “” we could put two markers in our Implement column and state we can never have stickies (work items) in that column without a marker. These markers would be Kanban cards, limiting the work in process (WIP) in the Implement column.
It just easier to write the WIP limit as a number than to create all the Kanban cards.
So, without WIP limits you are not using Kanban cards. And if you are not using Kanban cards then you are not doing Kanban.
You might have lovely continuous flow process. It might have a glorious board, and your team might methodically update it and move their stickies from start to completion. This might work for you and I would not tell you that you need to change it. But It ain’t Kanban if you don’t use WIP Limits.