In order to have a well-functioning Kanban setup one must agree on a basic set of rules of usage. The mother of all Kanban implementors is Toyota who, guided by the father of Kanban – Taiichi Ohno, outlined 6 basic rules that should be strictly followed.
- Do not send defective products to the subsequent process
- The subsequent process withdraws only what is needed
- Produce only the exact quantity withdrawn by the subsequent process
- Level the production
- Kanban is a means of fine tuning
- Stabilize and rationalize the process
These rules were defined for use at Toyota in 1953, so they may not entirely meet the requirements in todays software development. However, I still find it valuable to start up new teams using these rules for their Kanban setup.
When coaching new teams I interpret the 6 rules into the following software development statements:
Do not send defective products to the subsequent process
Always conform to the defined policies for each phase. Define efficient and sufficient policies to make sure quality is kept at appropriate level. Example: If the analysis phase has a policy that all design decisions must be reviewed by lead architect and business representatives – then this must be followed.
The subsequent process withdraws only what is needed
In production environments such as Toyota, this is pretty straight forward – only process ordered items that is needed further down the line. In software development this is analogy is a bit off and should be rephrased. My interpretation is two-fold: 1) only work on items that are prioritized and ordered by the customer and 2) all ways work on tasks from right to left on the board with respect to policies and limits, i.e. favor getting things done over starting new tasks.
Level the production
Working at the assembly line all units must produce exactly the amount of items needed by the weakest contributor, i.e. if machine A is able to spit out 1000 items per hour but machine B is only able to process 500 items per hour – machine A should be limited to 500 to minimize waste. The flow of tasks on the Kanban board should be meassured and bottlenecks should be identified to level the production. Resolving a bottleneck can be done by scaling up the problem ressource or limiting the number of tasks for review to the meassured capacity.
Kanban is a means of fine tuning
Kanban is meant as a non-intrusive framework that build on top of whatever defined/undefined process a team is following. Once Kanban has been initialized in a team meassurements and retrospective meetings should focus on fine tuning the flow of tasks on the Kanban board. Using the WIP-limits, policies and visual overview of tasks in the team to escalate pain points or reduce the number of active tasks in order to turn the team into a lean and mean task solving team.
Stabilize and rationalize the process
One of the objectives I hear from managers when assisting them in introducing Kanban, is to have a comon shared – stable – process for the team to follow. I aid the team to identify “all” their processes using process flow modelling and expand to one overall process. Process deviations for different types of tasks is handled within policies, i.e. each state on the Kanban board has policies covering “all” process deviations. This make a solid foundation for a sane and rational process within the team. A periodical retrospective meeting where the Kanban board is reviewed and updated, the team will have a rational process where each state that a task follows is within reason.