Does Kanban Respect People, Self Organisation and Continuous Improvement

There has been a lot of talk recently about whether Kanban Systems for Software Development include the need to respect people, and allow self organisation and continuous improvement. It is true that the community has primarily focussed on the mechanics of Kanban Systems. I believe that this is because it is the mechanics that are the differentiating factors, and thus generally the most interesting to discuss. However, we should not forget the human factors, as they are inherently part of the Lean Thinking from which Kanban directly descends. This post is an attempt to try and redress the balance by showing how the five primary practices should enable the right behaviours.

A Kanban System should respect people by allowing them to take ownership of process decisions. Mapping the value stream sets up a team where everyone who is involved in creating value is recognised and respected equally for their role. Visualising the value stream enables a team to decide for themselves how best they want to manage the work. Setting work in progress limits gives the team a mechanism to manage their work/life balance effectively and avoid having more work pushed onto them than they have capacity to deliver. Establishing a cadence gives the team a way to create a rhythm which is natural and works well for them. Reducing the kanban tokens guides the team in creating their own process in order to allow the work flow. All these practices are about the people on the team having discussions and making decisions which work for them. They are not about the team having decisions made for them by managers.

By allowing the team to take ownership of all the process decisions described above, a Kanban System automatically empowers them to self organise and continuously improve all the elements of the process. The primary mechanism for enabling this self organisation and continuous improvement is making the work visible. The whole value stream is visualised so that the whole team can see where the problems are and where the improvements are needed. Limiting work in progress makes the bottlenecks or constraints even more visible, and will ultimately shut down the system so that the team has to self-organise fix the problems. The team’s cadence provides a regular rhythm to reflect on the whole system, alongside the spontaneous quality circles and kaizen events triggered by the visualisation and limits. Self organisation and continuous improvement are therefore crucial if the team are to successfully refine the process such that they can reduce the number of kanban tokens and allow the work to flow more freely.

A Kanban System is more than just a basic tool to be used to manage the work. It is a way of working which frees people to think for themselves in the pursuit of achieving success through improved productivity and quality.

The Fifth Primary Practice of Kanban

I recently wrote what I considered to be the four primary practices of a Kanban System for Software Development:

  1. Map the Value Stream
  2. Visualise the Value Stream
  3. Limit the Work in Progress
  4. Establish a Cadence

During subsequent discussions on the aspect of Continuous Improvement in a Kanban System, I decided that there was a missing fifth primary practice:

  1. Reduce the Kanban Tokens

I originally named this practice “Eliminate Kanban”, but was persuaded that this was probably overly sensational, and as a result potentially confusing or misleading. Its intent is that once a Kanban System is in place, the team should be constantly looking to improve it by creating an environment where the work flows naturally. There is a quote that I believe comes from Rother and Shook which says “flow where you can, pull where you must”. By striving to reduce the number of kanban tokens in the system, a team will move towards an environment where they are more self organising and the work can flow. This can be achieved by either lowering the WIP limits or by collapsing the number of distinct stages.