Anatomy of the Kanban Canvas

I’ve just added a high level explanation of the anatomy of the Kanban Canvas to the main Kanban Thinking site (where you can downloade the Canvas). I thought I would also post it here.


How to assess the systemic problem and who is experiencing it.

At the centre of the Canvas is the system being worked on.

Assuming that the current situation is not perfect, and there is always room for improvement, then understanding the scope of the system helps focus on the biggest opportunities for improvement and avoids “rearranging the deck chairs on the Titanic”. By thinking about the situation as part of a holistic system, and having clarity on the scope of the system, we are more likely to identifying opportunities which improve the whole, rather than making smaller, local improvements, which might worsen the whole.

This leads to the question of what is the scope of the system. Defining the system to be too small, might not lead to any significant improvements. Equally defining the system to be too large, might be like trying to “boil the ocean”.

One way of understanding the system is to look at the people involved, and explore what problems those people are having. Narrative is an extremely useful form of doing this – finding and telling stories about people’s experiences and frustration with their work. In particular, the stories related to the customers and stakeholders will start to identify the boundaries of the system.

One fun way of exploring the system through narrative is by using the Pixar Pitch. This approach makes the final “Because of that…” refer to the current kanban system design, and the “Until Finally…” is left blank to be explored in the Impact section.


How to assess the fitness criteria in terms of flow, value and potential.

The three arrows coming out of the right of the central System are potential Impacts which might be made. These Impacts encourage a focus on what success or failure could look like, before any changes get made.

Given that in most situations, we are dealing with complex problems, where cause and effect are only apparent with hindsight and past solutions are not necessarily repeatable in the future, then we should not try to define a specific future state to solve the problem. However, that does not mean that we cannot determine the characteristics of the outcomes of solutions so we can assess their fitness criteria, or how fit for purpose a solution is.

Impact is an evaluation of fitness for purpose. A successful solution is one which has positive impact and an unsuccessful solution is what which has negative (or no) impact. Impact can be thought of as direction, as opposed to a point solution being a specific destination.

Having explored the scope of the System through narrative, we can also begin to define Impact in a similar way by asking what stories do we want to hear more of, or less off, in the future. When using the Pixar Pitch technique, imaging impossible good and bad endings to the story brings out exaggerated scenarios which can be compared against by asking whether the System is becoming more or less like the suggested endings. Getting both good and bad endings allows both positive and negative Impact to be easily imagined and identified.

When imagining the future, to create a range of diverse possibilities, the Impacts on Flow, Value and Potential are used to encourage thinking from different perspectives.


How to assess the evolutionary potential in terms of studying, sharing, stabilising, sensing and searching.

The five arrows going into the left of the System are the potential Interventions that could be made. These Interventions provide a frame for appreciating the intent behind various practices, learning and discovering which ways of working are the right ones for the current situation, and transforming those practices as the system continuously evolves.

Working through the interventions encourages continuous curiosity about which tools and techniques to use, understanding when and why they are appropriate, and ultimately collaboratively, co-creating an initial kanban system as a baseline to begin experimenting and improving.

The interventions used are to Study the context, Share the understanding, Stabilise the work, Sense the capability and Search the alternatives.

Understanding Change with Cynefin

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

Understanding Systems

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



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

System Domains

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

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

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

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

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

Managed Change

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

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

Evolutionary Change

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

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

Domain Dynamics

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

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

So What?

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


Kanban and Tragedy of the Commons

After Limits to Success and Shifting the Burden, we now come to Tragedy of the Commons.

I live in the seaside town of Brighton in the UK. On the rare weekends when we have hot weather it is popular to go down to the beach. Everyone gets in their cars and drives into Brighton expecting a quiet, relaxing day on the coast. What they actually get is a noisy, crowded area full of lots of other people who have had the same idea. This is an example of the “Tragedy of the Commons” archetype. The beach (and the roads to it), are the commons – a shared resource. Individually, each person expects to gain some pleasure from the beach. However, when too many people visit, nobody gets any pleasure from the beach, because it has limited capacity and quickly becomes over-crowded.


Individually, A and B’s activity give themselves separate net gains so that they each benefit through a reinforcing loop. However, their activities combine to create a total activity which, after some delay, eventually consumes a common resource beyond its limit. At that point, A and B’s activity begins to reduce those separate net gains through a balancing loop.

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

Often, a Tragedy of the Commons occurs as a result of Shifting the Burden to the commons. By setting up the system to deal with the Shifting of the Burden, the likelihood of the Tragedy of the Commons can be reduced.

