Kanban from the Inside – Summary – Part 3

This is the third part of the summary of the book, Kanban from the Inside by Mike Burrows.


STATIK –  Systems thinking approach to Introducing Kanban

Six steps

  1. Understand sources of dissatisfaction
  2. Analyze demand and capability
  3. Model workflow
  4. Discover classes of services
  5. Design Kanban systems
  6. Rollout

STATIK helps to connect a Kanban implementation to the needs or the Organization.  STATIK requires you to capture multiple perspectives.

Chapter 18 – Understand sources of dissatisfaction

Any kind of deliberate change requires two key pieces of context

  • its scope – boundary around what we do now within which the change will be focussed  – the “what of the change
  • its objective an expression of what we hope to achieve from the change, relative to how things currently are – they “why of the change

It is better to start with sources of dissatisfaction because

  • they lead to something positive – a set of things people might want to achieve.
  • And to get a perspective of those working within the system and those outside the system.

Two questions

  1. From your personal perspective, and from what you perceive from others inside and outside, what are the main sources of dissatisfaction with the system? In other words what needs and whose needs aren’t met
  2. What sources of variability and unpredictability would you highlight? In other words what frustrates you and the broader system as you try to deliver things of value with quality and timeliness

Both questions are about needs and the systems current capability to satisfy them.

These questions could be discussed in the following ways

  • going out and talking to people individually
  • gathering people together in a workshop and asking those questions and exploring them
  • in a workshop online setting, using facilitated exercises to generate and organize a large quantity of responses

One of the ways of coming out with the discussions is

  • ask participants to write one sticky note per issue to write their dissatisfactions down
  • gather and cluster – the sticky notes, have closely related items stacked together / eliminate duplicates
  • choose a name for each cluster – some
  • do a dot voting – each participant having 3-5 votes and rank the items by the number of votes received.

Another option is to rely on the opinions of few key people (HIPPO) – though not recommended.

Organize and explore

A good facilitator knows not to allow this information generating exercises to converge prematurely on too narrow a range of results.  Stick to the language of dissatisfactions and frustrations – not solutions

Take care to explore needs without assuming particular solutions.

Finally share, invite feedback, refine.

What would you have achieved?

  • shared understanding and agreement on dissatisfactions – the beginnings of a case for change that a wide range of stakeholders will have already bought into
  • some kind of sponsorship or at least a good idea of where to seek it

Chapter 19 – Analyze Demand and Capability

This is about gathering some specific quantitative and qualitative facts about the current process that will inform the design of the Kanban system


  • understand different types of work that will help you identify different variations in the workflow that need to be managed
  • understand different sources of work that will help you prepare for and manage demand
  • understand why work is needed – the types of risk involved and how they can be managed appropriately


  • understand quantity of work involved – to help you choose a manageable granularity to visualize and control it
  • understand the gap between actual process capability and expectations of customers and highlight the improvements needed
  • quantitative analysis of work recently delivered and currently in progress – to tell you where improvements are likely to be found

Knowing what you are delivering to whom and why


  • get to understand from various participants what are working on, how work is organized, what gets delivered etc – in short the process flow

To whom

  • can refer either to the downstream activity or function or to the ultimate customer. Often there are multiple to whoms in which case it is worth finding out
  • whether the workflow involved differs by customer


  • This is a follow up of what and to whom – to set up the why question. Why does the customer need them?  What is the impact to them of faster or slower delivery?
  • Does our process or product strategy meet their needs effectively enough?

Quantitative analysis

Questions like

  • How often do we deliver
  • How many items go in each delivery
  • How long do typical deliveries take?
  • How many items are currently work in progress – what is their age profile
  • Try to visualize using histograms, graphs, Pareto charts, CFDs etc

Flow efficiency

This is one impactful metric – it is the ratio of touch time to the overall lead time between defined start and finish points expressed as a percentage, Touch time is the total amount of time a work item spends actively being worked on.

How work arrives

For each type of work, find out

  • how does it arrive
  • at what rate does it arrive
  • does work arrive in large batches or bursts
  • what are key measures of success
  • how well do they align with customer outcomes

