What is Kanban?

Kanban != kanban
I'm talking about Kanban, as in the method used in software development / IT circles, rather than kanban, as in the tool used at Toyota and in Lean.  Having to say this is why I've always found it unfortunate that the same word was used.

However, Kanban invariably leads to kanban as a countermeasure so there is that...

The foundation of Kanban is incremental, evolutionary change 
From The Principles of the Kanban Method,

There are 3 foundational principles:

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities and titles

In other words, the Kanban Method follows the same change sparsity principle of solution-focused and positive deviance approaches:

Do not change faster or more than necessary

The reason for this is that smaller changes are less threatening, less disruptive, and more motivating and yet can still have highly leveraged effects.

What is the method of change?
From The Principles of the Kanban Method,

There are 5 core properties:

1. Visualise the workflow
2. Limit WIP (work-in-progress)
3. (Measure and) Manage flow
4. Make process policies explicit
5. Improve collaboratively (using models and the scientific method)

Here's how I prefer to express this:

1. Visualise for shared understanding (of work flow, information flow, and capability)
2. Limit WIP (work-in-process)
3. Measure performance (productivity, quality, cost, morale)
4. Make process policies explicit
5. Improve collaboratively and scientifically

Visualise for shared understanding (of work flow, information flow, and capability)

Visualise to make our implicit understanding explicit and thus allow any disagreements in understanding to be resolved.

Because in software development, the work itself is information, it is easy to confuse work flow and information flow.  Information flow refers to work signaling, for example, "how do you know what to work on next?", while work flow refers to the movement of a work item (e.g. feature) from the start to end of our process.

It's not enough to understand the flow of work and information. 

Visualise to share understanding of the flow of work items, the signals we send to manage those work items, AND the capabilities of the people working within the system.

Limit WIP (work-in-process)

I'm inclined to consider Limit WIP as not part of the change method so much as a very common, perhaps, fundamental solution that the Kanban community uses.

Limiting WIP is technically quite easy to do but can be very difficult psychologically and politically to do.  So difficult in fact, that I'll suggest that if you are able to convince people to actually Limit WIP, and not just that it's a good idea, the rest is rather easy by comparison.

Measure performance (productivity, quality, cost, morale)

Measuring performance always starts with the question: "What does it mean to be good at this?"

My answer will be efficiently, and sustainably, delivering value that delights customers.  Just being fast isn't enough.  Just delighting customers isn't enough.  Just being efficient isn't enough.  Just being sustainable isn't enough.

Make process policies explicit
Similar to visualising, making process policies explicit exposes disagreement which allows us to resolve conflict.  In general, making knowledge about how things work explicit is a democratising action.  When only a few people really know how and why things are done, they make all the decisions on how to improve; when we all know how and why, we can all participate in the decisions.

Improve collaboratively and scientifically
Every other Kanban property is about exposing the situation and problems.  The final property is the response.  Improve collaboratively because involvement in change leads to commitment to change.  Improve scientifically because otherwise we're more likely to just change and not actually learn and improve.  Improving scientifically means actually making a prediction about the effect of an intervention and re-assessing our model of reality when the intervention results in worse or even better performance than predicted.

Kanban is not the common solutions that the community uses but it's useful to know what they are
Although Kanban is officially referring only to the The Kanban Method, it's useful to also consider the typical Kanban-ish solutions that the community uses:

• kanban typically in the form of kanban boards (aka heijunka boards)
• Some variant of MMF (Minimum Marketable Feature), BVI (Business Value Increment), MVP (Minimum Viable Product), etc.
• Cumulative Flow Diagrams
• Statistical Process Control charts, especially for cycle and lead time
• Multiple cadences
• Classes of service
• Greatly simplified estimation
• Etc.