Understanding SAFe PI Planning with Cynefin


Within SAFe, PI Planning (or Release Planning) is when all the people on an Agile Release Train (ART), including all team members and anyone else involved in delivering the Program Increment (PI), get together to collaborate on co-creating a plan. The goal is to create confidence around the ability to deliver business benefits and meet business objectives over the coming weeks and months – typically around 3 months or a quarter.

To many people this feels un-agile. Isn’t it creating a big plan up-front and defining work far ahead? However, a recent experience led me to realise why its not about the plan, but the planning and the dynamics of the event itself. In Cynefin terms, PI Planning is a catalyst for transition and movement between domains.

Let me explain.

Before PI Planning, and a move into an ART cadence, many organisations are in Disorder, relying on order and expertise when they should be using experiments and emergence. The scheduling of a PI Planning event triggers a realisation that there is  a lack of alignment, focus or vision. In order to prepare for the event people have to agree on what is important and what the immediate objectives, intentions and needs are. In short, what does the Program Backlog look like, and what Features should be at the top. The conversations and work required to figure are the beginning of a shallow (or sometimes not so shallow!) dive into Chaos.

During PI Planning is when the Chaos reaches a peak, typically at the end of Day One, as it becomes clearly apparent that the nice ordered approach that was anticipated isn’t achievable. More conversations happen, decisions are made about the minimum plausible solution and hypothesis are formulated about what might be possible. This is when action happens as everyone starts to pull together to figure out how they might collectively meet the business objectives and move the situation out of Chaos into Complexity.

After PI Planning there is still uncertainty, and the iteration cadences and synchronisation points guide the movement through that uncertainty. Feedback on the system development, transparency of program status and evolution of the solution are all necessary to understand progress, identify learning and inform ongoing changes. This may require subsequent dips into Chaos again at future PI Planning events, or over time the ART may become more stable as understanding grows, and PI Planning in the initial form may eventually become unnecessary.

It is this triggering of a journey that makes me believe that PI Planning, or equivalent “mid-range” and “big-room” planning events, are a keystone to achieving agility at scale for many organisations. I wonder how this matches other’s experience of successful PI Planning meetings? Let me know with a comment.

A Kanban Thinking Pixar Pitch

I’ve been using the Pixar Pitch as a fun way for teams to discuss and explore the problem they are trying to solve by telling a story about what has been happening that led to the need for a kanban system. I thought it might be useful to use the formula to tell a dramatised story of what led me to first try using a kanban approach, and why that led to Kanban Thinking.

The Pixar Pitch

Once upon a time there was a team who were using Scrum to manage their work. They were cross-functional, with a ScrumMaster and Product Owner, developing and supporting a suite of entertainment websites for a global new-media organisation.

Every Sprint they prioritised and planned the next couple of weeks, developed and tested functionality, fixed live issues, released updates when ready, and reviewed and retrospected their work.

And every Sprint the team was unhappy with the way they were working. The Product Owner felt that the developers could be more productive, and the developers felt that the Product Owner could be giving more guidance on what build. Stories were completed, but features took a long time to release as the team thrashed to get the functionality right, meet commitments and increase velocity.

So every Sprint they inspected and adapted. The Spring length was shortened to get quicker feedback. The style of User Stories was adjusted to try and focus more on value. And yet things did’t improve significantly.

One day they decided to stop focussing on doing Scrum, and start using ideas from Kanban, experimenting with some different approaches that they hadn’t previously tried.

Because of that they stopped using Sprints and de-coupled their cadences, reprioritising their ready queue every week, planning only when they had capacity to start new work, releasing and reviewing every fortnight, and retrospecting every month.

And instead of breaking work down into small User Stories that would take less than 2 weeks, they focussed on finishing larger MMFs, which might take months in some cases.

And they paid more attention to their Work in Process, in particular making sure they only worked on one large new feature at a time.

And instead of the Sprint Burndown they tracked their work using a Cumulative Flow Diagram, Parking Lot and Lead Time report.

Because of that the whole team became more focussed on delivering valuable features, were more collaborative in how they figured out what the details of those feature were, and were more reliable in when they delivered them.

Until finally everyone was working well together as a much happier group, delivering much more value, and in a good place to continue to improve.

Kanban Thinking

The point of this story is not to try and make one approach sounds better than another, or to suggest that any approach can be a bad choice in some way. Rather it is that the team learned about what would and wouldn’t work by asking questions about their process and experimenting with all aspects of it. The end result might have ended up being exactly what an expert or consultant might have recommended or coached. That’s OK, because what is important is the understanding that was created about why things are as they are. This capability to solve problems, as opposed to implement solutions, sets a team up to continually evolve and improve as their context changes.

