Resilience, Adaptability and Transformability with Kanban

Posted on June 28, 2012 by Patrick Steyaert

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 Patrick Steyaert

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 Patrick Steyaert

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 Patrick Steyaert

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

From Stocks to Flows (and from portfolio to end-to-end)

Posted on May 21, 2012 by Patrick Steyaert

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

Lean Programme Transformation

Posted on May 15, 2012 by Patrick Steyaert

Background

For a while now I have been eager to look at the bigger picture of Lean and Kanban beyond the pure software development context. My inspiration comes mainly from the work of Alan Ward, Micheal Kennedy, John Shook and the likes on Lean Product Development and A3 thinking. The challenge was to apply it to a business/IT context. Recently I have had some opportunities to explore Lean and Kanban concepts in the context of Large Transformation Programmes (abbreviated to LTP in the rest of the blog).

Large business and IT transformation programmes represent a large expenditure with a substantial impact on the business and IT systems. Uncertainty in these programmes is high – both on the side of expected benefits as well as on the side of the capability of the organization to deliver the programme. Hence large transformation programmes are often plagued with overruns in budget and schedule, quality issues and in the end not delivering the aspired benefits. Due to economic and market reasons, organizations are starting to show less tolerance for overruns and quality issues in such programmes. It is time to explore how lean thinking can transform large transformation programmes.

Situation analysis

The traditional cornerstones for delivering LTPs include: stage gate project life-cycle, division of work in work-streams, some kind of portfolio management to release projects in the organization. These traditional cornerstones have proven to be deficient in the following ways:

Largely linear project life-cycle with stage gates gives rise to long project lead times (spending a lot of time in analysis and re-analysis) and loopbacks in later project stages.

In one example the LTP spend an additional 9 months in analysis. Even after doing a thorough analysis of all the business processes, the different (application oriented) work-streams felt the need to re-do the analysis from an application perspective and taking into account the capabilities of existing applications and a package application that was going to be implemented. Even after all this analysis it was hard to assess the impact of the transformation for the business people involved.

The programme also suffered from loopbacks. Work streams were de-scoped late in the project because of time pressure, wasting work that was already performed. Of all the (+20) business process that were analysed, only 5 processes were deemed critical. The work of the architecture team was largely neglected by the work streams resulting in the need to reverse engineer the (as-build) solution architecture. The purpose of the programme was to build an architecture that could be reused across business lines and regions. Even before the first implementation it was clear that much rework would be needed before going to the next implementation.

Work that is organized in technically driven work-streams ( roughly corresponding to existing delivery teams) giving rise to silo thinking, fragmented knowledge, integration problems and resistance to change.

In traditional programmes,  separate work streams are delivering in organizational silos each with their own goals and objectives. This means that goals and objectives of the work-stream are often too remote from the programme goals and objective. Also, the know-how and responsibilities about the solution is fragmented (in silos), without end-to-end ownership. Because each of the work-streams is working in a silo, integration proves to be a problem. Because non of the work-streams actually delivers business value in itself (only the integrated solution does) no value can be delivered before all integration problems are resolved. It’s an all or nothing solution making it hard to manage the programme towards its aspirational budget and schedule. Moreover it means that the business can expect a big change when the solution is implemented. Business is not ready for this big change and may never be ready to truly accept a big change like that.

Releasing projects into the organization based on “priority” and resource availability gives rise to reinvention of knowledge and duplication of effort.

Similar transformation projects are simultaneously started in different lines of business or in different geographical regions because of time pressure. Because transformation projects for each line of business are started in parallel there is no opportunity to learn across these projects. Even when projects are started sequentially, organizations do not have the capabilities to learn across projects.

Lean transformation

So what can lean thinking contribute to solving the above problems. We will look at the following pilars of lean and how they apply to managing an LTP:

  • Value
  • Pull
  • Flow
  • Standards

Focus on value