Armed with this information, you will have a good feel for

  • what gets produced, in chunks of what size and how often
  • what gets asked for, how, when and why
  • how much work lies between and for how long
  • the dissatisfactions of those outside the process
  • the frustrations of those inside

Chapter 20 – Model workflow

This chapter looks at 3 different approaches to modelling the workflow that our Kanban system is going to support

  1. sketching it out
  2. top down decomposition
  3. bottom up organization

Sketching it out

  • a formal business process or a value stream mapping can be used or any other process which comes out with the high level flow

Top down decomposition

  • writing down a very rough answer via a couple of guiding steps and refining a little
  • this would include
    • identifying your commitment points – the points at which you first commit to start building or servicing something to deliver/ deploy
    • give category names to the states or activities before between and after – e.g. backlog, engineering implementation
    • break down category names in a way that reflects the reality on the ground – backlog -> received, estimated, prioritized / engineering -> development, test
    • Identify the queues where work waits between active states and refine if necessary. e.g. in To Do / Doing / Done scenario, ask the following questions
      • Are there different degrees of To do? Do we organize e by activity or priority
      • what happens in “doing”
      • are there different degrees of “done” – how do we find out if it is really “done”

Bottom up organization

Instead of modelling the work flow, organize the work items that we have.  Questions like

  • what does this item need
  • what will this item need before it is more like that one
  • what will this item need before it can become complete-
  • how did this item get to here

Chapter 21 – Classes of Service

Classes of service are categories associated with customer expectation and schedule sensitivity.

The 4 categories are

  1. expedite – work items that are so urgent that we will drop other work in order to give them immediate attention
  2. date driven or fixed date – work items whose delay beyond a specific date will result in a significant penalty being incurred
  3. standard – urgency driven work to be delivered in some customer agreed order or sequenced as per policy
  4. intangible – system improvements, maintenance upgrades experiments in technology or market whose direct business value is hard to quantify

These classes should ideally be

  • easily recognized in advance
  • require different handling scheduling and risk management intenrally
  • will influence reasonable expectations externally

Discover, Check

For each work item

  • are all items treated as though they are equally urgent
  • what choices are offered to the customer
  • are these SLAs in place – are they effective
  • what items are getting special treatment

Typically, fixed date comprise 20% of the workload, intangible – 10-20% and a realistic provision for expedited unplanned work – the majority should be for high value urgency driven work

Classes of service and other categorizations enable some broad brush prioritization decisions, have them aligned to wider corporate priorities and match them to  customer needs.

Chapter 22 Design Kanban systems

Scope, Work Item granularity, Work item states

These 3 parameters are best decided together – the scope shouldn’t be too large, granularity not too small and work item states which changes at periodic intervals

Also depends on who is the board for – and the purpose of it – a board designed for CIO could be different than that for a team

Sequential States

This could be Backlog  – > Engineering  – > Implementation  – > Done  with Backlog subdivided into -> Received, Estimation, Prioritized / Engineering -> Dev, Test

Parallel states

It isn’t always possible to arrange states in a strict left to right sequence – especially when some state changes happen in parallel.   e.g. work may proceed optimistically allowing approvals to be recorded after work has started or work may get blocked on a technical, quality or business related issue  at any stage in the process.

So here checkboxes could be one of the ways to make things visible  –    Use of pink stickies could denote blockers


The blocker sticky technique is often used to indicate the presence of defects.  Ideally work items should not advance to the next stage if it is known to be defective  or the item, if needed to advance to the next stage can be flagged with a pink stickie – but again it is a call taken by the team / product owner


This covers two concepts – dependencies between work items and work items that require attention from other services.  Here you could either

  • show the dependent work item as blocked
  • Move to the work item to a holding area

Other dimensions

If there are a large number of work items to be visualised, it is better to organize them by additional dimensions such as

  • work item type and/or class of service
  • source
  • some kind of less permanent category – initiatve project epic sprint etc
  • work item’s owner

