Using narrative to research Kanban implementations

Posted on June 30, 2013 by

Update to this post (Oct. 30, 2013)

During the months after this blog post, Arno Korpershoek and myself have worked on an implementation of a narrative research tool (as described in the blog post) for lean agile organizations based on Cognitive Edge Sensemaker. The purpose is to allow practitioners to share stories about their experience with lean and agile. You can go and have a look and leave a story (if you want) on the narrative research tool website.

How deep is your Kanban?

The Kanban community holds the idea of evolutionary change very dear. The Kanban core practices play a central role in the sense that they are said to catalyze change, allowing a lean agile organization to emerge.Given the importance of the core practices, it is to be expected that people ask the question of how to “measure” a Kanban implementation against the core practices.

Kanban spider

Such measurements are being developed in the Kanban community. Typically, each core practice is considered a dimension against which to measure according to a certain scale of shallow to deep implementation. The above is a typical spider diagram visualization of this. The size and shape of the area in the middle of the spider diagram are a visual representation of the depth of the Kanban implementation for the team that is measured.

The most important reason for measuring a Kanban implementation seems to be a genuine concern for improvement. Measurement can help a team to identify “gaps” or opportunities for improvement. More importantly, it can help to identify other teams with similar or different profiles in the context of experience sharing.

Narrative research

Despite all good intentions, “measurement” of teams is a very thorny issue. We all know that measurement engenders all kinds of dysfunctional behavior. Quantification leads to unwanted outcomes, the environment is treated as unvarying, the context is not taken into account (one-size-fits-all), and it narrows the focus to that what is measured. Most important it may lead to cargo cult as every team aspires to conform to the ideal. In the wrong hands, it can turn into a tool that completely goes against the grain of evolutionary change that is held so dear.

The risk of a one-size-fits-all approach can kill the team diversity that is so crucial to improvement. Teams with different levels of sophistication in their Kanban implementation act as gradients for improvement. Just like a hang glider that needs pressure differences to keep going, improvement and learning needs different teams that perform at different levels of sophistication of implementing Kanban to keep on going. The wrong approach to measurement can take all the pressure differences away leaving no room for learning.

Glider that uses thermals

Narrative research (or narrative inquiry) is an alternative that needs to be seriously evaluated in the Kanban community. Narrative inquiry is a form of qualitative research that emerged in the field of management science and later also developed in the field of knowledge management. It uses stories as the central unit of analysis. It is the stories, such as the two examples below, that provide a context to any quantification of a Kanban implementation. Numbers derive meaning from the context that is set by the stories that are told by the individuals and team(s) that implement Kanban.

Story 1: We are a maintenance team that maintains a large application. Our customers are users from the following  units in the business:= HR, Finance, etc. Customers expect timely delivery of changes to the application and a stable application.

Story 2: We are innovating our product to cope with disruptive changes in the market. We are still exploring what our potential customers want and the business model to capture the value.

So how do the Kanban core practices fit in the narrative research? As a coach I have had the privilege to witness how the Kanban core practices are key to phase shift an organization into a different regime of higher performance. I am sure other coaches have had similar experiences. The Kanban core practices are modulators; i.e. a forces or factors that trigger a change in the “leanness” or “agileness” of a team. They are not just independent and linear dimensions. They influence each other and are influenced by the emergence of a lean-agile organization.

Core practices as modulators As such, it is a good idea to let the individuals and teams signify their stories with an identification of the strength or direction of the modulator/core practice. To avoid “cargo cult”/”conformance to the ideal” we prefer however to use a signification based on equal opposite ends rather than the traditional negative – positive extremes. The picture below shows an example on the basis of “Implement feedback loops” core practice.

Implement feedback loops signifier

The design of the signifier is such that both ends of the scale are equally positive/neutral or negative. In the example above, both types of feedback loops are seen to be equally neutral.

A signifier set design based on equal opposite ends avoids the risk of conformance to the ideal. However, designing a signifier set with equal opposite ends can sometimes prove to be a difficult exercise; especially for the Kanban core practices. The reader might, for example, have different concerns with the example above: Are the opposite ends really equal?  Are these the right opposite ends? I do think that the leaders in our community can agree upon a signifier set that is suitable. The exercise of building it could have a value in itself.

Fitness landscapes

I conclude this blog with an indication of how the results of a narrative inquiry are visualized and used. The figure below shows a fitness landscape. (NOTE: This is not a fitness landscape that has been constructed based on a narrative inquiry. Still it does fine for illustrating how a large quantity of stories that have been signified can be visualized.)

Fitness Landscape

Fitness Landscape

The fitness landscape shows plateau’s of stable implementations; outliers; and peaks of instable implementations. It can guide us to the places where we need to make an intervention and places that we can learn from.