The purpose of a transformation programme is not to deliver IT systems but to improve the business. The business is struggling with a problem. Let’s say that we are a manufacturing company. Maybe inventories are too big (and costly). Maybe delivery times are too slow (and not to the satisfaction of the customer) or too variable. Probably, performance in both dimensions is unacceptable. The main challenge for the programme is how to fundamentally improve the business. In the current state of business improving in one dimension (inventory) leads to unacceptable performance in the other dimension (due date performance for delivery). Fundamental improvement means to improve on both making inventories smaller and delivery times shorter. Typically we can capture the business problem in a trade-off curve as shown below.

Pull not push

Pushing one overarching, one-size-fits-all solution to our business problem has proven not to work. The situation analysis has shown that it leads to programmes that are hard to manage towards budget and schedule, a business that is not ready, and probably not delivering the improvement that was envisioned. At worst the programme cascades into failure – the technical problems become to big and resistance to change kills the programme off.

Value-driven programmes allow the business to pull small increments of value. They work in small steps allowing the business to learn what works and what does not work. As confidence grows (and also knowledge), bigger and bigger increments of change can be undertaken.

Flow

A value-driven programme is organized around A3 sized business improvements: business improvements that can be described and visualized on an A3 sized paper. (an example A3 is given at the bottom of the blog post). Each A3 sized improvement addresses a different root cause of the business problem.

Each A3 sized improvement also provides an opportunity for learning. At the start of the programme we have unclear visibility about what is realistic and what is not realistic business performance. Improvements need to be carefully planned to provide maximal learning opportunities about the trade-offs between the different dimensions of business performance.

As the programme progresses, we need to validate what has been delivered before starting new work. We can design a simple Kanban system to manage the flow of improvements.

Standards

With the above steps we have actually started to implement the plan, do and check steps of the PDCA cycle as show below.

As the cherry on the cake we now turn our attention to the act step. In the act step of the PDCA we need to make sure that what has been learned and developed in previous incremental improvement in the programme is made available for reuse for future incremental improvements. We need to scale up what works well and scale down what did not work well.

Examples of what needs to be captured and standardized for future reuse includes:

  • Business policies and procedures
  • IT systems and solutions
  • Delivery and delivery management capabilities

Summary A3

The following A3 summarizes the Lean Transformation of Large Programmes.

Posted in Uncategorized | Leave a comment

Using Cynefin to make sense of projects

Posted on September 9, 2011 by Patrick Steyaert

Since a couple of years we have been using Cynefin to help our customers to make sense of the different domains of projects they are executing. The motivation for doing so, is that we strongly believe that the one-size-fits-all approach that dominates most of the thinking today, is a major source of project failure.

In general we have found that most organizations do have projects that very much align with the different Cynefin domains. These domains include the following types of projects:

Routine projects (ref. Cynefin “simple/known” domain)

These are projects that the organization is executing on a very regular basis with very low risk and high predictability. The challenge in this domain of projects is not in the delivery of a single project but the increasingly efficiently delivery of many routine projects with increasing levels of quality. Consider for example a web-site development company that delivers web sites on a very regular basis (1 per week) with a relatively standard process and within relatively standard constraints. The organization has developed a routine for delivering such projects. It needs to ensure that it is increasingly efficient and quality is continuously improving. Often times the work is routinized to the extent that it is considered to be a continuous service rather than individual projects.

Of all “project management” approaches, Kanban is most appropriate in this domain. The Kanban properties of visualizing the workflow,  limiting work in progress, measuring and managing flow, making process policies explicit, using models to recognize improvement opportunities are critical in the routine domain.

Extension projects (ref. Cynefin “complicated/knowable” domain)

These are projects that are in extension of the organizations current capabilities and expertise. While there may be a certain level of uncertainty involved, this uncertainty can be assessed by experts in the organization. Uncertainty may be both on the side of the value of the project (do we know what we need to build?) as well as on the side of the execution (do we know how to build it and do we have the capabilities?). Most importantly the risk can be assessed and managed. Typical for this project domain is also that risk can be managed by close interaction with the customer (i.e. there is a trust relationship that allows close interaction between project team and customer and iteration to a solution). Many development projects are in this area if they are properly set up (if they are not properly set up, they will end up in the sensitive domain below).

