At the London Lean Kanban day last month I gave the following presentation on discovery kanban.
Okaloa
Accredited Kanban Trainer
LKNL12 Speaker
LKNL12 Board Member
LKFR12 Speaker
Resilience, Adaptability and Transformability with Kanban
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 adaptability, kanban, lean, resilience
Leave a comment
When change is the bottleneck
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.
Lead time, Loopbacks, Leadership and Learning – 4L root cause analysis of programme performance
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.
Discovery and the whole systems Kanban
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
From Stocks to Flows (and from portfolio to end-to-end)
At LSSC12, Mike Burrows organized an evening meeting on “portfolio stuff” (sic). He is reporting about this on his blog.
In his blog he wonders whether the name “portfolio management” is the right name as it carries the bagage of failing approaches.
I agree, the term portfolio carries a couple of connotations that we want to get rid of:
1) thinking about a project portfolio as a stock – when we talk about a project portfolio people tend to think about the portfolio as a stock that can be valued; they talk about optimizing the value of the portfolio, etc. Rather than thinking about the project portfolio we need to start thinking about it in terms of flow.
2) project portfolio thinking emphasizes functional/silo thinking – in your organization, do people talk about the “IT project portfolio”? The “development project portfolio”? If so, then you know what I am talking about. Talking about the “IT project portfolio” emphasis the IT function as a silo. Rather than that, we need to think end-to-end value stream.
This leads me to the advice, drop the name “portfolio” talk about end-to-end flow. Let’s not talk about “portfolio kanban”; let’s talk about end-to-end kanban!
The opportunity is not in going up in the hierarchy of the development silo. The opportunity is in broadening our view from “development kanban” to “end-to-end kanban”. What happens upstream? How can we support the upstream “business value discovery” process with visualization, pull, flow, collaborative improvement? How can we support the downstream “implementation and validation” process with visualization, pull, flow, and collaborative improvement?
What does this end-to-end flow look like? What items are flowing? Just work items? Or is it options (as in real options) and commitments? Is it limiting “work-in-progress” only? Or is it also ensuring “minimal options”? Is it collaborative improvement within “development” or is it collaborative improvement across the end-to-end?
I was not at the LSSC12 and the “portfolio stuff” meeting, so maybe I am repeating what was said already there. Still I thought it worthwhile to put in my 2 cents to the discussion.
Posted in Uncategorized
Leave a comment
