Kanban: Isn’t it Just Common Sense?

Many problems we are trying to solve in software and product development are complex, with no obvious solution. As a result it is not possible or appropriate to simply define and follow best or good practice. Instead me must think in terms of heuristics to discover contextual solutions. I will describe how we can use Kanban as a set of heuristics to learn what those solutions are.

Bob has just published that podcast. Enjoy!

The theme of the day was exploring how we can help organisations not just build the “thing right”, but build the “right thing”. We spent the morning sharing and exploring the various techniques we used, such as Story Mapping, Impact Mapping, Effect Mapping, Feature Injection, Real Options and Lean Canvas. We then moved onto more general discussion on the problem we are trying solve, before focussing back in on putting something together to try and articulate the commonalities we had found and create a platform to continue the conversation and try and make an impact ourselves.

Henrik has already blogged one statement summarising our conclusions.

Great results happen when:

• People know why they are doing the work
• Organisations focus on outcomes and impacts rather than features
• Teams decide what to do next based on immediate and dircet feedback from the use of their work
• Everyone cares

Another output was what I called “Heuristics for Building the Right Thing”. I mentioned heuristics in relation to Kanban Thinking, and again, the goal was to provide enough guidance for people to learn, without constraining to specific solutions or techniques. We started by brainstorming ideas and then grouped those into 5 themes, before putting some action-focussed words describe the themes. We noticed that there was a general feedback loop that the heuristics formed, and that there was a missing heuristic that was central to everything. Thus we ended up with:

• Understand your customer
• Be Comfortable with Ambiguity
• Co-Create
• Learn Fast
• Make an Impact
• Make it Visible

The key points for me in Mike’s second post are these. First,

We often say what the Kanban method is (an evolutionary approach to change) without saying what it is actually for! Change what? To what end?

and then,

The Kanban method is an evolutionary approach to building learning organisations.

Impact

I have a different take on the values discussion and how they help answer the question “to what end?” I’ve come to the view that articulating values is not a useful exercise because they often end up being things that anyone could espouse. One alternative is to use narratives and parables to describe the values in action. With Kanban Thinking, I prefer to talk about the desired impacts of a kanban system. Knowing what impact we want the kanban system to have, and how to measure that impact, will inform our system design decisions.

Thus, in answer to the question “to what end?”, Kanban Thinking suggests 3 impacts; improved flow (demonstrated in terms of productivity, predictability or responsiveness), increased value (demonstrated in terms of customer satisfaction, quality or productivity) and unleashed potential (demonstrated in terms of employee satisfaction, quality or responsiveness).

Heuristics

Mike suggests that the purpose of a kanban system is to learn, and in light of the above, that would be to learn how best to have maximum impact. Up until now, I have talked about five leverage points (or levers) on a kanban system, with Learn being one of those levers. As a result of the insights I had from Mike’s post I have switched to referring to those five elements as heuristics rather than levers, with the fifth heuristic changed from Learn to Explore.

This is one definition of heuristic:

involving or serving as an aid to learning, discovery, or problem-solving by experimental and especially trial-and-error methods.

and

of or relating to exploratory problem-solving techniques that utilize self-educating techniques (as the evaluation of feedback) to improve performance

Thus, the five (updated) heuristics of Study, Share, Limit, Sense and Explore help with the learning about a kanban system in order to have the desired impacts of improved Flow, increased Value and unleashed Potential.

Exploration is a more active description of what I originally intended by Learning as a then lever. Exploration requires curiosity (another value suggested by Mike) and experimentation to try things out, observe the results, and amplify or dampen accordingly.

That leaves the updated Kanban Thinking model looking like this:

Its going to be a great event to learn about Kanban. As well as my 2 day workshop which will allow participants to practice Kanban Thinking to design a Kanban System, Masa Maeda is also running a 1 day workshop on “Kanban for Success” which will introduce the foundations of the Kanban Method. And what’s even better is they don’t clash, so it’s possible to attend both, learn the basics with Masa, and then apply what you’ve learned with me!

Here’s some more info about the conference:

LEARN…NETWORK…EXPLORE

At Asia’s largest & premier international conference on Agile and Lean Software Development methods. Starting Feb 26th 2013 in Bangalore

Agile India 2013 is a refreshing, yet intense 4-day conferences where you can:

• Learn from experts like Craig Larman, Mary Poppendieck, Rebecca Parsons, Fred George, Jeff Patton, Jez Humble, Linda Rising, Naresh Jain, Neal Ford, Venkat Subramaniam and many other Agile Thought Leaders...
• Network & share your knowledge and experience with over 1500 international delegates from literally every software company practicing or exploring Agile & Lean.
• Explore diverse and interesting solutions and contribute to the future of Agile software development.