In the domain of extension projects, project managers need to be equipped to manage project risk by means of iterative delivery of the project results. Kanban can be extended into this domain as explained in the post on end-to-end project cycle.

Emergent projects (ref. Cynefin “complex” domain)

These are the projects where there is a large uncertainty about the value of the project (we may not even know who the real customers are) but we have ways to do experiments with low cost of failure and where we can quickly learn from these experiments. Project objectives are emergent based on direct customer feedback. True innovation projects that are properly set up fall into this domain.

In the emergent domain notions like iterative customer discovery as advocated by the lean start-up community are critical.

Sensitive projects (ref. Cynefin “chaos” domain)

These are the projects where there is a (lethal) combination of uncertainty about the value of the project and the execution of the project (how to deliver the value). In other words there is a combination of human uncertainty and technological uncertainty. Typically, these are projects surrounded by conflict, disagreement and ambiguity. It is exactly the combination of human uncertainty and technological uncertainty that is the breeding ground for rapidly cascading failure in these projects. Typical projects in this domain are large projects with substantial re-architecting of the existing infrastructure or capabilities.

Many development projects (that should be in the extension domain) also end up in the sensitive domain because of lack of trust between the customer and the supplier or lack of knowledge of how to set up such projects (E.g. setting the project up as a waterfall instead of iterations). Often times organizations move themselves into the sensitive/chaos domain by not properly aligning themselves around a common purpose. Whatever the reason for this – lack of trust, lack of vision, lack of management know-how -, in the end it leads to local optimization.

Still, often times the chaos/sensitivity comes from external factors. As in the large re-engineering project that was mentioned above. The organization is confronted with a rapidly changing technology landscape and needs to adapt its (large and complex) software to that and at the same time there is a high pressure to deliver new features as the competitive pressure in the market grows. It needs to change the engine of the car while driving at 100mph so to speak.

This seems to be more and more the new normal. It seems that in today’s business environments, dealing with contradictory and contingent goals (or objectives if
you like) can not be done away with as an anomaly but are an essential part of doing business. This poses – in my opinion – a serious challenge for how we think about management and project management in particular as our dominant models seem to rely on clear, consistent, stable goals.

In the domain of sensitive projects, project managers need to understand how to deal with contradictory goals, cascading failure, etc. This requires an insight in complexity models just like Cynefin which brings us back to the topic of this post – the need for project managers to take a broader view and abandon the one-size-fits-all approach. Herein lies the fundamental next step in delivering projects more successful.

Posted in Uncategorized | 1 Comment

Understanding value

Posted on August 19, 2011 by Patrick Steyaert

Title: Understanding value

Catalogue: Lean Adaptive Management

What this pattern is about: business alignement around value creation, the adaptive cycle of products and services, understanding value through a sense making framework

Maximizing value

Story: Wim and his team have worked hard to charter the upcoming major development projects for their next product release. These projects represent the majority of the product development investment their company will make in the next 6 to 12 months. Now they have a feeling that everybody has a shared understanding of what they are investing in. The management team recognizes that they now have an excellent view on what is going to be developed. Still they find that they need a clearer view on the “why” of all these projects. They want to get a better – and measurable – view on the benefits/returns that these investments will bring. In a workshop with the product manager and the sales manager it becomes clear that despite the fact that there is agreement about the choice of individual projects, sales and product management are not aligned on the big picture. Sales is frustrated as they have the feeling that they don’t get a clear message from development – e.g. they get the message that a certain product capability is developed, and then suddenly, if they want to market the capability, development is very cautious about it; apparently the capability was not developed to the full extent, or was it? On the other hand development and product management are frustrated. They feel a lot of pressure from sales and marketing – we need this and that feature to go to this and that market – and then suddenly, when they worked hard to get the feature in, it turns out that it is not a focus (anymore?) of sales and marketing. Or, they have made a quick and dirty implementation under pressure to capture a commercial opportunity and then suddenly sales and marketing starts marketing the feature on a scale they were not ready for. Apparently a more crucial conversation needs to take place (about the big picture) before delving into the details of each specific project.

