What are the "pillars" of the Kanban process?

Question

The Scrum Guide states:

Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

What are the pillars of the Kanban process? Are they the same or is something different?

N.B. I understand that Kanban surely has transparency via kanban board or other information radiators; inspection is also done regularly and there are even explicit rules for adaptation towards finishing expedited items or managing the delivery process. Nevertheless, the quote is from the Scrum Guide, which is a different framework.

Answer 1

TL;DR

What are the pillars of Kanban process? Are they the same [as Scrum] or is something different?

Kanban doesn't define "pillars" in the same sense as Scrum. However, as one of the core agile methodologies, it espouses a set of rules and principles that do map to the same agile objectives. The current set of six practices (described below) collectively map to the pillars you describe.

The Kanban Method

However, David Anderson's Kanban Method describes the following four basic principles:

• Start with existing process
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities and titles
• Leadership at all levels

Kanban, which grew out of manufacturing, describes the following rules for manufacturing:

• A later process tells an earlier process when new items are required.
• The earlier process produces what the later process needs.
• No items can be made or moved without a Kanban.
• Defects are not passed on to the next stage.
• The number of Kanbans is reduced carefully to lower inventories and to reveal problems.

— Mattias Skarin. Real-World Kanban (Kindle Locations 188-191). The Pragmatic Bookshelf, LLC.

Open Kanban

Open Kanban then defines four key practices:

1. Visualize the workflow.
2. Lead using a team approach.
3. Reduce the Batch Size of your Efforts or Reduce BASE.
4. Learn and improve continuously.

Within these practices, the Visualize the workflow and Learn and improve continuously principles provide the inspect-and-adapt cycle.

Kanban's Six Practices

It's worth noting that most practitioners now accept that there are six key practices:

1. Visualize workflow.
2. Limit Work-In-Progress (WIP).
3. Manage flow.
4. Make process policies explicit.
5. Implement feedback loops.
6. Improve collaboratively, evolve experimentally.

— Mattias Skarin. Real-World Kanban (Kindle Locations 195-206). The Pragmatic Bookshelf, LLC.

Here, there is a much clearer mapping to the Scrum process controls:

• Transparency
  • Visualize workflow.
  • Make processes explicit.
• Inspection
  • Implement feedback looks.
  • Evolve experimentally, because the exposition of this principle refers to the scientific method, which requires both measurements and observation.
• Adaptation
  • Implement feedback loops.
  • Improve collaboratively, evolve experimentally.

While it's not as simplistic as the "three pillars" in your question, and there is some complexity and overlap in the implementation, current Kanban practices do a good job of providing the same things, and can often be smoothly integrated within Scrum, Lean, or even XP implementations.

Answer 2

Kanban isn't nearly as well defined as Scrum. There is no equivalent to The Scrum Guide, as far as I know. However, I can share with you my "pillars of Kanban".

1. Start where you are and continuously improve from there.

   Where ever you happen to be, that is where you are. The best way to get to where you're going is one step at a time. As often as possible or necessary, reflect on where it is you are right now and where you want to go, then course correct to get there. Change and improvement happen in baby steps. Big Bang anything rarely works out well.

2. Make the work visible.

   Both to the team and your stakeholders. Typically done with a Kanban board, but I imagine other visualizations could be invented (always be open to new ideas!). People absorb information best when it's visual. Visualizing your work allows you to spot bottlenecks/issues and address them sooner.

3. Minimize Work In Progress.

   Everyone knows that developers (people in general) are single threaded and terribly inefficient at switching between tasks. Keeping the WIP to a minimum raises the efficiency of your system.

   There are a lot of other reasons keeping WIP to a minimum will raise a systems efficiency. This all related to Queue Theory and originated, to the best of my knowledge, from Lean Manufacturing techniques. It can be a bit heady; I recommend you do your own research on both topics.

4. It's not done until it's in production and we should focus on getting the things closest to done, DONE.

   Our work isn't valuable until it's been deployed. If something is almost done, then we should focus on delivering that value.

5. Pull, don't push.

   Pushing work through a system causes backups and bottlenecks. Resulting in a lot of work that's almost done. Pulling from a queue (with a WIP limit), alleviates this and allows our work to flow efficiently through the system.