The two main choices for representing these dimensions visually are

  • at a ticket level using some combination of ticket colour, annotation or adornment.
    • default colour of yellow sticky for standard work items
    • amber for date driven work
    • red for expedited work items
    • An annotation denoting the sprint for which the work item was committed
    • marking the ticket with the initials of owners
  • adding lines to demarcate horizontal swim lanes across the board or part of it – g.
    • a permanent swim lane dedicated to expedited items
    • swim lanes dedicated to teams or people
    • Swim lane that organize work items by project and so on ..

Limiting WIP

A true Kanban system incorporates some mechanism for limiting the amount of work in progress.  There are numerous ways to achieve this

  • numeric WIP limits, each controlling the amount of WIP in a single column / span of columns / horizontal swim lanes
  • physical constraints such as the number of horizontal swim lanes available
  • limits of the number of tokens (eg personal avatars) in circulation and attaching them to tickets
  • policies that control for example the WIP per person or class of service
  • some external mechanism that releases work into the system only when there is capacity


It is a good idea to review the board design before deeming it to be your initial one..

  • How does the board look when populated with work items? Does it organize them effectively? is there enough  room?
  • How much movement will we see between Standups ? Not enough? Too much?
  • Is it understandable by its intended users? too complicated ? too simplistic
  • Does it make unreasonable demands or assume changes of process, organization or role that aren’t yet agreed upon?

A good design addresses multiple needs of a broader nature:

  • it brings transparency to what is happening and how it happens, helps better decisions to be made and encourages self organization and collaboration.
  • it helps to bring balance between demand and supply – across different categories of demand
  • it encourages both thought and action with respect to customer focus and flow
  • in what ways does this design begin to address the specific dissatisfactions and frustrations you captured at the very start of the process.

These review considerations apply not only when designing a board for the first time, but evolving it too.

Chapter 23 – Rollout

Kanban implementation is a 3 stage process

  1. planning the engagement – preparation in terms of participants, venues, tools, supporting materials etc
  2. shaping the agenda – approaching STATIK with the explicit aim of producing a compelling set of agreed upon priorities, goals and actions,
  3. pulling change through the system – maintaining momentum into the future ensuring that the progress would be both visible and meaningful

Planning the engagement

It is important to prepare properly ahead of any engagement.  As a facilitator, these are the kinds of questions that you need to ask yourself when planning to use  STATIK

  1. understand the sources of dissatisfaction
    • Do you have a rough idea of the exercise
    • Who should participate? Who would represent the people who work inside the presumed system boundary? Who would represent the system’s customers?
    • What tools will you use to solicit and organize a good range of responses
  2. Analyse demand and capability
    • Are you ready to capture the “what, to whom and why?
    • Will you ask for some data in advance or will you wait to see what other participants want to do? What support can you provide?
  3. Model workflow
    • What is your preferred approach (sketch, top down, bottom up)
    • Are you armed with searching questions for reviewing the output
  4. Discover classes of service
    • Will you get more traction approaching classes of service as an internal tool for organizing and scheduling work or as a way to explore customer expectations?
  5. Design Kanban systems
    • how will you introduce the concepts and share what has worked elsewhere
    • how much time would you want to spend refining designs before allowing them to be tried in the field
    • physical or electronic – what limitations with respect to physical, geography, organization, privacy and security would need to be accommodated

Shaping the agenda

Positioning, Purpose and Priority give a high level shape


How you choose to engage with the organization and its people will depend both on context and your own preferences.

Positioning is based on

  • the Kanban method has been described as the humane – start with what you do now approach to change
  • Explore principles, practices and values thinking how they apply in our situation
  • Take a look at “what we do now” – using what is known as the Kanban lens. This encourages us to recognize that
    • what we do – our flavour of creative knowledge work is service oriented
    • service delivery involves workflow
    • work flow involves a series of knoweldge discovery activities
  • through a series of exercises we will do the following
  • map our knowledge discovery workflow
  • pay attention to how and why work arrives
  • equip ourselves to track work as it flows across and between services

– To ensure this exercise’s success we will take time to

  • agree on the scope and purpose of the system under review
  • identify sources of dissatisfaction which we will do from multiple perspectives
  • prioritize actions that begin to address those dissatisfactions and between align the design and operation of the system to its purpose


  • Understand the purpose of the system
  • Identify gaps and measures of success will help focus on the subsequent design activities and help in the rollout