When commercial units (e.g. sales and marketing) and development or delivery units (e.g. product development and service delivery) in an organization are not aligned, many things go wrong. Commercial efforts are made to market a product/service at a scale that the (development and delivery) organization is not ready for, development efforts are made without the proportional commercial support to market it. In the end all parties that are involved (and ultimately the customer) are disappointed and frustrated as the value that is created is not proportional to the investment that was made.

(note: I will talk about “product” as a synonym to “product/service”).

Organizations achieve alignment by linear top-down mechanisms (strategic performance management, business modeling, business cases) or iterative bottom-up mechanisms (e.g. iterative customer development). While each of these mechanisms are valuable, in isolation they give only a partial or fragmented understanding that may actually hinder alignment more than it helps. To explain this, we will need to look at the adaptive cycle metaphor as it is applied to products and services.

Adaptive cycleThe adaptive cycle consists of a front loop and a back loop. In the front loop of the adaptive cycle (exploitation to conservation, indicated in red in the figure below), an opportunity is captured and developed into a mature product within a mature market. To stay ahead of competitive pressure, the organization is continuously seeking to maximize value in the front loop.

Value maximization in the adaptive cycle

As the product and market jointly mature (in a co-evolutionary manner) product and market become very much interwoven and interconnected. Value maximization and increasing connectedness between product and market may push the product in a critical state. As the market matures, the product can become commoditized and competition may shift towards price competition. The organization may end up in the critical region where it overshoots it’s customer needs and becomes vulnerable to disruptive innovations (Ref. Clayton Christensen on Disruptive innovation). As the product grows it may become harder and harder to adapt to new needs and opportunities and ultimately the product and supporting organization may become atrophied.

Value renewal in the adaptive cycle

At the critical point the product may enter the backloop of the adaptive cycle (from release to reorganization, marked in blue in the figure above). Resources that are associated with the product are released and the organization seeks to reorganize the released resources to renew the product. It may seek to re-purpose the product to capture value from it in a novel way. Upon success, the product enters a new cycle to create new value. Upon failure, value is lost.

Cumulative success versus Cascading failure

Using the adaptive cycle metaphor we take a broader view than the usual S-curve. It is exactly this broader view that is of interest to us. In practice products may go many times through the adaptive cycle at different levels of scale (product-market, product capability-market segment, feature-user group). From a value creation perspective the front loop and the back loop of the product cycle are obviously very different.

In the front loop many reference points exist to understand value. The market is known and risks can be assessed. At best quantitative data is available, at least a good qualitative understanding by experts can be expected (an archetypical example of value assessment in this domain is the Alessi formula that is used by the Alessi company to assess the expected revenues of their design products; if you haven’t heard of it, just google it). The organization may need to invest to develop the necessary resources but investments can be justified based on the understanding of the value that can be expected. This is well know territory.

In the back loop, value is uncertain. The main question is how to re-purpose available resources so that novel value can be extracted. Quantitative data and qualitative understanding is limited. Rather than assessing value, the organization may seek to assess the impact it is making (e.g. impact on early adopters and thought leaders).

To understand value, organizations first, and foremost, need to understand where in the adaptive cycle they are operating. For a specific product – market combination the organization may be operating in the front loop; i.e. the market is an established market for standard usage of the product. For other product – market combinations, the organization may be operating in the back loop; e.g. the organization may be trying to enter a new market by using its existing product in a new way or by novel extensions to the product.