Similarly, the commons becoming overloaded is a specific case of Limits to Success, and setting explicit limits for the commons will avoid this. Further, creating a buffer before the commons will ensure that there is always work when the capacity is available. In Theory of Constraints terms, this is exploiting the constraint.


A kanban system also helps with a Tragedy of the Commons by helping visualize the total activity, so that everyone is aware of the demand on the limited resource. Further, each party can limit their own activity to avoid the total activity becoming too great. Swim-lanes are one approach to visualising this.


Finally, Classes of Service can then ensure that the limited resource is being used effectively for the most appropriate work. Swim-lanes, or colour-coding, can create clarity of which work is more important, based on its Cost of Delay. This clarity can also help keep an appropriate balance of different types of work in order to manage the risk of the commons unnecessarily delaying urgent work.


What other examples of Tragedy of the Commons have you experienced, and what other techniques have you used to visualise them?

Kanban and Shifting the Burden

Following on from a look at the Limits to Success system archetype, lets now look at the Shifting the Burden archetype.

I like my coffee in the morning. In fact I usually need a good cup of coffee before I start to feel human. Some days I like a coffee to start the afternoon as well, and occasionally I’ll have a few more in-between to keep me going. This is an example of ‘Shifting the Burden’ archetype. I feel low, so drink coffee to pick me up. However this is just a short term fix and I eventually need more caffeine to maintain my energy. The real problem is why I have low energy; late nights, a poor diet and little exercise. Rather than getting more sleep, eating a healthier diet, and exercising, I am shifting the burden to the caffeine. If I were to shift the burden to a stronger (and less legal) drug, then it is likely that my need for the drug itself would become the problem, rather than my lack of energy. At this point, the archetype has moved from Shifting the Burden to Addiction.


Shifting The Burden begins with a Problem Symptom. The quick or easy answer to this problem is the Symptomatic Solution which creates a balancing loop. However, there is also another answer – the Fundamental Solution – which can create an alternative balancing loop. The Symptomatic Solution only eases the symptom though, and doesn’t resolve the underlying problem, so the symptom consistently returns. The Fundamental Solution does address the root cause, but has a delay though, which means that it is more of a long term answer than a quick fix. The more the Symptomatic Solution is applied, the more a Side Effect takes place, which over time with delays reinforces the need for the Fundamental Solution, while at the same time making it less feasible. When the Side Effect becomes more of a problem than the initial Problem Symptom, is when the Shifting the Burden archetype becomes one of Addiction.


Recognizing the archetype leads us to examine our solutions to problems and to question whether they are Symptomatic or Fundamental. When problems re-occur over time, then using Root Cause Analysis techniques may lead to finding alternative Fundamental Solutions. Continually depending on technical specialists or coaches may be a Symptomatic Solution, whereas investing in training on knowledge sharing may be a better Fundamental Solution. As the well-known Chines proverb says, “give a man a fish and he will eat for a day, teach him how to fish and he will eat for a lifetime”

A Kanban System can help cope with Shifting the Burden, once a problem symptom has been identified, in the following ways:

  • Signalling occurrences of the identified problem symptoms so that they are transparent and appropriate focus can be made on the fundamental rather than symptomatic solution. A brightly coloured tag or shape can achieve this.


  • Visualizing what problems symptoms are being addressed by various symptomatic or fundamental solutions. The Concern, Containment, Countermeasure pattern can be useful here where problem symptom is defined and stated as a Concern. The Containment action is the symptomatic solution taken to resolve the problem quickly. Then, after root cause analysis, the Countermeasure action is the fundamental solution to prevent repeated recurrence. (Thanks to Jason Yip for pointing me to this pattern)


  • Allocating capacity and limiting work in process for work related to fundamental solutions using a dedicated swim-lane and WIP limits. This treats the improvement efforts as first class work types, with equal visibility to the rest of the work.


What other examples of Shifting the Burden have you experienced, and what other techniques have you used to visualise them?

Kanban, System Archetypes and Limits to Success

In a previous post I introduced the idea that Kanban can play a role in Systems Thinking and understanding System Archetypes. In this post I’ll describe system archetypes in some more detail, and describe the Limits to Success archetype.

Balancing Feedback

Balancing feedback will stabilise a system’s behaviour. For example a thermostat is a balancing feedback system where the temperature is measured, the difference from the desired temperature measured, and a heating or cooling device adjustment made accordingly. This can be depicted as below, with the B identifying the loop as balancing. When the temperature is higher than the target, then the adjustment is to generate cold air. When the temperature is lower than the target then the adjustment is to generate hot air.


Reinforcing Feedback

