“Kanban for skeptics” is a book describing the purpose of Kanban and withdrawing any arguments against or any misconceptions. In general, folks regularly have misunderstandings regarding concepts, frameworks, and methodologies… in that perspective I like the intention of the book.

Some might say the book is not a traditional explanation to a subject, which is the case – on the other hand that was not the intention of the book. If you’re new to Kanban, I do think you learn quite a lot by reading this book. I also think the arguments and explanations given are quite useful and make sense (at least to me). It does show the power of Kanban as a process improvement and change management tool.

In summary and my key take-away: Kanban is in essence a change management approach and vehicle (I don’t like saying a “tool”).

Kanban leads to establishing a continuous flow based on a pull system, by limiting the number of items in progress and subsequently forcing an organization to implement sustainable process improvements. Limiting the work-in-progress surfaces the obstacles in a current progress (cf. the powerful lean metaphor of rocks in the lake).

The goal of Kanban is to maximize end-to-end flow efficiency by removing bottlenecks, redesigning the process flow when necessary and focusing on delivering work fully completed. The aim is to make the flow well-balanced, so that the stages in the flow are close to the defined throughput limits. Control is exercised by an approach of monitoring and measuring throughput times (lead and cycle times) (and not estimations). Delivering steady business value occurs when a continuous flow is in place that consistently delivers work items finished on a regular basis at a speed that matches the needs of the organization.

I’ve noticed clear similarities between Kanban with other agile frameworks (i.e. Scrum):

• The goal is to deliver business value, based upon customer demand (in Scrum: value is managed by the product owner)
• The team pulls work from a single source: a list of work items (i.e. a backlog or queue).
• One defines a set of rules to define when an item is considered ready to be pulled into the flow (definition of ready): in Kanban: you can set the rules per stage of the workflow
• Transparent way of tracking progress
• Lean rocks-and-lake principle: impediments and obstacles in processes will become painfully visible – this triggers the need for change and facilitates organizational change
• It leads to better processes, by incorporating feedback and by building upon a momentum to improve a process (as in a Scrum’s retrospective)
• It leads to better collaboration in an organization (if you want to improve, you’ll need to break out of your organizational unit/silo) (Scrum: resolving organizational impediments + cross-functional team work)
• Kanban limits work-in-progress by process step, by lane. Scrum limits work-in-progress by sprint.

I’ve noticed differences Kanban with other agile frameworks (i.e. Scrum):

• Kanban works with measurements – no estimates (note: in agile there is a stream of thinking to work without estimations: on the contrary, the Scrum guide does specify that a product backlog item must have an estimate)
• A flow in Kanban is measured by lead / cycle times; in Scrum you measure by done work compared to planned work (velocity of a team)
• Kanban is less prescriptive compared to Scrum (not that Scrum is very prescriptive, in my humble opinion; at least compared with traditionally project/process management methodologies…)
• Kanban focuses on fully done work (due to the work-in-progress limits); in Scrum the teams defines itself their meaning of work done (note in Scrum the goal is to deliver actual working software at the end of the sprint)
• Kanban starts from the existing process; Scrum does pre-scribe a specific process with specific roles and responsibilities. Kanban does not require you to change your organizational way of working to get started.

I’ve noticed that you can incorporate many agile techniques into Kanban – although Kanban does not prescribe it – this is optional and depending what fits the needs and the context:

• Prioritizing the input queue (Scrum: product backlog) – this is a good practice as it enforces the stakeholders on focusing on the value of items in the queue
• Planning with relative estimates (estimate by comparing items)
• Planning by having relatively well-sized features (INVEST)
• Introduce iterations > regular cadence (iteration as a heartbeat)
• Daily scrum > team coordination
• Cross-functional team (instead of silo-teams) – by defacto in Scrum
• Build a minimal viable product (to start learning as fast as possible and to improve your product based upon real user feedback) – this is a lean concept; but anyhow considered a recommended practice for product development

Any choice of adding a particular practice is situation and context dependent and must be done with consideration.

All this confirms for me that Agile and Lean are blending philosophies.

The questions and reflections I had after reading this book:

1. To enforce work-in-progress limits in Scrum (when necessary)
2. Some general recommendations how to reach a steady continuous flow?
3. When precisely to adjust the work-in-progress limits?

More reading

Scrum and Kanban: Making the Most of Both
Simple, short and to the point comparison of Scrum and Kanban

Small notes: since the writing of this book, some minor, but important modifications have been done to Scrum:
– a team forecasts the amount of work it can do in the next sprint (it does not commit  anymore)
– a burndown (or burnup) chart has become optional

Scrumban book
Book elaborating how to use Kanban on top of Scrum