This principle – helping teams to solve problems rather than implement solutions – is what fascinated me about kanban when I first came across it and started exploring how it could be used. Its what ultimately led to the emergence of Kanban Thinking as a model for helping achieve this, and the Kanban Canvas as a practical tool.

Insights from a Kanban Board

Donkey DerbyI was working with a team this week, part of which involved reviewing their kanban board and discussing how it was evolving and what they were learning. There was one aspect in particular which generated a number of insights, and is a good example of how visualising work can help make discoveries that you might not otherwise unearth.

The board had a “On Hold” section, where post-its were collected for work on which some time had been spent, but which was not actively being progressed or had any expectation to be progressed, and which wasn’t blocked in any way. Quite a lot of work had built up in “On Hold”, which made it an obvious talking point, so we explored what that work was, and why it was there. These are the things we learnt:

  1. Some of the work wasn’t really “On Hold”, but were really requests which had been “Assessed” (the first stage in the workflow) and deemed valid and important, but not urgent enough to schedule imminently. This led to a discussion about commitment points, and a better understanding of what the backlog and scheduling policies were. In this case, items were not really “On Hold”, but had been put back on the backlog. In addition, a cadence of cleaning the backlog was created to remove requests that were no longer valid or important.
  2. Some of the work was “On Hold” because while it was valid and important, the urgency was unknown. It was an “Intangible” class of service. As a result it was always de-prioritised in favour of work where the urgency was clearer. For example work to mitigate a security risk wasn’t going to be urgent enough until the risk turned into a genuine issue which needed resolving. To avoid these items building up, and generating even greater risk, a “Donkey Derby” lane was created as a converse of their “Fast Track” lane. Work in this lane would progress more slowly, but at least there would always be at least one “Intangible” items in process.
  3. A very few items were genuinely “On-Hold”, but they were lost amidst the noise of all the other tokens. Thus any discussion about what to do, or what could be learned, was being lost.

In summary, by visualising the “On Hold” work (however imperfect it was), and creating a shared understanding, the team were able to improve their knowledge creation workflow, better manage their risk and increase their ability to learn from their work.

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.

Strategy Deployment, the X-Matrix and Kanban Thinking

Strategy Deployemnt

Kanban Systems are an enabler of evolutionary change. And so is Strategy Deployment. Strategy can be defined as how you will make a positive impact, and this implies change. As the saying goes, “hope is not a strategy”, and neither is doing nothing. Deploying that strategy, as opposed to defining and imposing a tactical plan, enables the evolution of the tactics by the people implementing them.

I have found that putting Strategy Deployment in place is my preferred approach to starting off any change initiative, and that as suggested above, there is a strong synergy with a kanban-based approach. (This is not surprising, given the roots of both in Toyota and Lean). In particular, I have been using a format known as the X-Matrix to setup Strategy Deployment.

The X-Matrix

The X-Matrix is a cornerstone of Strategy Deployment. It is an A3 format that provides a concise and portable shared understanding of how strategy is aligned to the deployed tactical initiatives, alongside leading indicators of progress and anticipated end results. I learned about the X-Matrix from the book “Hoshin Kanri for the Lean Enterprise” by Thomas L. Jackson, and I have previously blogged about how we used the approach at Rally.

CD Form 1-2_A3-X X-matrix

The X-Matrix has 5 primary sections, all of which are connected. At the bottom, below the X, are the results that we hope to achieve. To the left of the X are the key strategies that will get us to those results, and to the immediate right of the X are the measures of improvement that indicate how well we are doing. (Note that this is labelled process as it refers to process improvements). At the top, above the X, are the tactics that we will use to implement the strategy. Finally, on the far right are the teams that will be involved in the work. To link these together, the corners of the X-Matrix are used to show the strength of correlation or contribution between the different elements.

Thus it becomes easy to visualise and explore how a strategy, or a measure, correlates to achieving results. Similarly, it is easy to see and discuss how a tactic will correlate to achieving a strategy, or how it will contribute to moving the needle on a measure. And it is clear who is accountable or involved in each tactic. Having all this on a single page helps creating clarity and alignment on the why, how, what and who of the work.

Kanban Thinking

This works well because it wraps all the elements of Kanban Thinking nicely. The results are equivalent to Impacts, the process improvement measures are ways to Sense capability, the strategies can be derived from exploring various Interventions and the tactics are the experiments created to Search the landscape. (Note: While all the examples I have seen have financial results, focussing on value based impacts, there is no reason why flow and potential based impacts could not be forecast with alternative results).

What I really like about Strategy Deployment, and the way Jackson describes it in his book, is that it is a form of nested experimentation. From an organisations long-term vision, through its strategy, to tactics and day to day operations and action, each level is a hypothesis of increasing granularity. As each experiment is run, the feedback and learning is used by the outer levels to  steer and adjust direction. Thus a learning organisation is created as the learning is passed around the organisation in a process known as ‘catchball’, and within this context, Kanban Thinking (and the Kanban Method) provides a synergistic means to running experiments and creating learning.