Full Conference Program: http://betterconf.com/agileindia2013/index.html (PDF)

Last few seats left, register at: http://booking.agilefaqs.com/view/index.php

• 58000 views
• 30 posts
• 528 views on Feb 2nd.

The top 5 most-viewed posts were:

1. Kanban, Flow and Cadence
2. What is Cadence
3. The Science of Kanban – Introduction
4. Running the Ball Flow Game
5. The Anatomy of an MMF

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!

An Impact Map can be thought of as a structured mind map, with the following levels being used to articulate the various aspects of an initiative:

1. Why – The central node describes the goal of the initiative in a quantative manner such that it can be measured.
2. Who – These are the people who can either be a help or a hindrance in achieving the goal.
3. How – These are impacts that need to be had on the actors for them to either help achieve the goal, or minimise/avoid them being a hindrance.
4. What – These are the deliverables which are hoped will create the impact on the actors to achieve the goal.

There are a number of reasons I like the approach and find it coherent with my experiences.

• Impact Maps build on Simon Sinek’s Golden Circle, which I have written about in the past. The additional Who level helps bridge the gap and identify the different Hows .
• Impact Maps also provides a framework against which to iterate and increment using story maps, feature injection and fidelity. In particular, having the SMART goal means that the development is more likely be stopped at the right time because the the deliverables have had the desired impact, or because they are not having the anticipated impact. Alternatively, development might even be avoided because alternative deliverables are identified which will generate enough impact to achieve the goal.
• The language of Impact Maps is very close the language I use of Impacts, Outcomes and Outputs. For me, the Why is the Impact – it is the overall impact we want the initiative to have. The Who remains the people who can help or hindering achieving the Impacts. The How are the Outcomes which will help the actors achieve the Impact (or minimise/avoid hindrance), and the What are the Outputs required to create the Outcomes.

Regardless of the subtle differences of language, its still a great technique, and is one I’m looking forward to using in the future.

Understanding Systems

Being able to start thinking systemically is not easy, because there are different types of system, and each requires a different approach to working within them. Dave Snowden has developed a framework known as Cynefin, which is a useful way of understanding some of the differences, and the implications of those differences.

Cynefin is a Welsh word, which translates as “place of our multiple affiliations”. Snowden describes it as a multi-ontological sense-making framework. The multi-ontological aspect refers to the fact that there are different types of system, all of which are may be valid for different contexts. The sense-making aspect refers to the exercise of gathering data before creating the framework, as opposed to categorisation where a framework is created first and onto which data is subsequently placed. In practice, this means that examples are first gathered first and placed relative to each other based on some criteria, and then boundaries are then drawn in order to understand the relationships. This allows the emergence of a framework that might not otherwise have been identified.

System Domains

Cynefin has five domains; two ordered, two unordered, and one of disorder.

On the right hand side are the ordered domains simple and complicated. These are ordered because there is a direct relationship between cause and effect. Causality is known and clearly perceivable, predictable and repeatable for simple problems, or it is at least knowable, although less obvious due to separation in time and space, for complicated problems. As a result we can immediately get a sense of the situation first, before categorising or analysing, in or to decide how to respond with best or good practice.

On the left hand side are the unordered domains complex and chaotic. These are unordered because of the ambiguous relationship between cause and effect. Causality may be retrospectively coherent, but not repeatable for complex problems, or simply incoherent and not perceivable at all for chaotic problems. As a result we need to probe with experiments or act quickly and assertively before we can get a sense of the situation in order to know how to respond.

In the centre is the domain of disorder. This is where we are unsure what type of problem we are dealing with and as a result are likely to respond instinctively with our preferred approach rather than the one appropriate for the situation.

The Cynefin framework, and in particular its distinction between ordered and unordered systems, is useful in understanding two common ways of dealing with change.

Managed Change

On the ordered side, in the simple and complicated domains, we can take advantage of expert and common knowledge, using best and good practice, to define a desirable future state, and the work to close the gap from the current state.

This is the approach generally taken by managed change programs, which put together teams, define roadmaps and create backlogs of work to implement in order to complete the change. This is a perfectly valid approach when the system really is ordered, and not incompatible with Kanban Thinking. A future state Kanban System can be designed, with pre-determined work types and workflow, and an appropriate visualisation, WIP limits and other policies. Metrics can be gathered, but learning may be minimal because of the assumption that the correct solution can be known in advance. However, while short term results may be achieved, there is also the risk that the chosen practices being implemented are not appropriate, or get followed blindly and dogmatically, with the long term result being a fall over the cliff into chaos as already described.