Reinforcing feedback will amplify a system’s behaviour. For example a bank account is a reinforcing feedback system where you have an account balance, onto which an interest rate is applied, and as a result you have interest paid to increase the balance (assuming your bank pays you interest). This can be depicted as below, with the R identifying the loop as balancing. As the cycle continues, more and more interest is paid, continually increasing your account balance. Conversely, when you have a negative account balance, your bank might apply a charge, which is deducted from your balance (much more likely). This cycle will continue as your account goes into increasing debt.



What makes systems complex is that there are often delays in the feedback loops. Delays separate cause and effect over time which often leads to instability and oscillation. For example, how many times have you been in the shower and tried to adjust the temperature, only to find the water suddenly get too hot or cold? This is due to a delay in the action of adjusting the temperature, and the temperature actually changing. As a result we tend to over-adjust and get burnt or chilled.



Most systems are not as simple as these examples, and consist of combinations of balancing and reinforcing feedback loops with different delays. However, a system’s particular structure will result in its behaviour being constant over time, and systems with similar combinations result in similar behaviours. These patterns which cause similar and recognisable system behaviour are known as system archetypes.

Being able to recognise system archetypes helps to identify the cause of behaviours, and gives insight into how to break (or encourage) the archetype to our advantage. Let’s take a look at an example.

Limits to Success

The Limits to Success archetype can be depicted as below.


To improve performance of a system, more efforts are made, which do lead to the anticipated improvements, creating a reinforcing loop. However, after some time the performance reaches a limit and resistance creates a balancing loop, leading to the performance levelling off, declining or even crashing.


Recognising this archetype leads to the understanding that when the systems resists, or pushes back on attempts at improvement, then rather than continuing to push the reinforcing loop, and increase efforts or do the same thing better, we should look to remove the limits by adjusting the system design to delaying the balancing loop. In other words, deal with the limits before the system does. The system’s limits will result in a worse outcome.

A Kanban System can help to cope with Limits to Success in a couple of ways. Firstly, setting explicit Work in Process limits is a way of directly limiting the system before the system does so itself, avoiding the decline or crash in performance. Secondly, gaining transparency of the work and the workflow is a beginning to learning what the cause of the limiting factor is. Visualising any bottlenecks or impediments gives a good indication of where to start looking to make changes in the system design.

Cargo Cult Kanban

A couple of weeks ago I got involved in another conversation about the appropriateness of the software development community’s use of the name Kanban. This comes up every now and again, and I usually sympathise and try and talk more about the higher level system, as in the Toyota Production System. This time, however, I had a different thought. While Taiichi Ohno did call the TPS’s central tool Kanban, he was also against codifying methods, so why do we insist that the name Kanban has to refer to a copy (or codification) of what Ohno’s TPS Kanban looked like?

The Agile Community has referred to Cargo Cult Agile for some time, and it seems that there are increasing occurrences of Cargo Cult Kanban. The term Cargo Cult is used to describe the copying of practices to achieve a goal, without understanding those practices. From the Wikipedia page:

Cargo cult activity in the Pacific region increased significantly during and immediately after World War II, when the residents of these regions observed the Japanese and American combatants bringing in large amounts of material. When the war ended, the military bases closed and the flow of goods and materials ceased. In an attempt to attract further deliveries of goods, followers of the cults engaged in ritualistic practices such as building crude imitation landing strips, aircraft and radio equipment, and mimicking the behaviour that they had observed of the military personnel operating them.

Cargo Cult Kanban is the copying of another Kanban System without understanding why it is designed the way it is, and its appropriateness for another context. This applies whether the Kanban System you are copying was designed by Taiichi Ohno, David Anderson or Arlo Belshee. Taiichi Ohno’s TPS Kanban System was a solution in Toyota’s context. However, its the thinking behind the tool that was more significant, and I’d like to think that he would appreciate the software development community’s use of the name Kanban to describe its systems thinking approach to evolutionary change.

Kanban and Systems Thinking

Systems Thinking

The original Agile methods were created by teams independently in response to the challenge of improving software development and their documentation as a named process was a subsequent codification in order to help spread the learning and improvement wider throughout the industry. Either consciously or intuitively, these processes were applications of Systems Thinking, taking a holistic approach to solve the problem at hand. Taken in this context we can learn from Agile methods by treating them as system archetypes rather than repeatable solutions, and design our own systems to create the same results.

System Structure

