Kanban Thinking Workshop in London


I have another public Kanban Thinking workshop coming up in London (March 5-6), in collaboration with Agil8, and to fill the last few places, I can offer a discount! Book now, using the code KS25 to get 25% off the standard price, and get 2 days of fun, discover how to design a kanban system by populating a kanban canvas, and learn how to make system interventions which have a positive impact.

To wet your appetite, here’s a couple of photos from a recent workshop. (Click for larger versions).


VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

A Kanban Canvas Example

I’ve been doing the rounds of conferences and meet-ups recently, introducing the Kanban Canvas as a way of becoming a learning organisation. One of the more common requests and pieces of feedback is that an example would be useful. I have mixed feelings about this. On the one hand, giving an example feels like a slippery slope to giving a solution, and brings with it he risk of unconsciously narrowing the field of vision when looking for new answers. On the other hand, its come up often enough not to ignore!

I’ve decided put together a very simple example. Hopefully too simple, and simplistic, to be copyable, but concrete enough to help show how the canvas could be used. Its based on the experience from when I introduced a kanban system at Yahoo! I have taken some liberties in putting it together to keep it understandable – we didn’t formally use this approach, and it was a long time ago!

Click on the image to see a larger version. I have added some commentary about the different elements below.

en_Kanban Canvas v1-0 example


I have described the systemic challenge using the Pixar Pitch format (deferring the ‘Until finally’ to be covered by Impacts). It could be summarised by the the headline “Busy, Not Productive

Once upon a time a team was developing websites using Scrum

Every Sprint the team would struggle to agree with the PO on what they could deliver, and as a result they delivered very little.

One Sprint the team started trying to define smaller stories in more detail up front.

Because of that planning meetings became painfully long, and even less was delivered.

Because of that we tried a kanban system.


There is a single utopian and dystopian future for each Impact, using colour to differentiate. Utopian positive (+ve) impacts are green. Dystopian negative (-ve) impacts are red.


These are related to being able to release functionality early and often

  • +ve: Continuous deployments of new functionality
  • -ve: Websites broken, out of date and shut down


These are related to being a stable and high performing team

  • +ve: People clamouring to be on the team
  • -ve: Massive team turnover. No-one able to make changes.


These are related to being able to build the best product

  • +ve: Award winning websites, putting competition out of business.
  • -ve: No page views or visitors. Ridiculed on social media.



We identified 3 types of work; defects in production, enhancements to released functionality, and new features. These were generally equated to small, medium and large pieces of work.

We were following a basic Scrum workflow of Backlog, In Process, and Done.


To share the work type, we used token size. Defects were on small index cards, enhancements on medium, and features on large. Additionally, token colour differentiated failure and value demand. Defects were on red cards, whilst the others were on green cards.

To share the status of work in process, we used token placement in a matrix to represent progress and quality. The horizontal placement showed progress, while the vertical placement showed quality. Thus a token in the lower right corner was nearly finished, but with unsatisfactory quality.

Completed work was kept visible by keeping its token placement in a Done column until then end of a quarter.


We replaced the backlog with a limited “Ready Queue” to help clarity on what the next priorities were. (This queue would be restocked every week).

Work in Process was limited by work type, focussing on only 1 feature and 2 enhancements at a time. Defects were not limited, but the goal was always to eliminate defects rather than optimise them. Additionally, there was a “Top 5” work items to focus on, which could be of any work type. (We had 5 “star” adornments as token inscriptions to share what the top 5 were).

The goal was to get work into production, so our Definition of Done policy was simply that work must also be approved by the UX, QA and Ops teams and actually deployed and available.


The primary desired impact was Flow, with an outcome of improved productivity being a indicator. This was quantified by measuring throughput of items per week, with an increase being the goal.

A risk, however, was that cutting quality, or optimising for defects, could be a negative consequence of focussing on throughput. This would badly impact both Value and Potential. Thus a count of live defects was also measured, with a decrease being the goal.

The traditional scrum cadences were de-coupled with a new set of cadences put in place:

  • Weekly scheduling meetings to restock the ready queue
  • Planning meetings on-demand when work actually starts
  • Fortnightly review meetings to check progress
  • Monthly retrospective meetings to insect and adapt the process


While experiments were not formally run, there were essentially 2 hypothesis being tested. The first was related to the board design, visualising and focussing on the work types. The second was related to the de-coupled cadences, with work flowing across them.

Wrapping Up