Failure to differentiate between operating in the front loop and operating in the back loop, leads to the typical mismatched expectations as indicated in the introductory story. As most mature organizations are operating in both modes at the same time, an explicit understanding of where each existing or targeted product – market combination is positioned is a prerequisite to any discussion about value.

Practically, the framework to distinguish between different product – market combinations needs to take into account 2 dimensions. The first dimension is value uncertainty – i.e. are we operating in the front or in the back loop? This is indicated as run-the-business versus change-the-business in the figure below. The second dimension is determined by the way we can interact with the market. Is it possible to co-operate for example with lead customers, early adaptors in an iterative way? Or is the interaction with the market mainly linear/transactional (first develop then market).

Domains of value creation

Taking into account the above mentioned dimensions, we get a Cynefin like framework with the following domains:

  • Standard: product/service as it is delivered routinely in the market or market segments where the organization routinely operates; value is created by enhancing the product/service according to evolving needs of customers
  • Extension: extending the product/service in adjacent markets (e.g. extending into higher ends of the market)
  • Emergent: using existing product/service or product components (in fact all available resources) in a way that extracts value in a new way; opportunities present themselves (or can be created) to gain hands-on experience with this new way of extracting value from the product/service; for example by means of lead customers and early adaptors
  • Sensitive: product/service-market combination that has arrived at the critical point where future value becomes highly uncertain because of changes in the market and the large and uncertain cost that is required to cope with these changes; different conflicting views exist about how to retain or re-capture value

Understanding value

Story: Wim has organized several contextualization workshops at different levels in the organization. The outcome of the workshops is a shared understanding about the positioning of the existing and future product-market combinations in the adaptive cycle. This shared understanding is documented as four domains that represent different levels of commitment of the sales and marketing unit as well as the product management and development units. In the run-the-business domain, a clear relationship is established between sales and marketing targets (in terms of revenue and market share) and product development targets (in terms of product capabilities). In the change-the-business domain the different units are aligned around the opportunities that they want to explore (e.g. domains in which to actively solicit and work with lead customers) and the strategic investments/riks the company is willing to take (market and product capabilities in which to pro-actively invest).

Posted in adaptive cycle, cynefin, value | Tagged , , , , , | 2 Comments

Cynefin, Panarchy, PDCA, OODA and value creation curves

Posted on July 16, 2011 by Patrick Steyaert

The last couple of years I have been making use of Cynefin to make sense of complexity in project organizations. Cynefin has helped me to make sense of how projects differ and how to cope with these differences.

More recently I discovered the Panarchy model. Just like the Cynefin model the Panarchy model helps to make sense of complex systems. Specifically, it helps to make sense of the dynamics of evolving hierarchical systems with multiple interrelated elements. The panarchy model originated as a framework for understanding resilience in social-ecological systems. I think it may also have a great potential as a sens-making framework in the context of project organizations (that clearly fit the description of “evolving hierarchical systems with multiple interrelated elements”).

Adaptive cycleThe Panarchy model suggests that systems follows a four-phase adaptive cycle of (1) “exploitation” (r); (2) “conservation” (K); (3) “release” (Ω); and (4) “reorganization” (α). Quoting the Resilience Alliance: “The adaptive cycle exhibits two major phases (or transitions). The first, often referred to as the foreloop, from r to K, is the slow, incremental phase of growth and accumulation. The second, referred to as the backloop, from Omega to Alpha, is the rapid phase of reorganization leading to renewal.”

The metaphor of the adaptive cycle helps to make sense of the evolution of practice in organizations as depicted in the figure below. Similarly it can help to make sense of the evolution of the (hierarchical) systems (with many interrelated elements) that we are building.

Adaptive cycle and the evolution of practice

Equally important, the adaptive cycle can help to make sense of the mechanisms that we use to improve practice. I have seen people use and misuse the concepts of PDCA (Plan-Do-Check-Act) and OODA (Observe-Orient-Decide-Act). Using the adaptive cycle metaphor we can clearly situate both cycles.

Adaptive cycle, PDCA and OODA