Systems Thinking suggests that systems are made up of elements, which interact, to meet a purpose. In other words, they are more than the sum of the parts.

  • A system’s purpose is what ultimately determines its behaviour. In fact a system’s purpose can be often deduced from its behaviour which is observed over time rather than through individual events. A generic purpose for product development might be to deliver value through achieving flow and building capability.
  • A system’s elements are the things that it is made up of and these can be either tangible or intangible. Tangible elements of a product development system could include the people, physical resources (e.g. hardware and furniture) and artefacts (e.g. specifications and tests). Intangible elements could include the software itself (both product and tests), software tools (e.g. compilers and editors), skills and morale.
  • A system’s interactions are the relationships that hold its elements together. They can typically be a flow of energy, material or information. For product development systems, the most relevant interactions often take the form of information flows. This might be information about learning (e.g. success or failure), state changes (e.g. ready or done) or decisions (e.g. accepted or rejected).

System Archetypes

A system can also be described in terms of stocks and flows. A stock is a recognisable and measurable part of the system, and the flows are what cause the stock to rise and fall over time. Thus, the stock at any given time is the result of the all the preceding flows in and out of the system.  The stock acts as a buffer for the flows, which can create stability and allow for variability by decoupling the flows. However, it can also cause delays which may cause instability. In a product development system, if we think of the stock as the Work in Process (WIP), we can see that some WIP will create stability, but too much will create undesirable delays.

Describing systems in terms of stocks and flows leads to the understanding of feedback in systems. Feedback is created when changes in a stock affect the flows into or out of that same stock. Feedback can either balance and stabilise, or reinforce and amplify a system’s behaviour and combinations of feedback structures result in a system’s behaviour being constant over time. The patterns which cause similar and recognisable system behaviour are known as system archetypes.

Kanban Systems

These basic Systems Thinking concepts give us a clue to how we can help meet the challenges of improving our product development practices without codifying methods. Having clarity of purpose, and the way elements interact to achieve that purpose, can give us insight into intervention points for continuously improving.

System archetypes give us a further perspective with which to view our product development processes, and suggests the role Kanban plays. If Agile processes are examples of a system archetype, then Kanban provides an approach to creating further examples of those system archetypes. Workflow can be thought of as part of the system structure. Visualisation can highlight key elements and interactions. Limiting WIP can manage the stock. Cadence can co-ordinate of elements and interactions. Learning can focus on improving the system.  Further, where processes are exhibiting less desirable archetypes, then Kanban provides an approach to recognise, visualise and eventually break them.

It should be remembered though that systems area non-linear in that there not a simple cause and effect relationship. That is why behaviour should be measured over time rather than looking at individual events. As Donella H. Meadows so eloquently put it in her book ‘Thinking in Systems: A Primer’, “The future can’t be predicted, but it can be envisioned and brought lovingly into being” and “We can’t control systems or figure them out. But we can dance with them!”

Kanban System Design Article

I’ve just had an article published on Agile Journal about Kanban System Design in which I look at Kanban from a Systems Thinking perspective, and how various aspects of Kanban can provide leverage points to improve our product development outcomes.

A Model for Creating a Kanban System

This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.

At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.

The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.

  • Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
  • Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
  • Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.

In other words, we want to flow value through capability teams.

Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.

  • Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
  • Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
  • Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
  • Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
  • Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.

While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.

Systems Thinking, The Vanguard Method and Software Development

I’ve recently read John Seddon’s “Freedom from Command and Control“, which introduces his approach to Systems Thinking – the Vanguard Method. A few key points really struck home with me and helped clarify my thoughts on some of the challenges I’ve come across recently.

First is the following simple diagram, which shows that Management is responsible for defining the System, which is ultimately what defines Performance. Management’s role should be to analyse Performance, and change the System to improve it.

Agile initiatives are usually begun in order to improve performance. Seddon says that in order to analyse Performance, we first need to understand the Purpose of the System. Then we should create Measures to provide knowledge of how well we are meeting that Purpose, before finally applying a Method which meets that Purpose, using the Measures to help refine the Method.

Finally, Seddon says that understanding Purpose involves understanding Demand, and in particular, Seddon introduces the concepts of Value Demand and Failure Demand. Value Demand is what do our customers ask us to do because it add value, and Failure Demand is what our customers ask us to do because we failed to something, or do something right in the first place.

I’m increasingly aware of Lean and Agile methods being used for the sake of it. While Scrum, XP and Kanban will generally serve common software delivery Purposes, such as delivering real benefits and in short timescales, using them without recognising the Purpose will often result in no real improvement in Performance. Lean and Agile methods are often used just as alternative delivery approaches within an existing System, rather than as means to change the System itself. These organisations can be thought of as “wall-dwellers”, using a method within existing boundaries, rather than “wall-movers”, moving the boundaries to help create a System which helps meet the Purpose. To quote (or paraphrase) Russell Ackoff, this is “doing the wrong thing righter, rather than doing the right thing”.

Do you know what the Purpose of your software development process is? Do you have Measures about capability against that Purpose? Do you know what your Value and Failure Demand is?