Evolutionary Change

On the unordered side, in the complex and chaotic domains, we need to be more experimental, using emergent and novel practice, to understand the current state and discover its evolutionary potential. The author John Kay describes this approach as being one of Obliquity in his book of the same name. Similarly, Tim Harford discusses the need for a variety of experiments, resilience to the possibility of failure of those experiments, and clear selection of which experiments to kill or continue in his book Adapt.

This is the approach that really harnesses the power of Kanban Thinking. A Kanban System can be designed to represent the current state with existing work types and work flow, an appropriate visualisation  conservative WIP limits and other policies. Metrics can be used to further understand the current state and adjustments can be made to the work, its flow, visualisation and policies in the form of intentional experiments, run to learn how to evolve the system for greater impact. A more suitable system design is likely to emerge this way than could be envisaged up front, although there is the risk that the improvement could be achieved more quickly using expert guidance.

Domain Dynamics

What becomes interesting with Cynefin is not the classification of whether something is simple, complicated, complex or chaotic, but how situations transition between the domains and across the boundaries. No domain is considered to better than the others because each is contextual. Moving from the complex to the complicated domain may be appropriate when optimising or exploiting a solution. Conversely, moving from the complicated to complex domain may be appropriate when wanting to innovate or explore an idea. Occasionally a short and shallow dive through chaos into complexity might be appropriate for more radical changes. A key transition to be aware of is the one from the simple to chaotic domain. This results from complacency and over reliance on best practice, which pushes problems over the cliff into chaos. This transition is known as a cliff, and represented differently by the squiggle, because recovery is a non-trivial and costly process.

Use of the domains can be further confusing because often it is discovered that scenarios may be in multiple domains at the same time because elements of it live in a different domains. Narrative fragments, in the form of short anecdotes, are a common and useful form for capturing the examples and identifying and understanding the differences. Taking coding as an example, someone could tell a story about learning a new language, which might be a simple problem with best practice about syntax and coding styles. At the same time, someone else could tell a story about using Test Driven Development with that language as a good practice for a more complicated challenge of detailed design and development. Yet another person could tell a story about using spikes to experiment with a complex feature which requires the emergence of an innovative new design and architecture. Finally, a further person could tell a story about dealing with the chaos resulting from having to react to defects found in some legacy spaghetti code.

So What?

I have found that having an understanding of these different system domains, and their dynamics, to be useful in guiding my approach to taking action when working to  help organisations change and improve their system. While my experience may often lead me to believe I know the answer, there are times when there is no right answer, and sometime the answer is not even knowable. By helping others discover the answer for themselves, they are able to both get to a better place now, and be better positioned to be able to discover new answers for themselves in the future.

One of my contributions will be a short piece on flow, one of the three impacts I describe in Kanban Thinking. I am reproducing the current version below, although the final version may well change.

Flow is the result of doing the thing right. It is the regular and smooth progress of work from its initial concept to its final consumption.

Work that progresses in large chunks, in a stop-start manner, does not have flow. It’s the work that progresses in small pieces, in a continuous manner, that ultimately creates the kind of flow your organization needs. By reducing completion time and enabling greater predictability and reliability, it’s this kind of work that builds trust and fosters creativity and innovation. Moreover, reducing utilization and creating spare capacity, sometimes referred to as slack, allows a greater ability to respond to changes and surprises. After all, we don’t run our servers at 100%, and we know how well traffic flows on a grid-locked road! This spare capacity is what gives us time to spend on continuous improvement and innovation.

Working on smaller and fewer pieces of work helps minimize delays and generate faster feedback. Think about a slow, sluggish cargo tanker compared to a fast and nippy speedboat. Further, balancing demand against capability, and not starting more work than you can complete, means that work isn’t left hanging around and depreciating. Imagine the pileup caused by trying to push a chain of paperclips across a table versus the smooth flow created by pulling them across.

So how does an organization go about actually achieving flow? Focus on progressing and completing a smaller number of smaller pieces of work. Make that work, and its flow, visible in a physical shared place, and when work becomes blocked, encourage teams to resolve issues and concentrate on finishing it rather than starting something new. When aspects of the workflow are identified which mean that the work does not progress as quickly and smoothly as you would like, invest time in improving the workflow in order to develop future capability.

While this may appear to reduce the amount of time one is kept busy, it’s important to remember that busyness and productivity are not the same thing.

Measuring activity, in terms of utilization, will not create great results. Instead of focussing on the worker, focus on the work product, and measure work outcomes by things like throughput for productivity, lead-time for responsiveness, and due-date performance for reliability. These are all appropriate measures of flow.

Stop starting, and start finishing.