A Review of Impact Mapping

I mentioned that I had a great conversation with Gojko Adzic at Lean Agile Scotland. During that discussion, Gojko also described a technique he call Impact Mapping. Since then has published a short book on Impact Mapping which I highly recommend.

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 Change with Cynefin

I have written a number of posts on systemic thinking, which I believe is at the heart of Kanban Thinking. I’m currently referring to systemic thinking, rather than Systems Thinking, in order to try and avoid any confusion with any particular school of thought, of which Systems Thinking could be one. I have also written an number of posts on Cynefin. This post brings the two together.

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.

 

The Flow Impact

As I wrote yesterday about some upcoming Rallying adventures, I get to work on some exciting projects. A recent one is the “Agile for Business” book which is being put together in an iterative and incremental manner. Bob Gower, who is spearheading the initiative, wrote a blog post last month about the background to the book.

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.

From Capability to Potential

At Lean Agile Scotland last weekend I was chatting with Gojko Adzic over dinner, and one of the many topics we covered was whether capability was the right word for one of the three impacts I describe as desirable with Kanban Thinking. Earlier this year I described what I meant by capability, but more recently I’ve realised capability is more commonly referenced as a property of the whole system, rather than one specific impact. In other words, if we improve a system’s flow, we have improved the system’s overall capability. Thus I needed to find a new word.

When I referred to capability as an impact, my goal was to ensure as much emphasis was placed on the people who are doing the work, as was on the work itself and its process. This emphasis is what enables a system’s performance to be sustainable over the long term, and even to improve over time. I had been toying with sustainability, but Gojko suggested the word potential and the more I think about it, the more I like it. Potential can be defined as the “possible, as opposed to the actual”, and what is “capable of being or becoming”. This clearly describes that improving a system’s potential is improving the long term future of that system.

Another way of looking at it is the metaphor of a pipe, again inspired by Gojko. If value is what comes out of the pipe, and flow is the progress through the pipe, potential is what can go into the pipe. A system which has a positive impact on potential is one which opens the tap to allow more to be done.

IMG_0031

Then there is also the notion of human potential. Bob Marshall referred to this, and specifically to the waste of human potential, in his Lean Agile Scotland session on Rightshifting, further reinforcing the notion. I also noticed that Matt Wynne has referred to the same waste in his blog post following the conference. This has a nice synergy and helps reinforce the idea that increasing a system’s potential is not about cracking the whip harder. Rather it is about investing in people, unleashing their creativity, and making work fun.

As a result, the latest Kanban Thinking model now looks likes this.

IMG_0032

Management Improvement Carnival

I’m honoured to have been asked by John Hunter to host an edition of his Management Improvement Carnival. That means that I get to pick a number of links to posts and articles on relevant topics. Here they are…

Agile Fluency

One set of posts that caught my eye was on Agile Fluency. The original post by James Shore and Diana Larsen proposes “a model of Agile fluency that will help you achieve Agile’s benefits. Fluency evolves through four distinct stages, each with its own benefits, costs of adoption, and key metrics”. Dave Nicolette responded that ” the gist of the article appears to be that we can effect organizational improvement in a large company by driving change from the level of individual software development teams. The major problem with that idea, in my opinion, is the bottom-up approach.” James then further clarified, by saying “Dave argues that the individual software teams in IT cannot drive bottom-up organizational change. I agree. Organizational change must occur if you want to achieve three- or four-star fluency, but our article doesn’t describe how to do so. It just says it’s necessary.”

Cynefin Agile Lean Mashups

One of the areas I have been involved in recently is in exploring how we can use ideas from social and complexity science to inform the theory and practice of Agile and Lean. This months CALM Beta event was specifically aimed at using Dave Snowden’s work with Cyenfin to do this. Dave has recently been blogging about his latest thinking on Complexity.

Employee Ranking

This link from Forbes has been doing the rounds in my twittersphere, describing how “a management system known as “stack ranking”—a program that forces every unit to declare a certain percentage of employees as top performers, good performers, average, and poor—effectively crippled Microsoft’s ability to innovate”. In response, Jabe Bloom described how “it’s been three years since we last ranked employees or gave performance reviews at TLC, and we think it’s working reasonably well.”

Agile Book

One of my colleagues, Bob Gower, has been putting together a book about Agile Business, including contributions from a number of Rally Coaches. “An important part of Agile is shipping things in a continuous and real-time manner. This is our effort of practicing what we preach. We are releasing the first increment of the book at the Agile 2012 conference to test how you think we’ve done—it’s not a complete copy of the book but enough we hope to whet your appetite.”

Introduction to Waterfall