For constructing such a landscape we need to have a large enough quantity of stories. This may be beyond what is possible for small organizations; it might even be beyond the possibilities of larger organizations. My personal opinion is that this presents an opportunity for LKU, Limited WIP society or other to serve the Kanban community. A collection of Kanban implementation stories signified at the source of collection can prove to be an invaluable asset for the community.

Reference:

Dave Snowden’s work on narrative research has been very influential. See the Cognitive Edge website for more information.

Posted in change, complexity, kanban, Lean, Uncategorized | Tagged , , , , , | 4 Comments

Managing risks and options with discovery Kanban

Posted on April 24, 2013 by

At the London Lean Kanban day last month I gave the following presentation on discovery kanban.

Posted in Uncategorized | Leave a comment

Lean Kanban Europrean Tour 2012 – Resilient change

Posted on October 28, 2012 by

Here’s the slides of my presentations at LKNL2012 and LKFR2012:

Posted in Uncategorized | Tagged , , | Leave a comment

Resilience, Adaptability and Transformability with Kanban

Posted on June 28, 2012 by

Resilience

“Imagine you are on a boat docked in a calm harbor and you want to quickly carry a brim-full cup of water across a stateroom without spilling. Now imagine the same situation but with the boat in rough seas. In harbor, the solution is simple: just walk quickly, but not so quickly that the water spills. At sea, speed is a secondary concern; now the real challenge is to maintain balance on an abruptly pitching floor. The solution now is to find secure handholds and footholds and to flex your knees to absorb the roll of the boat. In harbor, the solution is a simple optimization problem (walk as fast as possible but not too fast); at sea the solution requires you to enhance your ability to absorb disturbance-that is, enhance your resilience against the waves.” From: Resilience Thinking: Sustaining Ecosystems and People in a Changing World by Brian Walker PhD, and David Salt

Resilience is the capacity of a system to absorb disturbance while undergoing change and still retain essentially the same function, structure, identity, and feedbacks. Eco-systems exhibit resilience: e.g. the capacity of a forrest to recover from a fire; the human body exhibits resilience: e.g. the capacity to maintain body temperature under varying conditions; as do many other systems.

The current economic, political and ecological climate, requires organizations to exhibit higher degrees of resilience.  They are forced to change their focus from maintaining efficiency of function towards that of maintaining existence of function (as illustrated with the water cup in the opening story). This has been a main driver of change in organizations for the last decade and will remain so for some time.

The concept of resilience is often depicted as a basin of attraction (see figure below). Under normal conditions, the system operates within the basin of attraction. Given enough disturbance the system can be moved beyond the threshold into another basin of attraction – the system has changed identity. In the case of the human body, if we move the body temperature beyond the threshold point (e.g. below 35°C), the human system is moved from the “life” basin of attraction to the “death” basin of attraction. Or in the case of a lake we may have a basin of attraction (the “good” basin of attraction) in which there is clear water and fish, and a “bad” basin of attraction where the lake is filled with algae due to the disturbance by nutrient pollution.

The stability landscape of a system. The basin of attraction define the main resilience parameters: L = Lattitude (how much the system can be changed); R = Resistance (how easy or difficult it is to change the system); Pr = Precariousness (how close the trajectory of the system is to the threshold )

To what degree does a software development, product development or other team exhibit resilience? Under what disturbances will a team lose it’s identity? I.e. when will a team start disintegrating, letting go of it’s normal practices, stop functioning and start trashing? At what point will the team stop feeling like the team? Under which disturbance? And which teams exhibit more resilience than other teams?

Let’s start with the disturbances. Typical disturbances include:

  • interruption of work
  • too much work
  • changing priorities
  • bugs
  • unclear requirements
  • information arriving too late
  • estimates

Many teams are so overwhelmed by these disturbances that their identity is one of firefighting, multi-tasking, and fixing problems. They are operating in a bad basin of attraction that they can not escape from. Resilience capacity is low, as small disturbances can have dramatic effect on the functioning of the team.

Kanban’s evolutionary change process allows teams to climb out of the bad basin of attraction. The Kanban core properties “visualize, limit WIP, manage flow, make policies explicit, collaboratively improve” help teams to build their resilience capacity. Resilience capacity depends on 3 main factors that are all 3 addressed by Kanban’s core properties and principles:

– Variety: the variety that is present/allowed in the system – the system needs variety to deal with the variety in its environment (requisite variety) – Kanban allows variety in the work items within a team and variety in the policies and processes across teams.

– Modularity: a modular system is more resilient than a highly connected system where disturbances freely propagate – Kanban promotes modularity of work within a team and modularity across teams

– Leadership: as humans are part of the systems we are talking about, leadership is required to respond to changing conditions – Acts of leadership are an integral part of Kanban

Beyond resilience adaptability and transformability are crucial properties. We leave those for a future blog post.

Adaptability

