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.

Estimates as Sensors

Note: this is not an April Fool – honest!

I’ve been watching the #NoEstimates conversations with interest and decided its about time to pitch in with my own perspective. I don’t want to take any ‘side’ because like most things, the answer is not black or white. Estimates can be used for both good and evil. For me they are useful as a sensing mechanism. Put another way, by estimating, I can get a sense of how well I know my actual capability.

Lets take an example. I’m taking part in a 10K run this Sunday (*) and I am estimating that I will complete the distance in 55 minutes. This is based on an understanding of my capability from participating in regular 5K runs, and more general training runs over a 10K distance. I’ve never run an official 10K race, let alone this course, and I don’t know what the conditions will be like, but I’m aiming for 55 minutes. If I run quicker and do better than my estimate, then my actual 10K capability is better than I thought. If I run slower and do worse than my estimate, then my actual 10K capability is worse than I thought. Either way,  I will learn something about how well I know my 10K capability.

What helps even more with that learning is regular feedback! I use MayMyRun on my phone to track  progress and give me feedback every kilometre for total time, average pace and last split. This could be considered a distance-based cadence. I could probably also use a time-based cadence to give me equivalent feedback every few minutes. This feedback on a regular cadence helps me decided whether my estimate was way off, or if I should slow down because my pace is probably unsustainable, or speed up because I feel I can push harder.

How does this relate to product development? Well, we can use estimates in the same way to get a sense of a teams delivery capability, and use regular feedback to learn whether we’re making the progress we thought, and need to re-plan, slow down or speed up. Time-boxing, with Story Point estimates and Velocity can provide this time-based cadence and feedback. Alternatively, how long it takes to complete 10 User Stories can be used as a distance-based cadence and feedback.

To sum up, I recommend using estimates to sense capability and create feedback for yourself. I don’t recommend using them to make promises and give guarantees to others. Or maybe we could just call them sensors instead of estimates?

(*) Of course this post is primarily an excuse to invite readers to sponsor me. If you’re so inclined, or would like to show support for this post in a charitable and financial way, then please head over to my JustGiving page and do so there 🙂

Update: My final time was 49:23 based on the timing chip, or 49:30 from the starting gun. I’ve learned that I’m better than I thought I was, and next time I’ll be estimating 50 minutes!

Three Kanban Reminders

I seem to have had a number of conversations recently which have all had some common themes. The general pattern has been that someone wants to talk about Kanban and let me know how its not working for them in some way. When I enquire further, and dig into the background some more, I’ve found that there are generally 3 things missing or misunderstood.

  1. You still need discipline. I hear of teams who find traditional agile practices difficult, for various reasons, some which may be valid, and some which may not. They decide to drop those practices, which may or may not be due to a lack of discipline. Dropping those practices, and just keeping the board, does not mean they have a Kanban System. In fact, if the board doesn’t have WIP limits, its not really even a Kanban Board! Whether or not teams have the discipline to follow their original process, they do need to have the discipline to define their own process by creating explicit policies.
  2. You still need cadence. The most common instance of a dropped practice that I hear is that of the time-box. The complaint is then that the team loses their rhythm, and that they have nothing to give them short term focus. They lose their sense of capability. What they have done is gone from a tightly coupled metronomic cadence, to an asynchronous, random and imperceivable cadence. There is a middle ground of a loosely coupled, poly-rhythmic cadence which is more resilient to the nature of their work, yet provides an ability to sense. As described above, it takes discipline to define this cadence.
  3. You still need people. The last misconception is that a Kanban-based approach is removing people from the equation again by trying to simply optimise the current process. Personally, this is why I talk about increasing Potential as one of the impacts we want a Kanban System to have. The potential of a system – its ability to improve over time – is grounded in the human potential of the people who are a fundamental part of the system. Its the people, and their connections and collaborations, who are best placed to know how to change the system for the better now, and be able to continue to change the system as the landscape changes.

I believe that attendees at the recent Kanban Leadership Retreat in San Diego were having similar experiences and I saw on twitter that the phrase “there’s a lot of sh*t out there” was used! This is partly why I came up with the Kanban Thinking model. As I alluded to when I talked about Cargo Cult Kanban, the Kanban community is not copying Toyota’s Kanban implementation tool, but the thinking behind it. If you trying a Kanban-based approach and its not working, think about why, identify something to change, and run an experiment. See, its not really that different to Agile!

 

Kanban and Quad Biking

I’ve recently been using a newer language to describe the model I apply when introducing Kanban to teams, which has been generally working well. I now talk about:

  • Studying – understanding the current system structure
  • Envisioning – creating a common mental model of the system
  • Limiting – bringing the system under control
  • Sensing – having an awareness of the system’s performance
  • Learning – improving the system’s capability

imageAt the Kanban Leadership Retreat in Reykjavik this week, I talked about sensing and was teased by Daniel Vacanti about how fluffy it sounded. (To be fair, I was giving as good as I got). Later that evening in the bar, I was chatting with Katherine Kirk, and I realised why it sounds fluffy. It’s because sensing is not just about the mechanics of measuring the process the capability of a system. Its also about the human aspects of a system, which are too easily forgotten. So for now I’m going to stick with it.

And that brings me to quad biking.

The day after the Leadership Retreat, a small group of us went quad biking over the Icelandic landscape. Its an amazing way to see the country and highly recommended. While I was driving over the rocky ground, I realised it was a great metaphor for sensing.

To begin with, it takes a bit of time to get used to driving the bike. More control is needed while learning the basics. When driving at speeds up to 70kph, however, you’re never actually in full control. The more firmly you try to gain control, the more likely you are to lose control. I soon realised that by gripping and steering too tightly, I was getting thrown about too much when I hit a large hole or rock. By holding more loosely, relaxing, leaning back and going with the flow, I could sense how the bike was behaving and move accordingly. By doing so, I learned that when going round tight corners, pushing the steering to force the bike round was hard work and ineffective, but leaning back and pulling the steering was a lot easier and more effective.

This is why I like sensing as a word to describe the way I work with kanban systems. While establishing a cadence and measuring are key ways that we can understand capability, sensing describes a more instinctive awareness of how a kanban system is performing, and conveys the way teams are able to adapt, anticipate and experiment as they explore the limits of the system.

Katherine Kirk has also taught me about equanimity, “a state of mental or emotional stability or composure arising from a deep awareness and acceptance of the present moment.” Sensing a kanban system involves having equanimity when  dancing with the system.