Ecological and social-ecological systems form nested sets of adaptive cycles. The larger, slower cycles generally constrain the smaller, faster ones and maintain system integrity. From the Resillience Allience: “The fast levels invent, experiment and test; the slower levels stabilize and conserve accumulated memory of past successful, surviving experiments. The whole panarchy is both creative and conserving. The interactions between cycles in a panarchy combines learning with continuity.”

Nested cycles

Also within project organizations we observe nested cycles. We can see organization-wide practice development at a longer time-scale (multiple years) and we can see practice development at the team level at shorter time-scales (weeks and months). We can see product evolution at the time-scale of the product life-cycle and we can see product evolution at the time-scale and scope of individual features.

The metaphor of nested adaptive cycles can help to make sense of the interactions between these different levels.

Shorter adaptive loops (of teams and features) can reinforce the longer adaptive cycle (of the whole organization and the product). The effect of these reinforcing loops on the value curve is reminiscent of the so familiar J-curves and S-curves.

Effect of reinforcing loops

Similarly, shorter adaptive loops can weaken the longer adaptive cycle. The system risks to go into a state of cascading failure.

Cascading failure

I am sure I have only scratched the surface here. I decided to put this post out anyhow to get early feedback. So, all input and feedback welcome! I will update the post to improve it.

Posted in adaptive cycle, complexity, cynefin, panarchy | 8 Comments

Manage the project end-to-end life-cycle with Kanban

Posted on June 26, 2011 by Patrick Steyaert

Title: Manage the project end-to-end  life-cycle with Kanban (previously was “Accelerate the project flow with Kanban”)

Catalogue: Lean Adaptive Management – Addressing project management challenges with Kanban

What this pattern is about: the project life-cycle – from idea to implementation; the communication bottleneck – balancing value discovery and value delivery; tailored project management for linear and iterative work flows

Focus on delivery

Story: Joe has recently been assigned a project in the business area that he is an expert in. He works for an international company. The project life-cycle that he needs to comply to, states that a user requirements specification (URS) is required before project development can start. So he has worked very hard to produce this URS. Now that he is in the process of seeking approval of the URS, he encounters a lot of resistance. The IT manager claims that he does not understand the URS; other stakeholders are not eager to give approval. According to compliance rules the project cannot start. In practice however – because of the pressure to deliver – IT has already started on the functional specifications. With all the discussion going on about this, somehow everybody is losing sight of the ones that matter most for this project … the users that later on will have to operate the system. Joe talks with his colleagues about the situation. It seems that many have similar experiences. It seems that the harder pressed they are to start the project the longer it takes to finish it.

Every project has a life-cycle. In many project organizations the project life-cycle has a formal character. In such cases, projects need to comply with it or tailor it to the project’s specific needs. In other project organizations, there seems to be a de-facto life-cycle, be it linear or iterative.

In theory, the life-cycle is there to prevent mistakes that will cost dearly later on in the project. In the linear life-cycle, we have stage-gates to prevent that we take short-cuts and ensure the quality of early life-cycle stage deliverables. In the iterative life-cycle, we have iterations because we want to avoid that big developments are done on unvalidated assumptions (assuming that these assumptions can only be validated by means of a working product). In theory, the life-cycle is there to ensure that value is delivered to the customer and users.

In practice, things turn out differently. Excellent delivery alone does not make success. In many project organizations, the project life-cycle starts when many important decision have already been taken. In many cases, the whole process of value discovery (understanding what value to deliver), is not covered in the life-cycle. Or, it is covered with much less detail and understanding. Generally, we tend to sub-optimize by overly focussing on the delivery side and not sufficiently involving upstream and downstream stakeholders (and ultimately the customers and users). It rarely happens that, the whole workflow is covered end-to-end, from idea to implementation. This applies to linear/waterfall life-cycles as well as to iterative/agile life-cycles.

From idea to implementation