It is important to prioritize the values and identify a top three or four around which a compelling call to action can be built.

  • Kanban values exercise
  • Kanban knowsy group game

Pulling change through the system

  • Good reference points – the Kanban kick start field guide by Christophe Achouiantz and Johan Nordin, Pull based change by Yuval Yuret and Lean change Method by Jeff Anderson.
  • Allow small increments of change to be pulled from a backlog and have it managed through to implementation
  • Use of Kanban Depth Assessment tool to prioritize practices that should be implemented / prioritized or focus on dissatisfactions or problems using these as a driver for change.
  • Identify increments of change
  • Give a score from 1 to 4 to the following
    • Our system exhibits this aspect barely, if at all
    • our system is somewhat capable of exhibiting this aspect
    • our system exhibits this aspect convincingly for the most part
    • our system departs from this only very exceptionally – we manage the consequence when it does so


  1. Work items are organized visually by type, stage, waiting in a que, parallel work stream and class of service
  2. It is clear which items are blocked and for what reason
  3. To the extent that it matters, it is clear who is working on what
  4. Explicit policies capture shared expectations on work item selection, quality criteria and so on
  5. The progress of the work and the overall effectiveness of the system are subject to review at a range of cadences – from at least daily to quarterly and longer.
  6. Attention is paid to how progress demand and capability are reported both to the customer and the wider organization
  7. Metrics have a clear relationship with the system’s purpose


  1. WIP is limited such that no individual activity or work stream is overburdened or is consuming a bigger share of available effort or shared resources that is appropriate
  2. Work is pulled into and across the system only when capacity is available
  3. WIP limits apply to work started but not completed
  4. The system comfortably accommodates a variety of schedule risk profiles (date driven / urgency driven) and classes of service
  5. In allocating capacity between competing sources of demand, consideration is given to the needs of all stakeholders and to the overall capability of the system over a broad range of time spans


  1. Improvements are framed and structured as experiments and managed visually
  2. Other bodies of knowledge are used as models for improvement
  3. Collaboration is embraced as a source of performance , driver of improvement and an antidote to system generated frustration
  4. The system is open to change from the inside (Self organizing) as it pursues fitness for purpose

Customer Focus

  1. the delivery workflow is understood to be a process of knoweldge discovery, in whcih needs, possibilities and capabilities are explored
  2. upstream of defined commitment point, work items are managed as options
  3. downstream of delivery, work items continue to be managed until their utlity in the hands of the customer has been validated


  1. Work items are sized and selected to achieve a strong and reliable flow of value
  2. Batches are sized and releases scheduled to maximize overall economic outcomes
  3. Work items of exceptional value and risk are managed appropriately
  4. The system reliably delivers non exceptional work items with appropriate predictability
  5. Measured end to end, time spent in active knowledge discovery dominates time lost to delays (queuing, multi tasking, blocking) and other kinds of work
  6. Dependencies between work items and on other services are identified and visualized in good time
  7. Work items can be scheduled for release independently of their commitment to the system

Leadership and Leadership disciplines

  1. Leadership is open to all, acts of leadership that bring about change are worthy of celebration
  2. There is a shared and ongoing commitment to change – based on an evolving understanding of what we do now and its alignment to purpose from the perspective of stakeholders
  3. Evidence of the need for change is kept close to the surface
  4. Change is safe, its downside risks are identified and mitigated
  5. The potential benefits of change are watched and nurtured
  6. Change is implemented through agreement, the practices of change and the capability to change are themselves focuses for improvement
  7. Respect is always a given – at times of change people’s attachment to their current roles, organization and practices is never underestimated

Visualizing the change

  • Use of radar charts to visualize progress of changes.
  • Jeff Andersen in Lean Change canvas – uses Agree or Urgency / Negotiating the change / Validate adoption / Verify performance

Not all change is alike

  • Kanban is not about fire fighting or managing existential crises – but if you find yourself needing to react in such a situation, it is possible Kanban will help
  • Introducing Kanban is usually a proactive change and is designed to generate further proactive change
  • Kanban is not just about improvement – but it is also about ambition

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s