I hope this example shows how the canvas can be used to tell a simple story about what the elements of a process are (the interventions), their context (the system), and their goal (the impacts).

If you’d like to use the canvas, please download it. And if you’d like me to facilitate a workshop which uses the canvas to design your kanban system, then please let me know.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Heuristics for Becoming a Learning Organisation at Spark the Change

InfoQ have just published the talk I gave at this year’s Spark the Change conference on “Heuristics for Becoming a Learning Organisation“. This was the first time I introduced the Kanban Canvas, and gives some background to the questions it asks.

Please follow the link to watch, as I can’t embed it here.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban Canvas InfoQ Interview

Last week InfoQ published an interview that I gave with Katherine Kirk at Agile2014 in which we talked about the Kanban Canvas, why I came up with it, and how I use it. Unfortunately I can’t embed it here, so please use the following link to find it:

Karl Scotland introduces the Kanban Canvas.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Anatomy of the Kanban Canvas

I’ve just added a high level explanation of the anatomy of the Kanban Canvas to the main Kanban Thinking site (where you can downloade the Canvas). I thought I would also post it here.


How to assess the systemic problem and who is experiencing it.

At the centre of the Canvas is the system being worked on.

Assuming that the current situation is not perfect, and there is always room for improvement, then understanding the scope of the system helps focus on the biggest opportunities for improvement and avoids “rearranging the deck chairs on the Titanic”. By thinking about the situation as part of a holistic system, and having clarity on the scope of the system, we are more likely to identifying opportunities which improve the whole, rather than making smaller, local improvements, which might worsen the whole.

This leads to the question of what is the scope of the system. Defining the system to be too small, might not lead to any significant improvements. Equally defining the system to be too large, might be like trying to “boil the ocean”.

One way of understanding the system is to look at the people involved, and explore what problems those people are having. Narrative is an extremely useful form of doing this – finding and telling stories about people’s experiences and frustration with their work. In particular, the stories related to the customers and stakeholders will start to identify the boundaries of the system.

One fun way of exploring the system through narrative is by using the Pixar Pitch. This approach makes the final “Because of that…” refer to the current kanban system design, and the “Until Finally…” is left blank to be explored in the Impact section.


How to assess the fitness criteria in terms of flow, value and potential.

The three arrows coming out of the right of the central System are potential Impacts which might be made. These Impacts encourage a focus on what success or failure could look like, before any changes get made.

Given that in most situations, we are dealing with complex problems, where cause and effect are only apparent with hindsight and past solutions are not necessarily repeatable in the future, then we should not try to define a specific future state to solve the problem. However, that does not mean that we cannot determine the characteristics of the outcomes of solutions so we can assess their fitness criteria, or how fit for purpose a solution is.

Impact is an evaluation of fitness for purpose. A successful solution is one which has positive impact and an unsuccessful solution is what which has negative (or no) impact. Impact can be thought of as direction, as opposed to a point solution being a specific destination.

Having explored the scope of the System through narrative, we can also begin to define Impact in a similar way by asking what stories do we want to hear more of, or less off, in the future. When using the Pixar Pitch technique, imaging impossible good and bad endings to the story brings out exaggerated scenarios which can be compared against by asking whether the System is becoming more or less like the suggested endings. Getting both good and bad endings allows both positive and negative Impact to be easily imagined and identified.

When imagining the future, to create a range of diverse possibilities, the Impacts on Flow, Value and Potential are used to encourage thinking from different perspectives.


How to assess the evolutionary potential in terms of studying, sharing, stabilising, sensing and searching.

The five arrows going into the left of the System are the potential Interventions that could be made. These Interventions provide a frame for appreciating the intent behind various practices, learning and discovering which ways of working are the right ones for the current situation, and transforming those practices as the system continuously evolves.

Working through the interventions encourages continuous curiosity about which tools and techniques to use, understanding when and why they are appropriate, and ultimately collaboratively, co-creating an initial kanban system as a baseline to begin experimenting and improving.

The interventions used are to Study the context, Share the understanding, Stabilise the work, Sense the capability and Search the alternatives.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Draft Kanban Canvas User Guide


This is an initial draft for brief guide to how I use the Kanban Canvas, building on the recently posted Prezi. It will eventually be added to the main Kanban Thinking site. Generally, I use the canvas as the core of a two day workshop, during which I use it to facilitate the collaborative co-creation of a kanban system. The canvas becomes a single, simple artefact which captures a common understanding of how a system is designed, and why it is designed the way it is.