Finally, here’s something fun I put together recently to help explain waterfall.

 

An Introduction to Waterfall

I was recently joking with some colleagues about what an “Introduction to Waterfall” course might look like. It turned out to be quite a simple proposition, so I quickly threw some slides together which I feel should be shared with the wide community.

Download the PowerPoint from slideshare for full effect, and please feel free to add some slide variations of your own!

Note: By waterfall, I mean “large-batch with stage-gate”. And remember this isn’t to be taken seriously – there may be contexts where that approach is appropriate…

Speaking at Lean Agile Scotland

How could I not attend a conference named after me? OK, maybe not named after me, but at least relatively local.

How could I not attend a conference being held on my birthday? OK, I could also spend my birthday with my family!

I will be at Lean Agile Scotland, however, which is being held September 21-22 in Edinburgh and I’ll be talking about “Understanding Kanban Thinking”.

If you want to go, I have a code which gives a discount of 10% on the ticket price. However, this will expire on the 6th of September. Let me know if you want the code, and then go to http://www.leanagilescotland.com/tickets and and follow the eventbrite steps.

Lean Flow Bag Stuffing Videos

The last few years I’ve helped out with the bag stuffing at the Agile200X conference. It started out as a fun experiment in applying our lean and kanban craft in a different context. It has turned into a tradition, and something we have learned huge amounts from. Last year Christopher Avery took some video and he’s recently published an number of posts with some of the content.

I’m not at Agile2012 this week and so missed the exercise on Sunday, but I’m hoping that someone will publish any metrics and learnings that came out of the latest instance of the experiment.

My CALM Beta Pre Work

I posted recently about by involvement in CALM Beta in Boulder. One of the things we added to the registration process was some “pre-work”.  The intent is to find out something about the people attending before they arrive in order to create a better event for everyone. As part of a post on the Rally blog, I decided to answer the pre-work questions myself, and I am repeating them here.

The Early Bird price of $350 ends on July 1. Register now to attend a couple of days of great discussion at a great price.

Why do I want to attend CALM Beta?

Apart from being one of the group organising the event (!), I’m excited about the possibilities of blending and learning from different ideas, approaches and disciplines. I hope that by exploring both what works in what context, and why, we can become better at choosing the right approach for the job at hand.

What experiences will I bring to CALM Beta?

I have been applying Agile ideas for more than 10 years, and Lean and Kanban ideas over the last 5. I have learned that helping teams and organisations understand why and how they can apply Agile and Lean thinking is essential to avoid practices being used by rote. As a result, I have recently started to use Cynefin techniques to help understand what approaches to use in their context.

What new insights do you hope to gain from CALM Beta?

I am hoping that we are able to explore the synergy between Cynefin ideas and some specific Agile and Lean techniques. For example, what is the relationship between A3 Thinking and the design of Safe to Fail probes. Or how do Lean Startup ideas fit in with those of working in the Cynefin complex domain. Or how can anecdotes and narratives be used to discover great user stories. In doing so, I hope to learn more about the appropriate use of those techniques, or identify areas where they might be modified or extended.

How would you answer these questions? Register and let me know!

Portfolio Kanban

I recently wrote an article for GOTO Magazine which has just been published its latest issue.

Given that it is embedded within the magazine, I thought I’d reproduce it here.

Steering the Agile Enterprise with Kanban Thinking

Introduction

Large scale, enterprise organisations consist of many initiatives, programs, projects and development teams. While it is well understood how each individual team can achieve the benefits of agility, it is more difficult for the enterprise as a whole to achieve those same benefits. This article will look at how Kanban Thinking can inform the design of a Portfolio Kanban System, with a view to steering the Agile Enterprise to attain those benefits in order to respond to today’s competitive environments and unpredictable change.

Kanban Thinking

Kanban Thinking is the framework I use when approaching the design of a Kanban System within a given context. The central concept is that the design approach is based on principles of Systems Thinking.

On the right side are the leverage activities for evolving the system design; study, share, limit, sense and learn. Studying the current system helps understanding of the existing context. Sharing that understanding gives everyone knowledge about what is happening. Putting limits in place bounds the system to help stabilise it. Sensing how the system is performing gives an understanding of current capability. Finally, learning from the systems performance allows its capability to be continually improved.

On the right side are the anticipated impacts the system design should have; flow, value and capability. Achieving flow involves a smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste. Delivering value involves focussing on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost. Building capability involves developing people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.

 

The Portfolio as a System

As a system, a portfolio is more than the sum of its parts – that is the initiatives, projects, features, teams and people – but is a product of the interactions of those parts with a particular tendency. Managing a portfolio, and as a result steering the enterprise, is the job of designing and guiding the portfolio such that its tendency is to have a positive impact.