But there is an even bigger issue. It has to do with  the tendency to think in one-size-fits-all solutions. For those that apply a linear life-cycle, all project must follow a linear life cycle – we need to think things through before we start. For those that think in iterations, all project must be iterative – focussing on delivery and feedback, here and now. In the ideal world, both types of life-cycles can work on their own. In practice a lot of energy is wasted in window dressing and using the wrong approach for the wrong situation.

It is no coincidence (in my opinion) that those involved in value delivery (developers, engineers, testers, etc.) are more inclined towards an iterative life-cycle and those that are involved in value discovery (business analysts, product managers, product marketing, etc.) are more inclined towards a linear life-cycle. The reason is the different time perspective of long-term value discovery versus short term value delivery. In practice this turns out to be a serious communication bottleneck. How many organizations have you encountered where there is a huge backlog of items to be developed – to the frustration of both the business and the development team -, but that development is continuously working on the basis of ill defined requirements because no one has the time or intention to turn these ill defined backlog items into well prepared work items? Project organizations need to be able to combine the long term with the short term and the life-cycles that are associated with it.

A chain is as strong as its weakest link. Project organizations need to manage the flow of work from end-to-end; from idea to implementation. The project life-cycle must include both value discovery as well as value delivery activities. The work that is involved with value discovery must be synchronized with the work that is involved with value delivery. And we need to combine value discovery and value delivery into both linear and iterative workflows.

End-to-end flow

Practically, we can set up Kanban boards for both value discovery and value delivery. The focus of the value delivery Kanban board is on managing the work in progress, the lead and cycle-times and helping the delivery team to self-organze. The focus of the discovery Kanban is on stimulating the engagement of upstream and downstream stakeholders (and users and customers), gaining an understanding of the priority of the most valuable work, and ensuring that all delivery work is well prepared. In the end the discovery Kanban must produce requirements with a clear value and priority in its output queue. Both types of Kanban boards are linked through a pull system. Delivery teams pull work from the discovery Kanban thereby signalling to the discovery teams that more work needs to be prepared in terms of e.g. requirements (but not to much of course).

The end-to-end Kanban as described in the previous paragraph is sufficient to manage the flow of routine work in a project or project organization. This includes maintenance tasks, standard services, routine performance improvements, routine enhancements, etc. The type of work where all requirements can be made clear upfront, the business case is straightforward because only one stakeholder is involved, the work can be executed by an independent team and there are no exceptional technical challenges. It all fits well in the current functional, technical, and business architecture. Work can flow linearly from discovery to delivery.

Linear flow

Not all projects are routine, of course. Sometimes more complicated work needs to be tackled: work where not all requirements can be made clear upfront, the business case is complicated because different stakeholders are involved, different teams are involved, and different experts need to be involved to clarify the business case and to help tackle technical complexities. Work can not simply flow linearly from discovery to delivery. The risk mandates iteration between value discovery and value delivery (iterative flow).

Iterative flow

Complicated projects start out in the same way as routine projects in the discovery Kanban. They are a combination of individual ideas that turn out to be too complicated to be delivered in one go. For complicated projects both the life-cycle of the project as a whole needs to be managed as well as that of individual work items. Work is managed on different levels: at the portfolio level the flow of projects is managed, at the individual project level the flow of project work items is managed.

Managing the end-to-end flow with Kanban

Story: Joe has set up a Kanban board for discovery. This Kanban board visualizes the flow of ideas, concepts and requirements. The different columns of the discovery Kanban represent different steps in the engagement with users and stakeholders. There is a cadence with which ideas are turned into concepts and concepts are turned into requirements. He has set up trigger points to ensure that at all times enough requirements are prepared to go into development (but not to much). As a result, Joe anticipates the pull of development but does not anticipate to much. At organizational level there are two levels of Kanban boards now: the portfolio level Kanban board in which ideas are collected, concept are prepared, and projects are qualified (routine or complicated), and the project level Kanban boards in which ideas, concept and requirements are processed for individual projects.

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