1. First we begin with understanding the scope and purpose of the System. I’m looking to discover key people, problems, frustrations, boundaries and interfaces. I like to get participants to tell their story leading up to the present day, explaining why they are in a room together designing a kanban system.

The output in this section is one or more a simple narratives capturing the essential system elements and interactions.


Next, we need to be able to assess whether any changes we make are improving or deteriorating the systems fitness for purpose. The goal is to be able to describe the general direction we want to go in, without identifying any specific outcomes or end states.

2. We explore various ways we might want the story to end – and what endings might we want to avoid. I ask participants to imagine impossibly good and bad endings – utopian and dystopian futures – using the three Impacts of Flow, Value and Potential to help them look from different perspectives. They are not distinct impacts, but more like triads, where elements of all three could be involved. This generates healthy conversations about how the potential futures relate to the different impacts.

The output across these three sections is a set up potential endings, placed relative to where they have most resonance. Colour coding is used to distinguish between the utopian (green) and dystopian (red) futures.


Now we have a good understanding of the recent past and desired future direction, we can begin looking at how we can start interacting with the system to make interventions which we hope will have a positive impact.

3. To really understand how we can make effective change, we first need to Study the context. There are 3 areas that I find it useful to study; the customer or stakeholder, the work demand that comes from them, and the way that demand is processed. We usually start by looking at demand, and the group applies concepts such as value and failure demand, the CORE Profile and Classes of Service. Then we’ll explore where that work comes from with a technique such as Empathy Mapping, and how that work is processed with a variation of Value Stream Mapping focussing on the flow of information and its discovery.

The output in this section is a set of sticky notes capturing a summary of customer/stakeholder needs, demand classifications and classes of service, and primary workflow states, transitions or delays.

4. Once we have a good common understanding of the existing context, then we can Share it by visualising our knowledge on a kanban board. First I ask the group to discuss and agree which information is most relevant and important for them to share – trying to show everything will just create noise. Then I introduce the Token, Inscription, Placement concept as a way of thinking about board design patterns, and the group comes up with approaches to visualise their important information.

The output in this section is a set of mappings between each important informational dimension to be visualised, and the visualisation technique to be used.

5. The next step is to begin to Stabilise the current system by introducing explicit policies. These policies will form flexible boundaries to contain the work. Boundaries which are too hard and fixed will lead to rigid bureaucracy, while boundaries which are too loose will lead to chaos. I introduce Work In Process limits as a core policy type, and we explore the various strategies and techniques for introducing and setting WIP limits. Then the group brainstorms some simple quality checklists to agree how and when work should progress across the board. These simple, standard work definitions become the baseline for future improvements.

The output in this section is a set of decisions regarding basic WIP limit strategies and allocations, and bullet points for initial entry/exit criteria on the board.

6. As a system is put in place and evolves, we need a way to Sense its capability in order to assess its fitness for purpose. The two primary means for this are measures and meetings. First, groups decide which outcomes they hope will have a positive impact, typically selecting from productivity, reliability, responsiveness, quality, customer satisfaction and employee engagement. Metrics are discussed and defined for these outcomes, considering the anticipated behaviour and consequences, and potential tradeoffs with other outcomes. Then groups decide what meetings and cadences they would like to use to give them an ongoing rhythm for assessing capability and progress.

The output in this section is a set of simple metrics definitions, and a list of meetings and respective cadences.

7. Finally, the evolutionary potential of the system is explored by beginning a Search for alternative designs. Given everything that has been discussed so far, the groups begins to define small experiments that could be run on possible changes. Each experiment has a hypothesis, a rationale, measures to both validate and falsify, and a mechanism for ensuring safety and reversibility.

The output in this section is a set of initial simple experiment definitions which can be run.

All of this is done in a very collaborative way, using various facilitation techniques to ensure everyone is able to contribute, different opinions are heard, and consensus is reached. At this point, the group is able to begin learning, evolving and improving their kanban system using the canvas as a basis.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban Canvas Prezi Overview

Yesterday I gave a brief overview of the Kanban Canvas to a few people in the Open Jam area at Agile2014. I used a Prezi to zoom around canvas, showing the order I generally work through it, with some high level ideas of the sort of content that I explore when filling it in. You can find the Prezi below.

I’ll be iterating on this, adding more detail and turning it into a simple “User Guide”.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)