Do you know what results your organisation are aiming for? Do you know the strategies being used and how they should lead to the results? Do you know what improvement measures should indicate progress towards the results? Do you know how your tactical work implements the strategy and which indicators it should improve? Are all these elements treated as hypothesis and experiments to create feedback and learning with which to steer and adjust?

If you’d like help answering these questions, using the X-Matrix, let me know!

Making System Interventions with Kanban Thinking

This post pulls together a number of ideas on interventions into a single place, and will become the content for a page on Interventions on the Kanban Thinking site.

What is an intervention?

An intervention is an act of becoming involved in something in order to have an influence on what happens. It is an active and participatory action, as opposed to a passive and observational instruction. Thus in Kanban Thinking, interventions are ways of interacting with a kanban system with the intent of improving it and having a positive impact.

There are 5 types of Kanban Thinking intervention, which can be considered as heuristics to help the discovery of appropriate practices and techniques for a system’s context. These heuristics may point to the purpose behind known and proven practices, or they may lead to the identification of new and alternative practices. They are:

  • Study the Context
  • Share the Understanding
  • Stabilise the System
  • Sense the Capability
  • Search the Landscape

Study the Context

What could be done to learn more about customer and stakeholder needs, the resultant demand and how that demand is processed?

Kanban Thinking is based on a philosophy of “start where you are now” and the foundation for this evolutionary approach is Studying the Context. In his book “The New Economics”, W. Edwards Deming famously said, “there is no substitute for knowledge”, and it is the acquisition of this knowledge about the current situation that leads to an appreciation of how to improve it.

Various practices are widely used to study different aspects of the system. Empathy Mapping is one way of learning more about customer and stakeholder needs. The work that they request as a result of those needs can be studied with demand analysis and profiling to determine classes of service and response. The way that work is then progressed, from concept to consumption, can be examined using forms of value stream mapping.

Share the Understanding

What information is important to share, and how can tokens, the inscriptions on them, and their placements, provide a single visual model?

Sharing the Understanding of the current situation, typically in the form of a kanban board, creates an environment where people are more intrinsically motivated. The ability to see what needs work provides autonomy, the ability to see where improvements can be made provides mastery, and the ability to see where to focus provides purpose.

Potentially, lots will have been learned from studying the context, so it is important to decide what is the most relevant information to share to avoid being overloaded with too much noise. That information can then be visualised using various patterns based on the acronym TIP; Token, Inscription, Placement. Tokens are the cards, stickies or other tangible representations of the work, where aspects such as shape, size, colour or material can represent different information. Inscriptions are items of information added onto the tokens, where words, dates, pictures or symbols can all be used with suitable formatting. Placements are the Tokens are placed on the board to convey information, where horizontal, vertical and relative positioning can all be meaningful.

Stabilise the Work

What policies could help limit work in process, and remove unnecessary or unexpected delays or rework?

A kanban system which is stable is more likely to be able to evolve and have resilience in the face of change. Systems can be considered to have boundaries or constraints, and those with too loose constraints will devolve into chaos, whereas those with too tight constraints will become brittle with bureaucracy. Stabilising the Work is achieved with enabling constraints, open enough to avoid restriction and prescription, yet limiting enough to stimulate expansion and new possibilities.

Defining work in process limits is a primary means of stabilising the work. One approach is to start with the current work in process (WIP), and look to gradually reduce it. Alternatively, the WIP could be drastically reduced to stabilise quickly, and then gradually increased to a more optimal level. A middle ground could be to base an initial WIP in the size of the team, such as one work item per person. How WIP is spread across the system is also a factor, from a single limit covering everything (CONWIP) to a different limit per stage or column.

WIP is a form of explicit policy, and other common forms are Definitions of Ready and Done and similar, simple quality criteria. Additionally, Test Driven Development can be considered an explicit policy on how software is written to create a stable code-base.

Sense the Capability

What measures and meetings might create insights and guide decisions on potential interventions?

As well as acquiring knowledge on what the work is, and how it gets done, it is also important to know how well it gets done. Sensing the Capability of a kanban system involves getting a feel for its performance by both measuring and interacting with it. Metrics provide an objective, quantative sense of capability. Meetings, and other feedback cadences, provide a subjective and qualitative sense of capability.

Measures should be derived from the desired impact, and the outcomes which would make the impact. If Flow is the desired impact, being more responsive might be a good outcome, and thus Lead Time might be a good measure. Additionally, the subsequent behaviours, both good and bad, which a measure might drive should be considered, and trade-offs can be made by having a set of balancing metrics. A focus on Lead Time might result in a reduction in Quality by cutting corners, so measuring Released Defects could help balance that trade-off.