First I will describe how the levers can be used to discover a Portfolio Kanban System design, and then show how to understand the impact of that design.

Portfolio Levers

Studying

When studying an existing portfolio, it is useful to begin by identifying all the work that is currently known about, from early ideation, to already in production and being maintained. That work can then be clustered and arranged into themes based on similarity or relatedness. Common patterns which emerge are often based around investment and work item types, hierarchies and their governance workflow.

Examples of investment types might be areas such as architecture, urgent customer requests, current market segments, expanding market segments or future opportunities. Those investment types could be made up of initiatives, which are progressed through the development of features, which are iterated on by breaking down into stories.

Sharing

Sharing a portfolio involves creating a model of the work which everyone can easily access and understand. Visual kanban boards provide a powerful mechanism for achieving this.

The most common approach is to create columns for the various stages of workflow that work items go through. For example, initiatives might begin as options, then have some discovery work done, then be assessed for suitability, then built and released before the results are reviewed for learning.

An important question to ask when designing the mechanism to share the portfolio is what you want to understand in order to learn. The TIP (Token, Inscription, Placement) heuristic is one I find useful to think about how to amplify the important signals, and dampen any noise.

Limiting

Limiting a portfolio is the means by which it can be effectively steered. By limiting the number of initiatives or features being worked on, they can be completed sooner, and with greater predictability, allowing organisations to get earlier feedback and respond better to new information and changing market conditions.

Work can be limited at a number of levels. Investment allocation can help keep the portfolio focussed on the right mix of work.  The number of initiatives and features can be limited to focus on finishing work before new work is started. Flowing work through stable teams can be used to balance demand against the capacity and capability of those teams.

As well as just limiting work in process through a Portfolio Kanban System, another form of limit is explicit policies. Creating transparency of the boundaries of the system design mean that the system can be stable within those constraints and the policies can be evolved to allow the system to evolve. A simple approach to policies is to add a checklist of exit criteria to each stage of the workflow.

Sensing

Sensing the performance of the portfolio is what tells us how well it is being steered, so that direction can be adjusted effectively. There are generally two elements to sensing; establishing a cadence and measuring outcomes.

Establishing a cadence creates a sense of rhythm, and helps lessen the co-ordination cost of getting people together. Setting up a regular meeting to plan and review the portfolio enables a forum for gathering new information and feedback. A Portfolio Council is then able to respond by scheduling and re-prioritizing work in a timely manner and ensure focus is on the most important work.

Establishing appropriate measures generates insights which can aid decision making about what can be done to enable better outcomes.  For a Portfolio Kanban System, financial measure seems to be appropriate. An economic model, which uses high level estimates of the costs and benefits of initiative or features, along with an understanding of the run-rate of teams, allows effective trade-off to be made between portfolio items. A timeline of planned and actual progress, for example, provides the basis for a rolling forecast as an alternative to annual plans.

Learning

Whatever choices you make, the design of your Portfolio Kanban System, and the work within it, it will be wrong! Learning, the detection and correction of those errors, is key to evolving the portfolio to have a greater impact.

Steering a portfolio is about updating the portfolio to match the reality of the current situation, rather than managing the portfolio towards a future situation. By sensing current performance with a regular cadence, work can be advanced, delayed or even killed to keep focus on the most important work.

Evolving a Portfolio Kanban System is about running deliberate experiments, with prediction and validation of how changes to the system design will affect its impact. Again, by sensing current performance with a regular cadence, visualisations, WIP limits and other explicit policies can be adjusted as knowledge is gained about what a better design should be.

Portfolio Impact

Flow

Achieving flow across a Portfolio Kanban System means that the initiatives, programs, projects or features in the system progress with as few delays as possible. As a result the enterprise will be more responsive to the competitive landscape, so that when new information surfaces it can be reacted to effectively. Further, when flow is smooth across a portfolio, the work delivered by the system becomes more reliable as variability of lead times is reduced to within understood ranges.

Value

Delivering value from a Portfolio Kanban System means the initiatives, programs, projects or features in the system are the most important things that could be worked on at that time. As a result stakeholder satisfaction will increase as customers get their needs met. Maintaining stakeholder satisfaction sustainably means that quality will also increase.

Capability

Building capability with a Portfolio Kanban System means that the right initiatives, programs, projects or features can be effectively delivered over the long term, and not just the short term. As a result employee satisfaction will increase, leading to greater retention of people and their knowledge. This long term building of people, teams and their skills will also lead to an increase in overall productivity.