Adaptability is the capacity of actors in a system to influence resilience. This amounts to the capacity of humans to manage resilience.

Transformability

The capacity to create a fundamentally new system when ecological, economic, or social (including political) conditions make the existing system untenable.

Posted in complexity, kanban, panarchy, resilience | Tagged , , , | Leave a comment

When change is the bottleneck

Posted on June 17, 2012 by

A couple of weeks ago I was doing an in-company Kanban workshop. I knew the team that participated in the workshop from before. I had been working briefly with them a few years ago. From the moment people started coming in, I realized that I had to be careful. The team showed many signs of “a bad history of change”. They had been going through several change initiatives, many, if not most, without success or perseverance.

One clear signal was from the body language of one participant. Leaned back in his chair, chin in the air, I really saw him thinking … “here we go again, yet another *wise guy* that is going to tell us how we need to do our work”. Other signals were what others were talking about. Yeah, we do scrum … but we don’t have a stand-up meeting. Yeah we have a project life-cycle (that we need to comply to), but we do not follow it. Etc. Many changes had been pushed onto them. Perseverance in the change had been lacking.

A few years ago I was not able to interpret the signals that this team was sending out. Since then I have been exposed to explicit change methods (i.e. Accelerated Implementation Method, “AIM”) and the Kanban change approach. When it comes to change their seems to be 1 fundamental law:

    • The success of a change initiative highly depends on the success of past change initiatives

In other words, if you have failed at implementing change in the past, you will have a high risk of failing to implement change in the future. And, the more failed changes, the harder it becomes.

For this organization, change really is the bottleneck. Yes, they need to fundamentally improve their performance; but yes they also need to be careful that this does not turn into a YAFCI – Yet Another Failed Change Initiative.

Kanban, in this light, is not just an evolutionary change approach. When done properly, Kanban evolutionary change actually helps the organisation to build a capacity for future change. By insisting on small steps and being persistent, the organisation can build a platform of successful change. The organisation starts with small changes and grows the capability to take on bigger changes in the process. Respect and persistence are the key words.

In the end we had a good workshop. I showed respect for the team, they showed respect back.

Posted in change, kanban | Tagged , | Leave a comment

Lead time, Loopbacks, Leadership and Learning – 4L root cause analysis of programme performance

Posted on June 14, 2012 by

Recently I was asked with a colleague to perform a root cause analysis of a large transformation programme. The expectation of the customer was not to perform an assessment of the programme against a best-practice model but really to find the root causes of why the programme was not performing as expected. The customer expected a cause and effect analysis.

We decided to analyse the programme from different angles: look at the programme management practices, project management practices, change management, 3rd party management, organization, learning and skills. We delivered a fine result (if I may say so myself) that gave the customer the insight that was needed.

Still, the exercise got me thinking. The typical tool for a root cause is a ishikawa diagram. Causes in the diagram are often categorized. In manufacturing, for example, the 6M categories are often used: Machine, Method, Material, Man Power/Mind Power, Measurement, Milieu/Mother Nature; or the 7P’s: Product, Price, Place, Promotion, People/personnel, Process, Physical Evidence.

In doing the root cause analysis of the programme, we had a hard time because we didn’t have a set of categories to work from. Since then I developed a little framework that can help to perform the root cause analysis of a programme or project. It is heavily inspired on Lean Product Development.

In its current stadium it is based on 4L’s: Lead times, Loopbacks, Learning and Leadership.

Lead times refer to the long start-up times that many programmes suffer from. Long start-up times are a root cause for project overrun. Much of the overrun of a project is incurred at the beginning. Causes in this area include: overly detailed analysis, lack of availability of experts, long decision cycles.

Loopbacks refer to points later in the project where there is a failure because of an unchecked assumption in the start of the project. Typical loopbacks include integration problems, building the wrong solution, de-scoping late in the project. Loopbacks are also a root cause of project failure.

Learning refers to the obstacles that the project encounters due to a lack of opportunity for learning and taking lessons learned into account in the project. It includes lack of cross project learning (solving the same problems in multiple projects), hand-overs, not taking into account the lessons learned of previous projects.

Leadership refers to … well, leadership. It includes a lack of balance in the decision making (e.g. scope, scope, scope in the beginning of the project, time, time, time near the end of the project when the deadline is coming close), not managing issues to closure, disconnect between authority and knowledge to make decisions.

As you notice I have left some room for a couple of extra categories. Things that have popped up as extra categories: respect (respect for diversity) and load (evenness of workload).

Since I started using the above 4l template it has proven to be very robust and useful. By publishing the framework I hope to gather your feedback. So, if you use it, drop a little comment and tell us about your experience.

Posted in Lean, Uncategorized | Tagged , , | 3 Comments

Discovery and the whole systems Kanban

Posted on June 2, 2012 by