Meetings provide a cadence with regular interactions can generate feedback. A simple metronomic cadence can tie various events such as planning, reviewing and retrospection to a single rhythm, or a polyrhythmic cadence can decouple these events into multiple rhythms. Another option is for some events to be asynchronous and triggered by the work rather than time-driven.

Search the Landscape

What small experiments could be run to safely learn the impact of different interventions?

Searching the Landscape of a kanban system involves looking at a range of possible interventions and experimenting to discover what impact they have. Those that have a positive impact should be pursued and amplified. Those that turn out to have a negative impact should be reversed and dampened. This searching can be thought of as exploring the evolutionary potential of the present state, as opposed to defining a future state and trying to move towards it.

Defining an experiment involves proposing a hypothesis that has a rationale behind it, can be measured in order to validate or falsify it, and can be easily recovered from in case of unanticipated results. The intentional act of documenting the experiment, using formats such as A3s, encourages disciplined thinking and avoids falling into the trap of retrospective coherence to explain results.

Searching the Landscape is an exercise in continual curiosity about how to evolve and improve the kanban system, increasing impact through further insights, interactions and interventions.

Making an Impact with Kanban Thinking

This post pulls together a number of ideas  on impact into a single place, and will become the content for a page in Impact on the Kanban Thinking site.

What is Impact

Outputs creates Outcomes which have Impact.

Designing a Kanban System involves the evolution and discovery of a good design. It cannot be pre-determined in advance. Thus instead of defining a future-state and working towards it, we start with the current-state and work away from it, exploring and assessing different alternatives. Each output of a design iteration will create different outcomes, and those that improve the system can be said to have a positive impact, while those that worsen the system have a negative impact.

Impact, therefore, describes the disposition of the system, or its tendency to behave in a certain way. Rather than defining a planned destination, impact points to the desired direction, such that we can check whether any changes are moving us towards or away from the direction we want to be heading. Impact can be assessed by using narrative techniques to capture stories about utopian (and dystopian) futures, and subsequently asking whether an outcome is likely to lead to more of the positive stories and fewer of the negative stories.

Describing Impacts

When imagining what impacts would be desirable, its easy for our experiences and biases to lead us to narrow our thinking and prematurely converge on only one particular type of impact. To avoid this, and encourage diversity in exploring a wide variety of potential impacts, Kanban Thinking describes three types to consider, giving different perspectives.

  • Flow. This is Doing the Thing Right. Stories will be primarily related to the process, efficiency and reliability.
  • Value. This is Doing the Right Thing. Stories will be primarily related to the product, effectiveness and validity.
  • Potential. This is Doing the Thing Sustainably. Stories will be primarily related to people, euphoria and flexibility.

Impacts as Triads

When exploring the impacts, it will become apparent that there is not always an obvious and neat mapping to either flow, value or potential. Thus, the three impacts can be thought of as a triad, with each being a vertex of a triangle.

Triads are concept I learned from Dave Snowden and used by the Cognitive Edge Sensemaker Suite (note that they have a patent associated with this), where a triangle is used as a measuring instrument to assess against three parameters. By using triads, impacts can be placed relative to where they have the strongest affinity, without having to decide on any one in particular. Imagine an impact being connected to each vertex with elastic. The greater the affinity to a vertex, the greater the tension, with the final position being a result of the combination of all three. Thus the story in the triad below has the strongest affinity with the Flow vertex. The next strongest is Potential, with Value being the weakest.

Impact Triad

While triads are an approach not directly supported by the canvas in its current form, the deliberate choice of words to describe each impact creates multiple possible triads which could be explored. Deciding where an impact goes generally requires more thinking, and generates greater dialogue and insight.

Thing RightRight ThingThing Sustainably

Generating lots of utopian (and dystopian) future stories, instrumented with these triads, will generate patterns which can give a sense of where the improvement opportunities are for making an impact.


Here’s an example of thinking about impact from the three perspectives. It is intentionally lacking in direct relevance to minimise the risk of biasing your own answers to the questions.

When I go running, I’m generally wanting to improve my health and fitness. What impact do I want to have?

  • From a Flow perspective, impact could be about pace and speed. I could imagine a utopian future where I can run a 4 minute mile.
  • From a Value perspective, impact could be about distance and stamina. I could imagine a utopian future where I can run 100 miles.
  • From a Potential perspective, impact could be about friendship and community. I could imagine a utopian future where I am the president of a local running club.

None of these are mutually exclusive. If I can run a 4 minute mile, then there is a high likelihood that I’ll be involved in a running club, and training longer distances as well. However, explicitly exploring the different perspectives avoids me just focussing on one thing such as speed, to the detriment of friendship or stamina.

What stories would you like to tell about the impact your kanban system makes in the future?

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.

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.

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”.