The whole systems view and deliberate discovery

The focus of Lean is on delivering value. The purpose is to deliver value for the business that pays for it.

Value of the product is not in the delivery but in the use of the product. We not only need to build the product right but make sure that we build the right product. But how do we know what is the right product? How do we know what the customer values? How do we know who are the customers?

Discovery is the process of finding out the customers, customer needs, business value and how customer needs can best be addressed by the system we want to build. In Jeff Patton’s words: Delivery is about the building of a product; Discovery is learning about the outside world and our product in it.

Discovery and delivery are the yin and yang of product development. They are inseparable. No delivery without discovery; no discovery without delivery. Often we are overly focused on delivery (and especially efficiency of delivery) and discovery is skipped or cut short. When we short-cut discovery we run the danger of taking wishes (what the user says he/she needs) for the actual needs (what the user really needs) and spending much money in building the wrong product.

As Dan North puts it: “Methodologies, practises and patterns for delivery are all well and good, but they don’t take into account the single biggest limiting factor to successful delivery. … Surely it makes sense to invest effort in firstly discovering which aspects of delivery we are most critically ignorant of (i.e. both where we are ignorant and where that ignorance is hampering throughput), and further to invest in reducing that ignorance – deliberately discovering enough to relieve the constraint and allow us to proceed.” He uses the term deliberate discovery to stress the fact that discovery should not just be left to happenstance.

Deliberate discovery is a learning process. It consists of:

1. Forming a hypothesis: postulating customer needs and business value
2. Validating the hypothesis: validating the assumptions we made about customer needs and business value

The front-end of discovery (forming a hypothesis) is found upstream of development; the back-end of discovery (validation) is found downstream of development. All-in-all discovery + delivery gives us a complete picture of the end-to-end value stream.

Kanban at the whole systems level

The purpose of introducing Kanban at the whole systems level is to evolve towards a steady flow of value towards customers. Discovery Kanban relates to the use of Kanban in both the discovery front-end and the discovery back-end. Delivery Kanban obviously relates to the use of Kanban in delivery (traditional Kanban so to speak).

In order to come to a steady flow of value, the balance between discovery and delivery is a critical point of attention.

Too much discovery upfront leads to a large inventory of requirements, too many unvalidated assumptions about user needs, and push of work into development. Development is perceived as the bottleneck. This has been the main focus of Kanban and the Kanban community.

In reality, it is equally often the case that development is starved because of too little time has been spent in the discovery upfront. Development just starts and invents its own requirements or it starts with the few requirements it already has. In such case up-front discovery is the actual bottleneck.

To balance discovery and delivery we need to make sure that discovery does not move too far ahead of delivery. This is the function of delivery kanban (the rope in the picture). We also need to make sure that discovery moves up ahead far enough so that delivery does not catch it up too soon and gets starved. This is the function of front-end discovery kanban (the flexible stick in the picture).

Lets have a closer look at the front-end of the discovery kanban to illustrate this last point.

Discovery kanban: front-end

The front-end of a project is often mistakingly depicted as a process of refinement. We start with top-level goals that are refined into detailed requirements. This is a mistake and an indication of a lack of understanding of the front-end process. Discovery is not a convergent process. It is a divergent – options creating – process.

A more correct representation of discovery is found below. The discovery starts with fragmented narratives. The different narrative fragments represent the different wishes of different stakeholders: “we want the system to do this”, “we want to serve these customers”, … Often narratives are anecdotal and they may be conflicting. The purpose of the front-end of discovery is to move from fragmented narratives to a shared coherent model.

Let’s illustrate with a concrete example with user stories. User stories are typically not derived in a top down fashion. To the contrary. Typically we start from the bottom up. Users write user stories from their individual perspective (fragmented narratives). User stories are collected in a story map (a concept or sketch) that relates the different stories to each other and to higher level goals (or activities). The story map is constructed in a workshop format to ensure that users (and other stakeholders) develop a shared view. As we move towards development, stories gain detail – e.g. by splitting stories and adding acceptance tests – and a more comprehensive model is created.

With this understanding of the discovery front-end flow, it is easily visualized on a Kanban board.

While delivery kanban and discovery kanban have more or less the same properties they are subtly different.

Unlike the delivery kanban system, the discovery kanban system does not manage a flow of work. It manages a flow of options. In the delivery kanban we limit the work in progress in order to push choice upstream (put the risk where it belongs). In the discovery we need to ensure minimal options in order to ensure that we have a choice. The purpose is to ensure that at each moment we have a minimal set of options ready for replenishment of the input queue of development (making sure that development is not starved from well prepared requirements).

To sum it all up, the core properties of discovery kanban can be expressed as follows:

1. Visualize options
2. Ensure minimal options
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively

Posted in kanban, Uncategorized, value | Tagged | 5 Comments