go-ELSE - User contributions [en-gb]

The Change Perspective

2025-05-28T15:06:46Z

Cbird: /* Adapt or Die! */

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|593x593px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

===Orient ===
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

==== Inspect with ELSE Principles ====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

==== Identify Options ====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

=== Decide ===

==== Direction ====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

==== Identify and Select Experiments ====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

=== Act ===
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

==== Shape Experiments ====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

==== Patterns and Practices as an input ====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

==== Shaping Parallel Experiments to Speed Learning ====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

=== Run Experiments - Observe ===

==== Support ====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

===== Prompts and Triggers =====
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

===== Skills and Capabilities =====
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

===== Culture Impact =====
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

==== Gather Data ====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

=== Orient ===

==== Analyse ====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

==== Identify Options ====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

=== Decide ===
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

=== Act ===

==== Evolve and Broaden ====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

==== Revert ====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Be prepared to make difficult and fundamental changes rather than polishing the current system of work.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-03-19T10:17:52Z

Cbird: added an additional bullet for fundamental change

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|775x775px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

===Orient ===
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

==== Inspect with ELSE Principles ====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

==== Identify Options ====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

=== Decide ===

==== Direction ====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

==== Identify and Select Experiments ====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

=== Act ===
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

==== Shape Experiments ====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

==== Patterns and Practices as an input ====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

==== Shaping Parallel Experiments to Speed Learning ====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

=== Run Experiments - Observe ===

==== Support ====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

===== Prompts and Triggers =====
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

===== Skills and Capabilities =====
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

===== Culture Impact =====
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

==== Gather Data ====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

=== Orient ===

==== Analyse ====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

==== Identify Options ====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

=== Decide ===
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

=== Act ===

==== Evolve and Broaden ====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

==== Revert ====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Be prepared to make difficult and fundamental changes rather than polishing the current system of work.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-13T17:14:14Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|775x775px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

===Orient ===
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

==== Inspect with ELSE Principles ====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

==== Identify Options ====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

=== Decide ===

==== Direction ====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

==== Identify and Select Experiments ====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

=== Act ===
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

==== Shape Experiments ====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

==== Patterns and Practices as an input ====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

==== Shaping Parallel Experiments to Speed Learning ====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

=== Run Experiments - Observe ===

==== Support ====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

===== Prompts and Triggers =====
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

===== Skills and Capabilities =====
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

===== Culture Impact =====
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

==== Gather Data ====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

=== Orient ===

==== Analyse ====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

==== Identify Options ====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

=== Decide ===
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

=== Act ===

==== Evolve and Broaden ====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

==== Revert ====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-13T17:13:16Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|775x775px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

===Orient ===
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

==== Inspect with ELSE Principles ====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

==== Identify Options ====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

=== Decide ===

==== Direction ====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

==== Identify and Select Experiments ====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

=== Act ===
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

==== Shape Experiments ====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

==== Patterns and Practices as an input ====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

==== Shaping Parallel Experiments to Speed Learning ====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

=== Run Experiments - Observe ===

==== Support ====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

===== Prompts and Triggers =====
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

===== Skills and Capabilities =====
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

===== Culture Impact =====
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

==== Gather Data ====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

=== Orient ===

==== Analyse ====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

==== Identify Options ====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

=== Decide ===
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

=== Act ===

==== Evolve and Broaden ====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

==== Revert ====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-13T17:12:24Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|775x775px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

[[index.php?title=File:Catalyse_Purpose.png|link=File:Catalyse_Purpose.png|alt=Start by catalysing the purpose and driving forces for change|right|114x114px]]

=== Catalyse Purpose! ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

===Orient ===
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

==== Inspect with ELSE Principles ====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

==== Identify Options ====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

=== Decide ===

==== Direction ====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

==== Identify and Select Experiments ====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

=== Act ===
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

==== Shape Experiments ====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

==== Patterns and Practices as an input ====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

==== Shaping Parallel Experiments to Speed Learning ====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

=== Run Experiments - Observe ===

==== Support ====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

===== Prompts and Triggers =====
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

===== Skills and Capabilities =====
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

===== Culture Impact =====
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

==== Gather Data ====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

=== Orient ===

==== Analyse ====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

==== Identify Options ====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

=== Decide ===
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

=== Act ===

==== Evolve and Broaden ====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

==== Revert ====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-13T17:06:03Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|775x775px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! [[File:Catalyse Purpose.png|alt=Start by catalysing the purpose and driving forces for change|114x114px]] ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

===Orient ===
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

==== Inspect with ELSE Principles ====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

==== Identify Options ====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

=== Decide ===

==== Direction ====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

==== Identify and Select Experiments ====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

=== Act ===
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

==== Shape Experiments ====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

==== Patterns and Practices as an input ====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

==== Shaping Parallel Experiments to Speed Learning ====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

=== Run Experiments - Observe ===

==== Support ====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

===== Prompts and Triggers =====
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

===== Skills and Capabilities =====
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

===== Culture Impact =====
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

==== Gather Data ====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

=== Orient ===

==== Analyse ====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

==== Identify Options ====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

=== Decide ===
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

=== Act ===

==== Evolve and Broaden ====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

==== Revert ====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-12T18:05:02Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|775x775px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! [[File:Catalyse Purpose.png|alt=Start by catalysing the purpose and driving forces for change|114x114px]] ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

====Orient ====
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

===== Inspect with ELSE Principles =====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

===== Identify Options =====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

==== Decide ====

===== Direction =====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

===== Identify and Select Experiments =====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

==== Act ====
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

===== Shape Experiments =====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

===== Patterns and Practices as an input =====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

===== Shaping Parallel Experiments to Speed Learning =====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

==== Run Experiments ====

===== Support =====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

====== Prompts and Triggers ======
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

====== Skills and Capabilities ======
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

====== Culture Impact ======
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

===== Gather Data =====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

==== Orient ====

===== Analyse =====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

===== Identify Options =====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

==== Decide ====
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

==== Act ====

===== Evolve and Broaden =====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

===== Revert =====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-12T18:03:30Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[index.php?title=File:Change_Posture.png|link=File:Change_Posture.png|alt=Organisations that resist change tend to have a declining postion in their market.|600x600px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! [[File:Catalyse Purpose.png|alt=Start by catalysing the purpose and driving forces for change|114x114px]] ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

====Orient ====
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

===== Inspect with ELSE Principles =====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

===== Identify Options =====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

==== Decide ====

===== Direction =====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

===== Identify and Select Experiments =====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

==== Act ====
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

===== Shape Experiments =====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

===== Patterns and Practices as an input =====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

===== Shaping Parallel Experiments to Speed Learning =====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

==== Run Experiments ====

===== Support =====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

====== Prompts and Triggers ======
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

====== Skills and Capabilities ======
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

====== Culture Impact ======
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

===== Gather Data =====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

==== Orient ====

===== Analyse =====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

===== Identify Options =====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

==== Decide ====
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

==== Act ====

===== Evolve and Broaden =====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

===== Revert =====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-12T18:02:25Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|alt=Organisations that resist change tend to have a declining postion in their market.|left|600x600px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! [[File:Catalyse Purpose.png|alt=Start by catalysing the purpose and driving forces for change|114x114px]] ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

====Orient ====
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

===== Inspect with ELSE Principles =====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

===== Identify Options =====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

==== Decide ====

===== Direction =====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

===== Identify and Select Experiments =====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

==== Act ====
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

===== Shape Experiments =====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

===== Patterns and Practices as an input =====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

===== Shaping Parallel Experiments to Speed Learning =====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

==== Run Experiments ====

===== Support =====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

====== Prompts and Triggers ======
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

====== Skills and Capabilities ======
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

====== Culture Impact ======
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

===== Gather Data =====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

==== Orient ====

===== Analyse =====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

===== Identify Options =====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

==== Decide ====
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

==== Act ====

===== Evolve and Broaden =====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

===== Revert =====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-12T17:59:30Z

Cbird:

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|alt=Organisations that resist change tend to have a declining postion in their market.|left|600x600px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:
* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1112x1112px]]

=== Catalyse Purpose! [[File:Catalyse Purpose.png|alt=Start by catalysing the purpose and driving forces for change|114x114px]] ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

====Orient ====
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

===== Inspect with ELSE Principles =====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

===== Identify Options =====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

==== Decide ====

===== Direction =====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

===== Identify and Select Experiments =====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

==== Act ====
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

===== Shape Experiments =====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

===== Patterns and Practices as an input =====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

===== Shaping Parallel Experiments to Speed Learning =====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

==== Run Experiments ====

===== Support =====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

====== Prompts and Triggers ======
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

====== Skills and Capabilities ======
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

====== Culture Impact ======
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

===== Gather Data =====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

==== Orient ====

===== Analyse =====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

===== Identify Options =====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

==== Decide ====
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

==== Act ====

===== Evolve and Broaden =====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

===== Revert =====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

The Change Perspective

2025-02-12T17:55:00Z

Cbird: Version 3 initial upload!

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity. Agility is required not just for teams but also at an organisational level.

''ELSE is a continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance organisational agility at scale''.

[[File:Change Posture.png|alt=Organisations that resist change tend to have a declining postion in their market.|left|600x600px]]

Those organisations that can’t or won’t adapt are destined to decline and go the way of the dinosaurs. Some organisations will change just fast enough to survive, whilst others won’t just respond, their ability to innovate their products and capabilities will create a competitive edge and contribute to the pace of change.
Leadership has a fundamental responsibility to help unleash their organisation’s human potential to continually out-learn and out-adapt competitors. Any scaling endeavour will require adaptation from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its ecosystem.

The ability to continually change must be incorporated into an organisation's DNA rather than treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

Organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:ForcesAgainstChange V2.png|alt=Changes is resisted by Ingrained Habits, Fear of Change, Size & Scope of Change, Risk of Change, Difficulty of Change, and Little Motivation for the change.|600x600px]]

Many personal, group and systemic factors push back against proposed changes. Some of these are illustrated above and are discussed further below:

* Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
* Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
* Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
* Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
* Difficulty of Change - The proposed changes may require new or rare skills, or organisational support capabilities that are immature or yet to be implemented.
* Lack of Motivation - The need for change has not been widely established and communicated or belief and trust in the proposed changes are lacking.

The approach to change has to address these challenges to have a chance of success.

== Evolutionary and Emergent Change Model ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing a sociotechnical system is an inherently difficult and unpredictable business, often resulting in unforeseen side effects. Designing an ideal comprehensive target model for your change and then performing a transactional transition is destined for failure.

Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. ELSE offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The ELSE Change Model is illustrated below. The outline of the change cycle is modelled as an outer OODA loop that uses [[Actionable Principles|ELSE Actionable Principles]] to help guide where change is required and in which direction. An inner OODA loop models the Experiment and Learn cycle to emerge and establish new practices.

[[File:ELSE Change Model-Purpose.png|alt=An evolutionary and empowering change process modelled with 2 nested OODA loops.|1149x1149px]]

=== Catalyse Purpose! [[File:Catalyse Purpose.png|alt=Start by catalysing the purpose and driving forces for change|114x114px]] ===
Given the challenges of change, there needs to be clear and agreed reasons that will motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and detail of the evolving changes.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes must be formed in collaboration with those involved and impacted by potential changes. The alternative, the top-down imposition of purpose, is unlikely to have the necessary ownership and buy-in and could lack essential input from diverse perspectives. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]

[[File:Observe-Outer.png|alt=Observe - Engage Peiople, Create Safety, Map Context|right|200x200px]]

=== Observe ===
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational structure.

We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.

====Engage People====
[[Involve those affected by change]] in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they lack understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. In addition, ensure that we ask “What assumptions are we making?” to ensure that assumptions are explicitly recognised so that we can decide how best to validate or invalidate them. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”''a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…''”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

Allow people to commit, rather than being committed to a change. Seeking volunteers for experiments increases engagement and empowerment, as well as ensuring that there is motivation to trial an experiment fairly.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
This step aims to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to address.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:
* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis
[[File:Orient-Outer.png|alt=Orient - Inspect with ELSE principles, Identify Options|right|200x200px]]

====Orient ====
Orient is primarily a “divergent” activity, making sense of the observations and generating diverse options whilst delaying commitment to a specific way forward.

===== Inspect with ELSE Principles =====
“''If you only have a hammer, you tend to see every problem as a nail.''” Abraham Maslow

Best practices and patterns are typically the “hammer” resulting in a poor fit to specific organisational contexts. We must work a little harder and apply principles that can inform the emergence of better practice that is appropriate for the current context. Given that the context will change, this has to be a repetitive cycle of evolutionary change.

With a comprehensive map and understanding of the current context, inspect with common sense and the ELSE Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

With the application of the collective diverse perspectives of stakeholders, the mapping exercise often reveals previously hidden challenges. Others require the application of the principles as their impacts may be harder to spot or pin down the causes.

Use the ELSE Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a list of areas for improvement that can be ordered by impact.

===== Identify Options =====
With the ordered list of improvements as input, engage stakeholders to generate multiple diverse options for improvement experiments.

Focus on scaling “Value” rather than assuming the need to scale the size of the development system. First consider “De-scaling” by exploring options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead. For example, team performance often suffers from interdependencies that cause delays and prevent completion of work. We could choose an option to add additional meetings to manage the dependencies, or we could look to reduce the dependencies by simplifying the product and team structures.

Supporting Principles:

* [[Involve those affected by change]]
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Minimise unnecessary complexity]]
* [[Committed to required structural changes]]

[[File:Decide-Outer.png|alt=Decide - Direction, Identify & Select Experiments|right|200x200px]]

==== Decide ====

===== Direction =====
To quote Dave Snowden “''In complexity, you describe the present and see what you can change. You define a direction of travel, not a goal.''”

So, instead of a future end state, we define how we will recognise whether we are making improvement. This direction of travel then provides context for selecting experiment options that appear to be good bets.

===== Identify and Select Experiments =====
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks, and gaining empirical data that enable better planning and decision-making for the next steps.

When selecting options, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|760x760px|alt=Prioritise the order of changes: First shape Products & Services, then Product Ownership and then Teams]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Options can be assessed and prioritised by many factors, including:

* Positive impact
* Financial cost
* Effort
* Availability of required skills or capability
* Availability of willing volunteers
* An event that provides context and motivation
* Risk and blast radius
* Resistance
* Elapsed time to feedback and learning

Supporting Principles:
*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]
[[File:Act-Outer.png|alt=Act - Shape, Run Experiments, Emerge Practice|right|463x463px]]

==== Act ====
It is now time to shape, initiate and support the experiments in an incremental cycle. Framing changes as experiments provided the safety to ”fail” and learn as a natural part of complex change where outcomes are not certain and failure should be expected. Even successful experiments will have lessons and improvements emerging from them. Successful Emergent Practice can be shared and experimentally broadened as appropriate.

===== Shape Experiments =====
Intentionally frame potential changes as “Experiments” to ensure that we are admitting that we don’t know everything and the outcome is by no means certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as “an unexpected outcome of the experiment that provides an opportunity to learn”. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

* The “Why” - context of the challenge to the Scaling principles.
* The outcome we hope to see.
* Experiment plan outline
* When - how long we expect to run the experiment and observe results.
* Who - people involved and impacted.
* What changes - structure, systems, processes, policies, skills, roles, etc.
* Validation - how we will assess outcome progress and success.
* Key assumptions, challenges and risks.
* Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what to change - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see [[Start small and scale success]].

===== Patterns and Practices as an input =====
Practices and patterns harvested from external sources such as scale frameworks and other organisations are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptation based on the outcomes of small experiments.

===== Shaping Parallel Experiments to Speed Learning =====
Intentionally running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

* The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
* Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

* [[Involve those affected by change]]
* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose|Create Clarity of Purpose]]
* [[Limit Work In Progress]]

[[File:Observe-Inner.png|alt=Observe - Support, Gather data|right|200x200px]]

==== Run Experiments ====

===== Support =====
Without support, many experiments are destined to wither and die before they can provide learning or change. Leadership keeps momentum for change by ensuring continued focus on improvement as part of day-to-day work and reducing the friction caused by the existing environment.

It is often necessary for leaders with sufficient seniority to provide the authority to bend or break the current formal and informal rules and processes. In addition, it is easy for experiments to lose their way and regular restating and reinforcement by leadership of the purpose and intended direction of travel provide the stability of intention.

Those in leadership or influential positions can support experiments in the following ways:

* Regularly refresh and reinforce the purpose to keep aligned on the “Why”.
* Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
* Create enough time to trial new ideas. Many changes fail simply due to delivery pressure and focus.
* Help understand and mitigate or resolve impediments.
* Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

====== Prompts and Triggers ======
Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to initiate new behaviours. If we don’t plan to work differently, we will carry on in the same way and nothing will change! An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

====== Skills and Capabilities ======
Address shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through. Furthermore, supporting the professional growth of the people will help in keeping them engaged with the change process.

====== Culture Impact ======
Organisational culture is notoriously difficult to influence directly. Initiatives to improve culture almost always fail. Culture is an outcome of the way we work, so by using experiments to gradually change how work is done, indirectly impacts culture.

From John Shook’s work and learning from his [https://www.lean.org/downloads/35.pdf NUMMI] experience (<nowiki>https://www.lean.org/downloads/35.pdf</nowiki>), we know that behaviour drives culture, values, attitudes and thinking rather than the traditional idea of teaching people new ways of thinking first.

An experiment that incorporates new or changed behaviours, processes, systems, artefacts or environmental context, is likely to evolve the culture of those impacted. As a successful experiment is adopted more broadly the breadth of the cultural impact also increases. So, changes made to the working environment and its associated systems and processes will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

Another relevant study revealed: “Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - see [https://greatergood.berkeley.edu/images/uploads/Darley-JersualemJericho.pdf The Good Samaritan Study].

Supporting Principles:

* [[Foster a high trust environment]]
* [[Committed to required structural changes]]
* [[Provide an impediment removal service]]
* [[Catalyst for change]]
* [[Create clarity of purpose]]

===== Gather Data =====
The purpose of an experiment is to learn and this requires that information is generated and harvested, regardless of whether the outcome was as expected. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

[[File:Orient-Inner.png|alt=Orient - Analyse, Identify Options|right|200x200px]]

==== Orient ====

===== Analyse =====
When it comes to cultivating a Safe to Fail culture, asking questions like "''What can we learn from this outcome?''" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes (using the 5 Whys and other techniques) to ensure depth understanding, learning and adaptations that don’t just address symptoms.

===== Identify Options =====
Once we have established root causes and sufficient understanding, generate diverse options for improving the outcome. These may include options to refine the experiment and keep running it, adopt the experiment more broadly or abandon it and select another option entirely.

[[File:Decide-Inner.png|alt=Decide whether to - Adapt, Adopt or Abandon th experiment|right|200x200px]]

==== Decide ====
Based on what has been learned so far, decide on the best option to take the next step forward.

[[File:Act-Inner.png|alt=Act - Evolve, Broaden or Revert the experiment|right|225x225px]]

==== Act ====

===== Evolve and Broaden =====
It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]

Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be carried out in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

* [[Start small and scale success]]
* [[Scale only when you need to]]
* [[Evolutionary over revolutionary change]]
* [[Involve those affected by change]]

===== Revert =====
Experiments must be allowed to fail as they will not always have positive outcomes or may come with unforeseen side effects. When this happens, implement actions to revert the experiment and celebrate the learning!

Emerge Practices

Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as Exaptation.

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

==== Repeat! ====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

* The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
* Organisational change is complex and requires an iterative and incremental evolutionary approach.
* Don’t Copy & Paste “Best Practice”, instead emerge context specific practice through experimentation and learning.
* Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
* A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
* Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
* Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
* Support workshops with appropriate collaborative mapping techniques.
* Identify and prioritise options for experiments.
* “De-scale” - always consider options for reducing the complexity of the current context!
* Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
* Shape, support, and incorporate learning from experiments into emergent practices.
* Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "''From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.''] Journal of Personality and Social Psychology, 27(1), 100.

How to Change a Culture: Lessons From NUMMI - Shook, John ''https://sloanreview.mit.edu/article/how-to-change-a-culture-lessons-from-nummi/''

File:Act-Inner.png

2025-02-12T17:40:30Z

Cbird:

Act - Evolve, Broaden or Revert

File:Decide-Inner.png

2025-02-12T17:38:42Z

Cbird:

Decide - Adapt, Adopt, Abandon

File:Orient-Inner.png

2025-02-12T17:31:26Z

Cbird:

Orient - Analyse, Identify Options

File:Observe-Inner.png

2025-02-12T17:21:45Z

Cbird:

Observe - Support, Gather data

File:Act-Outer.png

2025-02-12T16:57:55Z

Cbird:

Act - Shape, Run Experiments, Emerge Practice

File:Decide-Outer.png

2025-02-12T16:50:37Z

Cbird:

Decide - Direction, Identify & Select Experiments

File:Orient-Outer.png

2025-02-12T16:43:42Z

Cbird:

Orient - Inspect with ELSE principles, Identify Options

File:Observe-Outer.png

2025-02-12T16:36:00Z

Cbird:

Observe - Engage Peiople, Create Safety, Map Context

File:Catalyse Purpose.png

2025-02-12T16:30:53Z

Cbird:

Start by catalysing the purpose and driving forces for change.

File:ELSE Change Model-Purpose.png

2025-02-12T16:26:50Z

Cbird:

An evolutionary and empowering change process modelled with 2 nested OODA loops.

File:ForcesAgainstChange V2.png

2025-02-12T16:15:15Z

Cbird:

There are many forces pushing back against change

File:Change Posture.png

2025-02-12T16:05:18Z

Cbird:

How organisations view change

Emergent Practice

2025-02-05T15:02:03Z

Cbird: Created page with "Rather than imposing new practice, new and evolving methods or techniques are encouraged to develop organically over time as people experiment, learn, and adapt to new conditions or challenges. These practices often arise in response to complex, dynamic environments where traditional approaches may not be sufficient. The advantages of letting practice emerge include: * Emerged practice can consider and fit the specific context. * Practice can continue to evolve over ti..."

Rather than imposing new practice, new and evolving methods or techniques are encouraged to develop organically over time as people experiment, learn, and adapt to new conditions or challenges. These practices often arise in response to complex, dynamic environments where traditional approaches may not be sufficient.

The advantages of letting practice emerge include:
* Emerged practice can consider and fit the specific context.
* Practice can continue to evolve over time, to match changing context and pursue improvement.
* Innovative new approaches can be discovered over copying “Best practice” from other organisations.
* Existing methods and techniques within the organisation can be co-opted and “Exapted” for functions that they were not originally intended.

See [https://thecynefin.co/about-us/about-cynefin-framework/ Cynefin]

Glossary

2025-02-05T14:47:25Z

Cbird:

__NOTOC__
This section contains descriptions of items that we have used throughout the principles.

* [[Product]]
* [[Value Stream]]
* [[Linear Value Stream]]
* [[Composite Value Stream]]
*[[Partial Value Stream]]
* [[Product Line]]
* [[Scope of Accountability for a Product Owner]]
* [[Outcome]]
* [[Value of a Product]]
* [[Accidental Complexity]]
* [[System of Work]]
* [[Specialist skill sets|Specialist Skill Sets]]
* [[Teams of Specialists]]
*[[Cognitive Load]]
*[[Mental Workload]]
*[[Product Ownership Group]]
*[[Solution Accountability]]
*[[Business Domain Accountability]]
*[[The Teams' Perspective#Effective Autonomy with Boundaries|Bounded Autonomy]]
*[[Team of Teams]]
*[[Team Autonomy]]
*[[Cognitive Diversity]]
*[[Product Increment]]
*[[Learning Cycles]]
*[[Emergent Practice]]

Why ELSE?

2024-07-31T10:54:22Z

Cbird: /* Advantages of the ELSE Approach */

We observe a very high rate of failure of large-scale agility programmes, going by names such as Agile Transformations or scaled product delivery.

Scaling agility requires fundamental changes to an organisation as it is much more than a process change. Applying a new framework rarely results in sustained and positive change, with additional processes dragging progress and old habits reasserting themselves. To increase the probability of success, ELSE incorporates the following high-level ideals:

* Start from where you are: Any change has to start from the current state of an organisation. This is the real state - how things actually get done, both formal and informal and probably not as it is written in the documentation.
* Complexity: Recognise that organisations are complex adaptive systems, requiring an iterative change process informed by feedback loops rather than a large transactional change to a new target operating model.
* Emergent practice: An almost infinite number of potential patterns and practices can be applied in scaling situations. The choice of a specific pattern for a given context should not be because it is considered “Best practice” and part of a collection of patterns in a framework. Instead, the choice should be informed by fundamental principles and validated and evolved through experiment.
* Inclusive change: Ensure that change is not “done to people” but instead “with people”. Involve those impacted by a change in a collaborative exploration of the current context and generation of potential incremental improvement experiments.
* Small changes: Reducing the size of change lowers the fear and risk of change and speeds up learning.
* Continuous improvement is a core competitive capability. For this reason, an improved capability of supporting change is a key target outcome of the change process!
* Success at scale requires organisational agility: A scaled challenge is unlikely to function in an isolated bubble outside an organisation’s environment. It will require improved support and reduced impediments from the organisation to reach its full potential.

Dealing with all that cannot be done by applying recipes, and it cannot be done in a one-shot transformation. It’s, instead, a journey of discovering what makes your organisation more effective.

For this journey, go-ELSE:
* '''Emergent''': there are no recipes or one-size-fits-all solutions available. It needs to be a discovery process that emerges practice guided by [actionable] principles.
* '''Large-Scale''': Lean and Agile ideas are applied to large-scale challenges to reduce the relative complexity and increase value creation. The goal is to reduce the amount of wasted work and overhead required to produce valuable outcomes. At scale, the principle 10 of the Agile Manifesto, i.e. the art of maximising the amount of work not done, means streamlining the organisational structures to enable effectiveness.
* '''Evolution''': because it’s not a one-shot effort. It will take time and focus, and it is often a struggle. However, The result is an organisation that can sustain effectiveness both in delivering outcomes and improving itself over time.
=== Advantages of the ELSE Approach ===
''“Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation. Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves.”''

Implementing Lean Software Development - From Concept to Cash, Mary and Tom Poppendieck

Regardless of their provenance, applying new processes, roles, policies, structures, and systems rarely results in sustained and positive change, with old habits reasserting themselves.

The ELSE approach intends to avoid or mitigate the following contributory causes of failure common in Agile change initiatives:

* Approaching change as a large transactional process, moving directly from the current state to a designed ideal future state. The larger the change, the greater the fear, risk and probability of failure.
* Topdown imposition of new processes, policies and roles leads to disempowerment, a lack of buy-in and poorly informed changes.
* Starting with incorrect assumptions or a lack of in-depth understanding of the starting context for how the organisation currently functions. This point is related to another: a failure to engage the people who have the necessary knowledge and will additionally be the people who will have to enact changes.
* A belief in the concept of “Best Practice” leads to blind and unthinking adoption of an entire set of practices or framework as a monolith, regardless of the suitability of specific elements to aspects of the organisation. The larger a framework, the less likely it will fit any given context in its entirety.
* Simply overlaying new processes, policies, roles and systems onto the current organisational system creates additional overhead. Instead, they should be implemented with an understanding that an evolutionary but fundamental shift in leadership, roles, policies, structure, and culture will also be required.
* Renamed but still the same - existing roles, processes, policies and systems are renamed but remain largely the same, creating confusion and little to no benefit.
* Agile and agility are viewed as only relevant to engineering rather than understanding that agility is an end-to-end business value proposition, including leadership, organisation design and supporting services.

In summary, comprehensive scaling frameworks are seductive as they appear to be “Best Practice” and have all the answers. The reality is that there is no shortcut! The ELSE approach mitigates or avoids many of the pitfalls of challenged scaling endeavours with a flexible strategy for the emergence of scale patterns.

The Product Perspective

2024-05-21T15:47:59Z

Cbird: /* A Product+Owner */

__NOTOC__
== A Product+Owner ==
The Product Owner is most definitely the most misunderstood role in Scrum. There are good reasons why this happens, as a proper implementation of that role usually requires a change in how the organisation is structured.

We start by considering a small organisation using Scrum where just one team is working on a particular product this company is creating. The Developers have everything in their hands; they have all the competencies necessary to “get the job done”. Of course, this makes their work very flexible and adaptive: if there is anything they need to change in their development, they can meet shortly, decide what to change and implement it.

For their business priorities, they rely on their Product Owner. This person is “accountable for maximising the value of the product resulting from the work of the Scrum Team”<ref>https://scrumguides.org/scrum-guide.html</ref> or is “responsible for maximising return on investment (ROI)<ref>https://www.scrumprimer.org/</ref> by identifying product features, translating these into a prioritised list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritising and refining the list.

The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. In the case of an internal application, the Product Owner is not responsible for ROI in the sense of a commercial product (that will generate revenue). However, they are still responsible for maximising ROI by choosing – each Sprint – the highest-value items. (Principle: [[The Product Owner is accountable for sustained end value]])

The Product Owner for this Scrum Team is probably either the owner of the company or somebody very close to that role. As such, this person understands the business and can drive the priorities in the Product Backlog to devise sensible business tactics and strategies depending on various constraints: financing, customer wishes, personnel-related issues and strengths, etc... The scope of these decisions is the Product as a whole. These “global” decisions impact the Product and the company betting on it.

This Product Owner knows every developer, stakeholder, and competitor one by one and interacts with them daily and is available for questions, clarifications, and discussions. It’s not just the decisions that characterise this Product Owner but also how this person can create a shared vision for the Product. Sure enough, the authority to decide lies in their hands and the responsibility for the Product's success: true accountability.

In this setting, decisions are swift: let’s talk to the Product Owner! In this way, we can have real adaptability at the Product level, which is the actual meaning of agility! (Related Principle: [[PO should inspect to see if outcomes have been achieved]])

We could say that this Product Owner is a “Product” and “Owner” in the sense that their decisions span the entire scope of the Product, and the Product Owner is accountable for those, i.e. has authority and responsibility.

== But... at Scale? ==
Let’s imagine now a company producing several “products” that result from the work of hundreds or even thousands of people, maybe overarching different companies, technologies and technical domains, and where there are several “components” that are common to several of those products. An excellent example to grasp the potential complexities is a car manufacturer. Several “platforms” are used to build different car models, yet the engines, and brakes, ... are built not only for those but for even more platforms. Even more: when the car is produced, it’s not the end of the “product”: your customers expect to get customer support to be able to find spare parts, ... and car manufacturers are moving more and more into the services market.

How do you define a “product” in this scenario? The problem is even more complex: how do you define a “product” in a way that helps you to adapt the product as fast as possible so that you can be as agile as possible?

Imagine for a second the scenario mentioned before. It would be great if it were possible to have your product developed by a small team of Developers under the direction given by a Product Owner. Still, the size of the development (number of people involved, amount of time, ...) is likely to make it very difficult, if at all possible, to keep this straightforward setup. So what parameters must we consider when defining a structure of Product Ownership at scale?

== “Scale” is for Products, not for Organisations ==
First, a clarification on the usage of the word “Scale” in the context of Products: it has to do with the size of the Product, not with the size of the organisation! Imagine a big company developing dozens or hundreds of small products, each involving one team of Developers and each led by a Product Owner. While the organisation might be large, we can simply create many independent Scrum Teams and let them loose in pursuing value.

The Product Owners might work according to a company vision and might even align to avoid overlapping products and compete for the same customers. Yet, the model of the single autonomous Scrum Team still holds. No “scaling” is needed.

Now imagine a small company where there is a handful of teams working on the same Product: while the company might be small, the Developers are stumbling on the changes made by their peers in other Teams, hence the need to coordinate the work of the Team, hence the need to scale.

So whether we need some form of Scaling concept depends on the size of the Product, not on the size of the Teams!

'''Definition:'''

'''Scaling''' = a set of techniques used to enable two or more teams of Developers to cooperate when working on the same Product

== A Product Owner can deal with more than one team ==
One widespread way to organise several teams of Developers working on the same product is to have one Product Owner per Team. This is primarily due to a misunderstanding of Scrum. While it’s true that every Team sees exactly one Product Owner to get the priorities from one single source, the opposite is definitely not true. (Principle: [[Each team "sees" exactly one Product Owner]])

We suggest that a Product Owner focusing on prioritisation and leaving all the analysis and design work to the Teams can drive the direction of many Teams (though there will be a limit...). (Practice: [[One Product Owner may have multiple Teams]], Principle: [[Minimum Viable Product Owners]])

== Small and Big Product Owners ==
Another typical pattern is having product owners take care of a particular aspect of a large system. An example is an e-commerce system that considers the product catalogue as a Product, the payments as another Product, and the shipment logistics as another Product.

Each of these Product Owners is dealing with a small part of an entire system, so regardless of their formal role, they usually have limited ownership for what concerns their part of the system, and every change that goes beyond the boundaries of their area is problematic as it requires synchronisation among Product Owners.

This means that system-wide decisions are often escalated to some senior management forum, usually called “program management”, “portfolio management”, or “steering committee”, and while some decisions might very well belong to that forum, there will also be a significant amount of low-level synchronisation issues that will be passed up the chain.[[File:Small POs PL diag.png|600x600px|thumb|“Small Product Owners” require a “portfolio management” to arbitrate priority conflicts|none]]

The configuration described is what we call “Small Product Owners”. While unavoidable in some cases, it reduces the overall adaptivity of the product given the usually large amount of escalations. A better alternative, where possible, is to opt for a “Big Product Owner”, i.e. a Product Owner with accountability over a wider part of the Product. This type of Product Owner encapsulates all the low-level decisions, escalating to senior management only the high-level strategic decisions determining which Product in the portfolio receives more funding.
[[File:Big POs PL diag.png|none|thumb|600x600px|A “Big Product Owner” encapsulates product decisions. Upper management is deciding how much to invest in each product]]

== Some Definitions ==
: '''Definition:''' A Value Stream for a business process is the series of steps to provide the product, service and/or experience the customer desires. '''Definition:''' Product is used in this context to mean an actual deliverable product and a service and/or an experience desired by the customer. So, the Value Stream is the process that results in the Product:
[[File:Linear Value Stream PL diag.png|none|thumb|515x515px|A Linear Value Stream]]
i.e. we would ideally expect to have a Product Owner being accountable for the whole Value Stream that leads to a Product:
[[File:PO Scope of Accountability PL diag.png|none|thumb|552x552px|The Product Owner Scope of Accountability]]
We call this simple situation "[[Linear Value Stream]]".

However, at scale, the scenario is usually much more complex as the input from different clients is used to create several end products, trying to reuse as much as possible of the internal deliverables and create internal synergies. This is a situation we call "[[Composite Value Stream]]":
[[File:Composite Value Stream PL diag.png|none|thumb|515x515px|A Composite Value Stream]]
So, how are we going to define what is the Scope of Accountability for a Product Owner? How many Product Owners do we need? And how can they coordinate? To understand the most adaptive way to arrange a situation like the one above, we need to understand what the “Products” make sense to define. To do this, we need to consider several different parameters... (Principles: [[Minimum Viable Product Owners]], [[Collective accountability in case of Product Ownership Group]])

There might be a very simple answer to the question above: For a Composite Value Stream, only one Product Owner should take care of the whole "ecosystem" and be accountable for defining the optimum value delivery proposition. Sometimes this is a viable answer; if so, it should be chosen.

At scale, however, the sheer size of many Composite Value Streams, as well as the interplay with other organisational variables (different departments and different sites involved, teams with specialised knowledge, ...), makes it often impossible for a simple Product Owner to take care of the whole system. However, it needs to be always kept in mind that splitting the work into separate parts needs to be seen as an anti-pattern that causes
# The need for synchronisation points, i.e. more upfront planning (and less experimentation options)
# Localised knowledge and silo work
# Integration is shifted to later stages of development, thus postponing risks to later stages of development

The problems of products being built as the sum of the work of organisational parts have been described by Conway's Law<ref>https://en.wikipedia.org/wiki/Conway%27s_law</ref>. While sometimes this is needed, it is nonetheless a significant source of dependencies, coordination effort and political games, not to mention that the inability of each part to develop a complete and customer-focused product minimises the possibility of learning what is important for the customers and reduces the options for testing, thus resulting in longer and longer engineering cycles needed to validate the product being developed.

Regardless of the current structure, adapting the organisation toward an [[End-to-End Product]] is essential. This requires a focused effort at all organisational levels, and the details are explained in [[The Change Perspective]] and how the definition of product changes over time is a significant driver for change in the direction of agility.

Moving toward an End-to-End Product means having teams capable of working on larger and larger parts of the system. To do that, learning and creating teams with a broader solution and business domain accountability is paramount.

While on very large-scale developments, it might be impossible to reach a genuinely end-to-end-customer-focused Product, the path towards that goal results in fewer dependencies and more autonomous teams and, in the end, in a more adaptable organisation.

To do this, we must reduce [[Accidental Complexity]]! The path to reach a single Product Owner means working on progressively redefining what we consider a Product, simplifying the Product Development Organisation in successive steps.

Large organisations have several reasons why an End-to-End Product is not feasible. Some of these reasons are excuses that show a dysfunctional organisation. Here are a few examples:

* The product is too large/complex
* Our departments are organised in a different way
* There is no way our developers can work on such a large product at once
* We are organised in many different locations worldwide
* Our architecture does not permit a different way of working
* We need a system integration/test team to test everything in the end

The [[Teams]] and [[Craft]] principles describe in detail what are the problems caused by these assumptions and possible remedies.

To understand what that means in practice, we need to analyse what are the elements that influence a Composite Value Stream: the Product Dimensions.

== The Product Dimensions ==
We can look at Products from different sides, different “Dimensions”. By assessing our product's essential and accidental complexity in each of these dimensions, we can evaluate how to organise the Product Ownership of our system to minimise the number of Product Owners, yet be able to drive the business properly. In general, the higher the accidental complexity in a particular dimension, the narrower the scope of accountability we will give to a Product Owner, hence going in the direction of Small Product Owners. At the same time, the more we can reduce the accidental complexity, the more global the accountability of a Product Owner and the fewer Product Owners will be needed.

=== Business Dimensions ===
The first two dimensions have to do with the complexity of the business we’re in:

{|class="wikitable"
!Dimension
!Reasons to opt for Narrower Scope of Accountability
!Reasons to opt for a Broader Scope of Accountability
!Comments
|+
|Product Strategy
|If it is valuable to have parts of the Value Stream[s] visible as separate Products having their own strategy
|When global optimisation is important (common experience, integration of Products, synergies among Products, ...), in particular when a broader Scope of Accountability would help creating a better experience for our customers and end users
|The bigger the Product Owner, the more it becomes possible to drive global priorities in a complex system and deliver value to customers and end users: deliverables composed of several "components" to be assembled before the final delivery require additional organisational complexity. On the other hand, sometimes it makes sense to disconnect the strategy of several Products to allow them to be steered fast in their respective markets.
|-
|Multi-Product Strategy
|Business Strategy of parts of the Value Stream[s] is more important than global decisions
|Multi-Product synergies are more important
|This is often an “Enabling Constraint” from the organisation, i.e. this is a deliberate choice to promote the integration of several products to be sold together.
|}

Note that while it’s true that reducing accidental complexity will lead to a simpler structure of Product Ownership when it comes to the business dimensions, it is your decision on whether it makes sense to reduce complexity or whether the additional complexity seems reasonable and produces value for the company!

=== Constraints Dimensions ===

This second group of dimensions considers the aspects that might limit your decisions about what a Product is. Contrary to the Business Dimensions, accidental complexity in these dimensions is always problematic and worth removing. Trying to remove this complexity might, in fact, be the way to drive the company transformation over time!

{|class="wikitable"
!Dimension
!Reasons to opt for Narrower Scope of Accountability
!Reasons to opt for a Broader Scope of Accountability
!Comments
|+
|'''Technological:''' the number of different technologies that are needed to create the product
|Many different technological domains
|Fewer technological domains to cover or Developers learning more technologies
|Developers have difficulties managing the overall scope of the development because of the sheer amount of technologies involved in building the product, hence the need to compartmentalise development and increase the coordination points. It is important to note that many companies opt for compartmentalisation of knowledge, hence creating artificially many apparently different technologies. For example, separating front- and back-end developers in different teams creates two “disciplines” that have no real reason to be different.
|-
|'''Technical:''' the technical practices used by the Developers
|Development practices outdated
|Technical excellence is the focus of the Developers
|The application of modern technical practices - including widespread automated testing - simplifies experimentation and supports learning, hence reducing the need for information silos.
|-
|'''Product Size:''' how many people are involved in the development of the product
|Larger products will make it more difficult to have a Broad Scope of Accountability for a Product owner
|Reducing accidental complexity will help manage larger product developments while keeping a Broad Scope of Accountability for Product Owners
|Size is seen as one of the prime reasons to split a value stream into smaller parts. Yet companies are developing similar products with very different organisation sizes, and often smaller organisations are more effective than bigger ones. We believe accidental complexity plays a very big role in this dimension, and opting for a Narrow Scope of Accountability is a significant component in creating accidental complexity.
|-
|'''Value Stream complexity:''' Composite Value Streams are inherently more complex to handle
|Complex Value Streams might require to be split into parts
|There is value in having a Product Owner responsible for the whole Value Stream
|It is important to look at why the value stream is complex: often accidental complexity creeps in for various reasons: organisational history and structure, habits, no refactoring on the process, power structures, different locations, information silos, ...
|-
|'''Human Factors:''' We’re still humans, so things can go wrong even with a “perfect” process
|Silos knowledge, lack of communication skills, multiple locations and remote communication, interpersonal problems, latent conflicts, ...
|Individual and interactions, face-to-face communication, co-location, Developers interacting with the Stakeholders...
|The way we interact is often an additional problem “on top” of the others: learning to interact and communicate at the product organisation level as well as keeping the energy and focus of working in small Teams. Here is where the support of professional facilitators can help and agile has a lot of suggestions for this dimension!
|-
|'''Politics:''' What should not happen in a company, but often plays an important role
|Internal and inter-company politics play a role in how a value stream is organised: the more present and important they are in an organisation, usually the more the value stream will be split in parts in order to cater for the need of more roles with organisational power
|
|Interestingly enough, lack of product focus (and customer centered approach) is an important reason why internal politics become a game people play. We have noticed many times that reorganising the company around customer value reduces the weight of politics and, more in general, of the other social networks of the company.
|-

|'''Organisational Structure:''' Often a product is being developed by a suboptimally structured product development organisation, either due to lack of understanding or, more often, due to historical reasons
|The more organisational silos, the more information is isolated, resulting in more fractalised development. Loyalty to managers and organisational silos trumps loyalty towards the product vision and the customer
|A properly organised product development organisation helps to organise teams around customer value
|This often requires a radical management-led restructuring: a kaizen approach usually fails at the department boundaries, requiring a Kaikaku instead. This is why it is important for management not only to “support” an agile organisation but to be directly involved in creating it. Organisational Design principles help inform the change. Conway's Law<ref>https://en.wikipedia.org/wiki/Conway's_law</ref> is a popular way to describe the problem.
|}

And, in your organisation, there might be additional dimensions to consider...

== Using the dimensions ==
One of the most common problems in an agile transformation is to define “what is our product[s]”. This is especially true in companies with complex composite value streams: the discussion is not trivial. It becomes fundamental to drive the agilisation of the company properly. As we have previously seen, agility promotes using a product development organisation to deliver products. Hence, the process of re-organising around products is a central driving force of this work. (Principle: [[Minimum Viable Product Owners]], [[Minimise unnecessary complexity]])

In this re-organisation process, removing accidental complexity is paramount to getting to a “more agile” organisation than the original one. However, this process has many practical limitations due to the current organisation and what is realistically possible. Here is where the dimensions of a product become helpful. Consider a company with a composite value stream to deliver several products to the market. This is often done by taking various parts of the value stream and mapping them as “projects” under the lead of a project manager and coordinated by a PMO, portfolio management or a similar structure.

In practice, these are all silos that interact via pre-defined organisational interfaces, creating an interdependent system where every deviation becomes a project management nightmare. While this scenario is already challenging to set up in a production environment where the cycle repeats over and over, it is way more complex to handle in product development where the nature of the activities is less predictable and less repetitive. As such, improving how a company works could and should pass through repeating cycles of improving the product definition, each time looking at the product dimensions and understanding how to reduce accidental complexity in each constraint dimension.

It is important to notice there is no single strategy to implement these changes: sometimes, it is as easy as bringing the technicians together to "merge" some part of the organisation into a bigger Product definition. Sometimes the change is led by management changing the organisational structures to create a larger Product. Sometimes it might take years and a treacherous path to reach there, involving company politics, management egos, cultural differences, ...

And, sometimes, it cannot be done at all, but this is the crux of every organisational development initiative.

Colin Bird

2024-02-05T15:23:49Z

Cbird:

[[File:Colin.png|left|frameless|329x329px]]
Although best known for my long association with Scrum, I love everything Lean, Agile and Kanban. I get a buzz out of catalysing new ideas, collaboration, creativity and innovation to engage the full potential of teams and leadership. Since 2005, I have been assisting organisations wrestle with the challenges of retaining agility as the scale of the challenge moves beyond a single team. My experience spans many different sectors, and involves a broad spectrum of organisational elements, including strategy, budgeting, portfolio management, leadership, team design and engineering at scale. I enjoy using my hard-won years of team and senior leadership experience to help others.

I am an Agile coach and consultant, a Certified Scrum Trainer (CST) and Certified Agile Leadership (CAL) Trainer for the Scrum Alliance.

Away from work, I try and squeeze in way too many sports and hobbies: road cycling up mountains, trail running with my dog, sailing, skiing, diving and lots of DIY projects!

website: https://ripple-rock.com https://www.linkedin.com/in/colinbird

Location: London, United Kingdom

Maximise engagement

2024-01-30T11:46:54Z

Cbird: /* Related Research */

__NOTOC__
== Description ==
Leaders have a responsibility to maximise the engagement of the organisation's human capability to harness the potential creativity and cognitive abilities. This will enhance the organisation's chances of surviving and thriving, and it will also improve the culture, morale and staff retention.

== Rationale ==
The regular engagement survey from Gallup shows that 70% of employees are not engaged. <ref>https://www.gallup.com/workplace/313313/historic-drop-employee-engagement-follows-record-rise.aspx</ref> Employee engagement is highly related to many performance outcomes, lack of engagement has significant potential performance consequences.

Forbes defines Employee engagement as "the emotional commitment the employee has to the organization and its goals." <ref>https://www.forbes.com/sites/kevinkruse/2012/06/22/employee-engagement-what-and-why/?sh=3bb61d997f37</ref> This emotional commitment means engaged employees actually care about their work, their team and their company. One of the main reasons for employee disengagement is a lack of purpose or meaning in the work. Sometimes, a company’s vision doesn’t resonate with employees. Or the company may fail to give its employees purposeful, meaningful work to perform.<ref>https://xl.net/thought-leadership/top-reasons-employee-disengagement/</ref>

Therefore leaders should ensure followers have a clear connection to organisational goals, they care about their fellow team members, and they are given the space to engage in problem-solving and actively practice personal growth in their skills and relationships with others.

Much of the research we refer to in leadership is interconnected, has many similarities and supports this broad view.

Whilst extrinsic motivational factors, rewards or other incentives like praise, money or fame do provide a level of motivation, intrinsic motivation encourages cohesive interaction and a higher degree of effort and long-term performance (Pinder 2011)<ref>https://www.amazon.co.uk/Motivation-Organizational-Behavior-Craig-Pinder/dp/0805856048</ref>. Self-determination theory (Ryan & Deci, 2017)<ref name=":0">Self-Determination Theory: Basic Psychological Needs in Motivation, Development, and Wellness (1st ed.). Guilford Publishing.</ref>, provides one of the most robust models for human motivation.

For complex, knowledge-based, problem-solving work, once so-called hygiene factors have been satisfied (such as enough money), there are three main factors that drive motivation in the workplace (and hence engagement). These are autonomy, competence and relatedness. Leaders should actively maximise these factors so that teams achieve higher levels of personal satisfaction and performance.

=== Related Research ===

* [[Self-Determination Theory - Deci & Ryan]]
* [https://www.thersa.org/video/events/2010/01/drive Drive - Daniel Pink]
* [[The Full Power of Engagement - Jim Loehr & Tony Schwartz]]<ref>https://www.amazon.co.uk/Power-Full-Engagement-Managing-Personal/dp/0743226755</ref>
* [https://hbr.org/2020/03/what-job-crafting-looks-like Job Crafting - Amy Wrzesniewski]

== Related Principles ==
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Create clarity of purpose]]
* [[Involve those affected by change]]
* [[Create a Learning Organisation]]
* [[Maximise team empowerment and localised decision making]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Accountability]]
* [[Self-managed teams]]
* [[Self-managed Team of Teams]]
* [[Maximise Team autonomy]]
* [[Organise around value streams]]

== Related Practices ==
[https://positiveorgs.bus.umich.edu/wp-content/uploads/Job-Crafting-Exercise-Teaching-Note-Aug-101.pdf Job Crafting Exercise] - Relies on the individual knowing their strengths, passions and values

== References ==
<references />

Foster a high trust environment

2024-01-30T11:36:30Z

Cbird: /* Rationale */

__NOTOC__
== Description ==
Trust is the foundation that enables teams to create great results for the organisation. Without trust, teams can't reach their potential. Trust is an essential element of Psychological Safety which was found by Google's Project Aristotle to be the number one factor differentiating the highest-performing teams.

Trust can be defined as “Choosing to make something important to you vulnerable to the actions of someone else.” <ref>https://www.uncrushed.org/content/2019/7/1/the-anatomy-of-trust-brene-brown</ref> Trust is built slowly over time, Brené Brown<ref>https://en.wikipedia.org/wiki/Bren%C3%A9_Brown</ref> uses a marble jar metaphor; “We can deposit marbles and build up our sense of trust or withdraw them and degrade that sense of trust through our interactions”.

Research has identified how establishing trust between people affects us. <ref>https://greatergood.berkeley.edu/article/item/how_stories_change_brain</ref> There is a neurological reaction to trusting someone. When we are intentionally trusted, even by a stranger, the brain produces oxytocin<ref>https://www.livescience.com/35219-11-effects-of-oxytocin.html</ref>. The enhanced empathy enabled by oxytocin allows humans to quickly form teams and work together effectively.
== Rationale ==
There are several models and research articles that we have found helpful in understanding how leaders can help foster a high-trust environment. You can find links to these below.

* [[Trust and Purpose - Paul Zak]]

* [[The Anatomy of Trust - Brene Brown]]
* [[Performance vs Trust - Simon Sinek]]
* [[wikipedia:The_Five_Dysfunctions_of_a_Team|The 5 Dysfunctions of a Team - Patrick Lencioni]]
* [https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html Google - Project Aristotle]
* [[Building Trust in High-Performing Teams - Mila Hakanen and Aki Soudunsaari]]
* [https://www.jstor.org/stable/258792?seq=4 Mayer, R. C., & Davis, J. H. (1995). An Integrative Model of Organizational Trust].<br />

== Related Principles ==
* [[Create the environment for people to thrive]]
* [[Maximise engagement]]
* [[Catalyst for change]]
* [[Involve those affected by change]]
* [[Create a Learning Organisation]]
* [[Provide an impediment removal service]]
* [[Maximise team empowerment and localised decision making]]
* [[Self-managed teams]]
* [[Self-managed Team of Teams]]
* [[Maximise Team autonomy]]

== References ==
<references />

Foster a high trust environment

2024-01-30T11:35:08Z

Cbird: /* Rationale */

__NOTOC__
== Description ==
Trust is the foundation that enables teams to create great results for the organisation. Without trust, teams can't reach their potential. Trust is an essential element of Psychological Safety which was found by Google's Project Aristotle to be the number one factor differentiating the highest-performing teams.

Trust can be defined as “Choosing to make something important to you vulnerable to the actions of someone else.” <ref>https://www.uncrushed.org/content/2019/7/1/the-anatomy-of-trust-brene-brown</ref> Trust is built slowly over time, Brené Brown<ref>https://en.wikipedia.org/wiki/Bren%C3%A9_Brown</ref> uses a marble jar metaphor; “We can deposit marbles and build up our sense of trust or withdraw them and degrade that sense of trust through our interactions”.

Research has identified how establishing trust between people affects us. <ref>https://greatergood.berkeley.edu/article/item/how_stories_change_brain</ref> There is a neurological reaction to trusting someone. When we are intentionally trusted, even by a stranger, the brain produces oxytocin<ref>https://www.livescience.com/35219-11-effects-of-oxytocin.html</ref>. The enhanced empathy enabled by oxytocin allows humans to quickly form teams and work together effectively.
== Rationale ==
There are several models and research articles that we have found helpful in understanding how leaders can help foster a high-trust environment. You can find links to these below.

* [[Trust and Purpose - Paul Zak]]

* [[The Anatomy of Trust - Brene Brown]]
* [[Performance vs Trust - Simon Sinek]]
* [[The 5 Dysfunctions of a Team - Patrick Lencioni]]
* [https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html Google - Project Aristotle]
* [[Building Trust in High-Performing Teams - Mila Hakanen and Aki Soudunsaari]]
* [https://www.jstor.org/stable/258792?seq=4 Mayer, R. C., & Davis, J. H. (1995). An Integrative Model of Organizational Trust].<br />

== Related Principles ==
* [[Create the environment for people to thrive]]
* [[Maximise engagement]]
* [[Catalyst for change]]
* [[Involve those affected by change]]
* [[Create a Learning Organisation]]
* [[Provide an impediment removal service]]
* [[Maximise team empowerment and localised decision making]]
* [[Self-managed teams]]
* [[Self-managed Team of Teams]]
* [[Maximise Team autonomy]]

== References ==
<references />

Main Page

2024-01-30T11:27:17Z

Cbird:

__NOTOC__
= ELSE: Emergent Large-Scale Evolution =

[[File:ELSE V2.png|frameless|834x834px]]

== Introducing ELSE ==
''A continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance agility at scale''.
*[[What is ELSE?]]
*[[Why ELSE?]]
*[[Actionable Principles]]
*[[How to Apply ELSE]]
Beta! The content of the ELSE wiki is very much ''Emergent'' and in a state of ''Evolution.'' It is our hope that the guidance is helpful, however we value your feedback to help us continually iterate and evolve the content.

== ELSE Perspectives and Principles ==

{| class="wikitable"
|+
!
!'''<big>Perspective</big>'''
!'''<big>Principles</big>'''
|-
|<div class="extralargefont">General</div>
|
|<div class="imagelink_elseprinciple">[[General| ]]</div>
|-
|<div class="extralargefont">Leadership</div>
| <div class="imagelink_elseperspective">[[The Leadership Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Leadership| ]]</div>
|-
|<div class="extralargefont">Change</div>
|<div class="imagelink_elseperspective">[[The Change Perspective| ]]</div>
|
|-
|<div class="extralargefont">Defining Products</div>
| rowspan="2" |<div class="imagelink_elseperspective">[[The Product Perspective| ]]</div>
| <div class="imagelink_elseprinciple">[[Defining Products| ]]</div>
|-
|<div class="extralargefont">Product Ownership</div>
|<div class="imagelink_elseprinciple">[[Product Ownership| ]]</div>
|-
|<div class="extralargefont">Teams</div>
|<div class="imagelink_elseperspective">[[The Teams' Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Teams| ]]</div>
|-
|<div class="extralargefont">Craft</div>
|
|<div class="imagelink_elseprinciple">[[Craft| ]]</div>
|-
|<div class="extralargefont">Coaching</div>
|<div class="imagelink_elseperspective">[[The Coaching Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Coaching| ]]</div>
|}
{|
|
|
|-
|
|
|}

{|
|[[File:Icon principle.png|left|frameless]]
|At the core of ELSE are the Principles. They are giving the "true north", the direction we aim for. Here are the links to them, categorised based on the area they belong to.
|-
|[[File:Icon perspective.png|left|frameless]]
|But principles often work together, and the perspectives are intended to capture these relationships and provide a narrative to give coherence to the system of Principles.

|}

==Practices ==
During the modelling of ELSE, we developed also several ideas and workshop formats that are good practices when implementing agile at scale, yet, not driving principles. Therefore we created a growing collection of [[Practices]] that will grown over time.

==Worked Examples ==
Real-life examples will be illustrated here.

==Tools==
During our work we have devised some techniques and workshop formats that will be documented soonish...

==References==
Here is a comprehensive set of [[references]].

== Glossary ==
Here is [[glossary]] defining the most important terms and concepts.

==Authors==
The following people are currently involved actively in this initiative: [[Colin Bird]], [[Jan B. Olsen]], [[Pierluigi Pugliese]], [[Matt Roadnight]] and [[Simon Roberts]].

How to Apply ELSE

2024-01-30T11:06:09Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Given streamlining the value stream and achieving a more end-to-end product can open up greater opportunities for improvement, it makes sense to start improvement iterations from this perspective.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves and makes new improvement opportunities possible, [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that help reshape the organisational environment.

 

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, leaders lead by example and take themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing on their individual silos.

How to Apply ELSE

2024-01-30T11:04:50Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Given streamlining the value stream and achieving a more end-to-end product can open up greater opportunities for improvement, it makes sense to start improvement iterations from this perspective.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves and makes new improvement opportunities possible, [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that help reshape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, leaders lead by example and take themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing on their individual silos.

How to Apply ELSE

2024-01-30T11:04:18Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Given streamlining the value stream and achieving a more end-to-end product can open up greater opportunities for improvement, it makes sense to start improvement iterations from this perspective.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves and makes new improvement opportunities possible, [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that help reshape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, leaders lead by example and take themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing on their individual silos.

How to Apply ELSE

2024-01-30T11:04:02Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Given streamlining the value stream and achieving a more end-to-end product can open up greater opportunities for improvement, it makes sense to start improvement iterations from this perspective.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves and makes new improvement opportunities possible, [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that help reshape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, leaders lead by example and take themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing on their individual silos.

How to Apply ELSE

2024-01-30T11:03:08Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Given streamlining the value stream and achieving a more end-to-end product can open up greater opportunities for improvement, it makes sense to start improvement iterations from this perspective.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves and makes new improvement opportunities possible, [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that help reshape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, leaders lead by example and take themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing on their individual silos.

How to Apply ELSE

2024-01-30T11:02:38Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Given streamlining the value stream and achieving a more end-to-end product can open up greater opportunities for improvement, it makes sense to start improvement iterations from this perspective.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves and makes new improvement opportunities possible, [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that help reshape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, leaders lead by example and take themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing on their individual silos.

How to Apply ELSE

2024-01-30T10:43:34Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Given streamlining the value stream and achieving a more end-to-end product can open up greater opportunities for improvement, it makes sense to start improvement iterations from this perspective.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves and makes new improvement opportunities possible, [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that help reshape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, they need to go themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing their individual work on silos.

How to Apply ELSE

2024-01-30T10:34:22Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Streamlining the value stream and achieving a more end-to-end product often opens up greater opportunities for improvement to product ownership, teams and leadership, thus enabling a more effective whole organisation.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves, so it open more opportunities to evolve Team structures, Product Ownership and the overall System of Work, including how Leadership operates. [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that shape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, they need to go themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing their individual work on silos.

How to Apply ELSE

2024-01-30T10:33:52Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. A common characteristic of many companies is to have a high level of [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change.

We noticed that often the improvement work on Teams, Product Ownership and Leadership to create a more agile ecosystem is severely constrained within the limits of how the value stream is structured.

Streamlining the value stream and achieving a more end-to-end product often opens up greater opportunities for improvement to product ownership, teams and leadership, thus enabling a more effective whole organisation.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the background knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves, so it open more opportunities to evolve Team structures, Product Ownership and the overall System of Work, including how Leadership operates. [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that shape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, they need to go themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing their individual work on silos.

How to Apply ELSE

2024-01-29T16:27:28Z

Cbird:

ELSE proposes that change is an emergent and evolutionary approach. As such, at the core, it's about designing experiments that drive the change in a useful direction. But... what is this direction? Agility is about value delivery and the capability of "turning on a dime for a dime"<ref>http://www.gurteen.com/gurteen/gurteen.nsf/id/to-turn-on-a-dime-for-a-dime</ref>, i.e. optimising for adaptability in product development. One characteristic of many companies is to have huge [[Accidental Complexity]] in the way they have organised their product development. As such, how products and value streams are set up is a key element to inform change. We noticed that often the work on Teams, Product Ownership and Leadership to create an agile ecosystem is severely limited by how the value stream is structured.

Streamlining the value stream usually involves changing organisational structures, thus enabling a more effective work on the whole organisation.

To understand the best way to do it, [[The Product Perspective]] and the [[Defining Products|Defining Products Principles]] provide the basic knowledge to inform your experiments.

[[File:ELSE - Align to end-to-end Products.png|frameless|800x800px]]

As the definition of Product evolves, so it open more opportunities to evolve Team structures, Product Ownership and the overall System of Work, including how Leadership operates. [[The Teams' Perspective]] and [[The Coaching Perspective]] and all the Principles will help in the design of experiments that shape the organisational environment.

To help you in the implementation of these experiments, [[The Change Perspective]] describes how to create the needed emergent evolutionary culture in your organisation based on the ELSE actionable principles, which can be summarised as follows:

[[File:ELSE Change Journey.png|frameless|800x800px]]

The catalyst of this work is, of course, Leadership! In order to support this work, they need to go themselves through a change process that involves learning to work as an end-to-end leadership team, rather than focusing their individual work on silos.

Scale only when you need to

2024-01-29T15:14:30Z

Cbird: refactored text

__NOTOC__
== Description ==
Assume that you do not need to scale your system of work until you can validate that you really need to. If you need to scale, do it as little as possible. Before adding more teams, make sure that your first few teams are highly effective –– you might not even need to add additional teams.

== Rationale ==

The goal of scaling is to scale the value of the outcome rather than the size of the development system (teams, processes, governance, roles, etc.). Most organisations are already carrying a great deal of "[[Accidental Complexity]]" and adding more teams and processes only exacerbates the situation. Before scaling, first optimise the system you already have and then only scale if it proves necessary.

Here is an example from a telecommunications company’s failing consumer cloud product turned around by going back to basics and applying a rigorous and evolutionary approach to scaling:

* Initial situation. The product was developed by multiple silo-based teams, each responsible for a different layer of the technical architecture (back-end, iOS client, Android client, Windows client etc.). This resulted in a long time to market for new versions (1-2 releases a year) because of the large amount of coordination overhead needed to make even modest changes. There was low customer satisfaction, indicated by low user retention rate and typically 1-2 star ratings in the App stores. In addition, there was low team morale and poor performance and reliability of the product.
* What was changed? Starting with one team, the transition was made to feature teams. Each team had the skills necessary to develop across the full stack from front-end to back-end, focussed on a particular channel (iOS, Android, Windows etc.). A single product backlog was introduced across all teams. Each team was trained and coached for several sprints to support the rollout of excellent Scrum + key Scrum patterns + XP development practices. This gave the business unit the means to respond quickly to data on product quality and customer satisfaction and drive the product towards success.
* What happened? After 6 months, things had improved considerably: App store ratings improved from an average of 1-2 stars to 4-5 stars, there were more active users, team morale had improved and the product was awarded first place in a review of competitive consumer cloud products (including Dropbox).

== Related Principles ==

* [[Evolutionary over revolutionary change]]
* [[Start small and scale success]]
* [[Own your own approach]]
* [[Minimise unnecessary complexity]]
* [[Maximise team empowerment and localised decision making]]
* [[Architectural cohesion]]
* [[Minimum Viable Product Owners]]
* [[Limit Product Owner Mental Workload]]
* [[Limit Team Mental Workload]]

Evolutionary over revolutionary change

2024-01-29T15:00:32Z

Cbird: /* Description */

__NOTOC__
== Description ==
Large revolutionary change to organisational systems has a high risk of failure, therefore it is recommended to inact change in an evolutionary approach.

== Rationale ==
Organisations are complex adaptive systems by nature, and changing them is an unpredictable business, often resulting in unforeseen side effects. Revolutionary change, where a significant change is made in a transactional fashion, has a far higher risk of failure than multiple small incremental changes. Smaller changes are also more practical to corelate change and outcome, leading to clearer understanding of impact. An evolutionary approach to change introduction is recommended, with the following considerations:

* Ensure those impacted by a change are part of the change process as opposed to having the changes done to them.
* Understand and start from the current context of your organisation and system of work.
* Use the Scaling Principles as a "Lens" to assess and understand potential opportunities for improvement.
* Create change hypotheses for the high-priority opportunities.
* Introduce and support a small number of experiments that can be run and evaluated independently.
* Use volunteers in the experiments where possible.
* Apply learnings back into the experiments.
* Broaden adoption when proven and where applicable.

==Related Principles==
* [[Start small and scale success]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]
* [[Catalyst for change]]
* [[Involve those affected by change]]
* [[Create a Learning Organisation]]
* [[Own your own approach]]

How to Apply ELSE

2024-01-29T14:47:33Z

Cbird:

The Perspectives discuss the background thinking behind the Principles. The Change Perspective includes a detailed discussion of the process for applying the ELSE Scaling Principles. In summary, the list below outlines the major activities and suggested order:

# Engage people and create the safety to surface issues and try experiments
# Collaboratively map the current context
# Use the ELSE Scaling Principles to analyse the context for gaps
# Identify improvement options and prioritise
# Shape, run and support experiments
# Review, adapt and learn from the experiments
# Emerge practice
# Broaden and evolve
# Repeat

How to Apply ELSE

2024-01-29T14:14:18Z

Cbird: Created page with "The Perspectives discuss the background thinking behind the Principles. The Change Perspective includes a process for applying the ELSE Scaling Principles. In summary, the list below outlines the major activities and suggested order to apply the scaling priniciples to your specific scaling challenge. # Engage people and create the safety to surface issues and try experiments # Map the current context # Use the ELSE Scaling Prinicples to analyse the context for gaps # Id..."

The Perspectives discuss the background thinking behind the Principles. The Change Perspective includes a process for applying the ELSE Scaling Principles. In summary, the list below outlines the major activities and suggested order to apply the scaling priniciples to your specific scaling challenge.

# Engage people and create the safety to surface issues and try experiments
# Map the current context
# Use the ELSE Scaling Prinicples to analyse the context for gaps
# Identify improvement options and prioritise
# Shape, run and support experiments
# Review, adpt and learn from the experiments
# Emgerge practice
# Broaden and evolve
# Repeat

The Change Perspective

2024-01-29T13:56:06Z

Cbird: /* Map Context */

__NOTOC__
== Adapt or Die! ==
Like other organisms, organisations must continually reinvent themselves to survive and thrive. With the accelerating pace of change, the ability to rapidly evolve has become an existential necessity.

A fundamental leadership responsibility is to help organisations navigate [[wikipedia:OODA_loop|OODA loops]] (Observe, Orient, Decide, Act) to learn and adapt continually. Any scaling endeavour will require adaption from current structures, behaviours, systems, processes, policies, etc., to an organisation better equipped to thrive in its environment.

The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end. It will likely be too late if an organisation waits until an event makes the need for change evident.

So, organisations need to adapt, but in which direction? Simply copying “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations is unlikely to create a competitive advantage, and there is no guarantee that it will suit your unique organisational context and culture. Leadership takes responsibility for catalysing a direction and purpose for change that guides a process of emergent practice.

''"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change." Charles Darwin (1809 - 1882)''

==Challenges to Change==
Changing organisational systems is generally challenging, highly disruptive, risky and takes more time than expected. The larger the change and the greater the cultural shift required, the more this is true.

[[File:Challenges to Change.png|frameless|463x463px]]

The diagram above identifies some forces that inhibit change and suggests appropriate strategies to address the challenges - discussed below.

Many personal, group and systemic factors push back against proposed changes:

*Ingrained Habits - Habit creates inertia to change; by default, people will do things the way they always have.
*Fear of Change - Change is complex and uncertain, creating a fear of the learning challenge and potential negative impacts on those involved.
*Size and scope of Change - More dramatic changes and those impacting more people and systems will suffer increased resistance.
*Risk of Change - Some changes have a greater perceived or real risk of high-impact failure.
*Difficulty of Change - The proposed changes may require new or rare skills or immature organisational support capabilities that still need to be implemented.
*Lack of Motivation - The need for change has not been widely established and communicated, or there is insufficient belief and trust in proposed changes.

==Evolutionary Change ==
The “Change Journey” is at least as important as where you arrive. A transactional change from today’s state to a target state misses out on the journey experiences and learnings, which provide time to learn, adapt and acclimatise.

Organisations are complex adaptive systems by nature, and changing them is an unpredictable business, often resulting in unforeseen side effects. Agile approaches have emerged to deal with complex problems, so they are a natural choice to apply to the challenge of change. This section offers an evolutionary and incremental change model, with inspection and adaptation cycles at its heart.

Supporting Principles:

*[[Evolutionary over revolutionary change]]
*[[Catalyst for change]]
*[[Create a Learning Organisation]]

The diagram below outlines a cycle of evolutionary change guided by principles that are abstract enough to be widely applicable but concrete enough to implement. These principles are called [[Actionable Principles]].

[[File:ELSE Change Journey.png|frameless|767x767px]]

===Why!===
Given the challenges of change, there needs to be clear and agreed reasons to motivate people to risk modifying systems and ways of working. Clarity of purpose will also inform strategies and decisions on the direction and details of the evolving changes. For this reason, “Why!” is shown in the diagram, providing context for the entire change cycle.

At a high level, the need to continually evolve the organisation to stay relevant and viable will likely be a constant but abstract motivator. As we go deeper, more specific and concrete reasons for improvement to systems, processes, policy, etc. will need to be established. These purposes should be formed in collaboration with those involved and impacted by potential changes. See “Engage People” below.

Supporting principles:

*[[Create clarity of purpose]]
*[[Maximise engagement]]
[[File:Start Where You Are - ELSE.png|left|frameless|196x196px]]
When reviewing the root causes of change failures, it is common to find faulty assumptions and incomplete perspectives of how complex work gets done. It is easy to miss many informal networks and relationships and put too much trust in official documentation and organisational charts.

''We must start changing from where we are, with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.''

====Engage People====
Involve those affected by change in exploring the current systems and processes and identifying opportunities to improve them. This strategy will lead to better-informed change with buy-in and increased motivation from those who will enact the improved processes.

Many change programmes meet significant resistance from those impacted by the change. One of the reasons for this resistance is that the change is forced on them, and they need more understanding of the reasons driving the change. Establishing the “Why” through collaborative engagement with those impacted by change can shift their place in the change process from victims to supporters.

Process changes are often designed based on flawed assumptions about current processes. Involving those with intimate knowledge of systems and processes impacted by change leads to better-informed decision-making. This, in turn, increases trust and helps reduce resistance to change.

Supporting principles:

*[[Involve those affected by change]]
*[[Shared context improves decisions]]
*[[Maximise engagement]]
* [[Create clarity of purpose]]
*[[Catalyst for change]]

====Create Safety====
Amy Edmondson defines Psychological Safety as ”a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…”

It seems such a simple statement, but without Psychological Safety, nothing good happens: errors and issues remain hidden, and learning and improvement are stunted. With high levels of Psychological Safety, we open the door for greater engagement and innovation, improved work quality and collaboration, and support for learning and process improvement.

Establishing a safe environment is a priority for leadership to ensure that less bravery is required to identify and explore current challenges down to their root causes. A reduction in the fear of failure will enable experiments to safely explore innovative solutions and identify and apply learnings.

Supporting principles:

*[[Create the environment for people to thrive]]
*[[Foster a high trust environment]]
*[[Involve those affected by change]]
*[[Maximise engagement]]
*[[Create a Learning Organisation]]
*[[Evolutionary over revolutionary change]]

====Map Context ====
The aim of this step is to establish a shared understanding of the current context by engaging all relevant stakeholders and sources of data in a rapid, collaborative process. Avoid getting bogged down in over-analysis and ensure that all stakeholders appreciate that this is an emergent process.

Structured interactive workshops are an excellent approach to engage and incorporate diverse perspectives into a shared picture of the current context and surface the challenges to be addressed.

There are many workshop techniques and structures that can be used, Value Stream Mapping is an excellent example. Whilst deriving ELSE, we evolved an effective Context Mapping Workshop (this will be documented in the Practices section of the wiki), which is another option.

Here are some ideas for workshop options to support the mapping of the current context, digging down to root causes, and assessing the strengths and weaknesses of potential improvement options:

* Value Stream Mapping
*Impact Mapping
*Wardley Mapping
*Causal Loop Diagramming
*Fishbone Analysis
* 5 Whys
*Forcefield Analysis

====Analyse & Understand====
With a comprehensive map and understanding of the current context, inspect with common sense and the Scaling Principles as lenses. Identify where there are larger gaps between the principles and reality, pointing to opportunities for improvement.

The mapping exercise often reveals challenges that are not immediately apparent, due to the collective diverse perspectives of stakeholders. Others require the application of the principles to be revealed as their impacts may be harder to spot or pin down the causes.

Use the Scaling Principles to inspect the map(s) and explore how the current context supports each principle. A useful workshop technique is to divide stakeholders into small groups, each applying a subset of the principles for a time-boxed period before rotating to another subset.

The outcome should be a prioritised list of challenges where there are larger deviations from the principles. When prioritising, it is worth considering addressing challenges considering the emphasis shown in the diagram below:

[[File:Improvement Order - ELSE.png|frameless|760x760px]]

We see many instances where team structure and communication patterns are optimised within a poor product structure and product ownership that reduces their alignment with value creation. So whilst tactical improvements can be accomplished at a team level, greater progress may require starting with improvements to the structure of products and services before addressing product ownership and teams.

[[File:Small Experiments - ELSE.png|left|frameless|201x201px]]
Limiting the scope and framing changes as experiments rather than finalised change decisions reduce fear and risk. Work to reduce the scope of changes so that they impact only a small part of the system’s processes and a manageable subset of people.

Start small with the primary objective of maximising learning - validating or invalidating assumptions and risks and gaining empirical data that enables better planning and decision-making for the next steps.

Supporting Principles:

*[[Scale only when you need to]]
* [[Start small and scale success]]
*[[Foster a high trust environment]]

====Identify Options====
Building on the context mapping and analysis, engage stakeholders to generate multiple diverse options for improvement experiments.

Don’t assume the need to scale! Consider that you might not need to scale at all: a highly productive team working in a supportive environment might be everything you need to create great products. Scaling always adds complexity and process wastes, so prioritise options that improve at the current scale before resorting to scaling.

Consider “De-scaling”. If improving an already scaled system, then explore options that enable the scaling level and complexity to be reduced. A surprising amount of performance improvement can often be unlocked by reducing complexity and overhead.

Options can be assessed and prioritised by many factors, including their envisaged relative:

*Positive impact
*Financial cost
*Effort
*Availability of required skills or capability
*Risk and blast radius
*Resistance
*Elapsed time to feedback and learning

Generate a shortlist of the most promising options to take forward and shape as experiments.

Supporting Principles:

*[[Involve those affected by change]]
*[[Scale only when you need to]]
*[[Start small and scale success]]
*[[Minimise unnecessary complexity]]
*[[Are lean practitioners]]

====Shape Experiments====
Intentionally frame potential changes as “Experiments” to ensure that we admit that we don’t know everything and the outcome is not certain, with “Failure” a likely option. Make it “Safe to Fail” by reframing “Failure” as an unexpected outcome of the experiment that provides an opportunity to learn. The learning can then be incorporated into improved or illuminate better alternative change options. This strategy reduces the traditional stigma of failure that creates a fear of innovating and changing the way things have always been done.

Collaboratively develop a hypothesis for an experiment to address an option for improvement. A change experiment hypothesis may include the following elements:

*The “Why” - context of the challenge to the Scaling principles.
*The outcome we hope to see.
*Experiment plan outline
*When - how long we expect to run the experiment and observe results.
*Who - people involved and impacted.
*What changes - structure, systems, processes, policies, skills, roles, etc.
*Validation - how we will assess outcome progress and success.
*Key assumptions, challenges and risks.
*Support required.

Shape small experiments, or as Jason Little refers to them: MVCs - [https://blog.leanchange.org/2016/07/minimum-viable-change-process/ Minimum Viable Changes]. When considering what changes - keep impact and effort low by making local and/or temporary changes or exceptions to normal working practices for the experiment timebox. If the experiment validates changing more officially and widely, then see Scale Success, below.

<u>Prompts and Triggers</u>

Even with great motivation to change, there is the inertia of ingrained habits to overcome. To help tackle this challenge to change, we need to provide some scaffolding to support new behaviours. An effective pattern is to either modify or insert prompts into existing processes and systems to trigger new behaviours. For example, a change might be as simple as adding a new column to a Kanban board or inserting a question into a planning meeting agenda.

In addition, address any shortcomings in the skills and capabilities of people and systems in order to reduce the challenge of the new behaviours. If a change is too difficult, people will be far less likely to follow through.

<u>Parallel Experiments to Speed Learning</u>

Running parallel experiments can enable more learning in a given period of time. However, there are some caveats:

*The experiments must be able to run independently without impacting each other and this might be difficult to predict. It must be possible to attribute observed outcomes to a specific experiment and avoid the possibility of one cancelling the benefits of another.
*Ensure that the additional WIP due to initiating, supporting and learning from the experiments does not negatively impact the outcomes of the process. Taking on too many parallel changes can overload the capacity to support the experiments and may lead to incorrect invalidation of good ideas that lack sufficient support.

Supporting Principles:

*[[Involve those affected by change]]
*[[Foster a high trust environment]]
*[[Provide an impediment removal service]]
*[[Catalyst for change]]
*[[Create clarity of purpose]]

====Support Experiments====
Seek volunteers to run and support experiments to reduce resistance and provide the motivation to give the idea a fair trial.

Those in a leadership or influential positions can support experiments in the following ways:

*Retain and remind all involved as to the purpose to keep aligned on the “Why”.
*Provide air cover to enable bending or breaking of normal rules within the context of the experiment.
*Help understand and mitigate or resolve impediments.
*Support a “Safe to Fail” culture by ensuring that responses to unexpected outcomes of experiments are constructive and lead to learning and adaptation.

When it comes to cultivating a Safe to Fail culture, asking questions like "What can we learn from this outcome?" helps foster open and honest discussions that are free from blame. In contrast, questions like "Who thought this was a good idea?" can be thoroughly counterproductive. Unexpected outcomes often present the greatest opportunities for learning, as they can help us uncover faulty assumptions and gain new insights.

It is vital that the outcomes, whether intended or unintended, are investigated down to root causes to ensure depth learning.

Supporting Principles:

*[[Foster a high trust environment]]
*[[Provide an impediment removal service]]
*[[Catalyst for change]]
*[[Create clarity of purpose]]

====Emerge Practices====
Whilst practices and patterns harvested from external sources such as scale frameworks are useful input, they should be adapted to fit the specific context. Practices are then “Emerged” through a process of evaluating, learning and further adaptions based on the outcomes of small experiments.

True innovative change often emerges from the serendipitous and accidental discovery of practices and patterns that provide both intended and unintended benefits and improvements. Of course, the reverse can also occur, with unintended and unforeseen negative side-effects resulting from an experiment.

Intentionally and regularly assess the results of experiments to understand the desirable and undesirable consequences arising. Analyse whether the consequences point to alternative purposes that were not originally envisaged i.e. intentionally repurpose existing and emergent capabilities for reasons that are different to the original intent. Dave Snowden refers to this process as [https://thecynefin.co/exaptation-managed-serendipity-part-i/ Exaptation].

Actively look for and experiment with removing practices whose purpose appears to have become redundant but have been retained through force of habit.

<u>Culture Impact</u>

Be aware of the cultural impact of experiments. It is important to understand the difference and relationship between making changes to the environment versus the behaviour changes caused by the environment.

“Environmental factors, which often seem benign or inconsequential, play powerful roles in shaping our behaviors.” - The Good Samaritan Study ([https://psycnet.apa.org/record/1973-31215-001 "From Jerusalem to Jericho"]). As changes are made to the working environment and its associated systems and processes, they will impact how people behave and think. This is clearly an essential element of the feedback loop into the process of emerging practice and cultural change.

[[File:Scale Success - ELSE.png|left|frameless|200x200px]]
Don’t assume the need to scale!

It may be that we have now validated assumptions, derisked some key risks and provided the basis for understanding how we need to scale up and expand the teams. Alternatively, we are making excellent progress, so scaling is not required. Or, perhaps the “Start Small” approach has quickly and cheaply “Failed”, and the business can now make a better decision and pivot to an alternative strategy. The larger the scale, the more expensive and difficult it is to make the hard call to abandon a bad idea!

Supporting Principles:

*[[Start small and scale success]]
*[[Scale only when you need to]]

====Broaden and Evolve====
Once experiments have reached a level of maturity where there is good evidence that the changes are positive and practical, then incrementally broaden through engagement with a wider scope and audience.

Scaling success should be done in an incremental and evolutionary style rather than a big-bang rollout! This process should still be “Experimental”, looking to learn and evolve, being considered “Emergent Practice” and definitely not “Best Practice”. Understanding the context of the successful experiment is vital when considering its broader application or incorporation into formal practices.

Seeking volunteers is always preferred over mandating and pushing changes onto unwilling victims! The guidance on engaging those impacted by changes still holds when broadening and evolving practice. Engaging volunteers from the initial experiments to act as supporting coaches for new groups can reduce cognitive load and speed up the evolution of improvements.

Supporting Principles:

*[[Start small and scale success]]
*[[Scale only when you need to]]
*[[Evolutionary over revolutionary change]]
*[[Involve those affected by change]]

====Repeat!====
Improvement is a continuous endeavour and should definitely not be considered a transactional process.

The impact of improvements will change the context, and given the complex adaptive nature of human systems, the outcomes may not be entirely as expected. It is, therefore, essential that we start by re-engaging our people to re-assess the context before embarking on further changes.

==Change Perspective Summary==

*The ability to continually change must become part of an organisation's DNA rather than being treated as a transaction with a beginning and end.
*Don’t Copy & Paste “Best Practice”
*Organisational change is complex and requires an iterative and incremental evolutionary approach.
*Establish a clarity of purpose at all levels and engage those impacting and impacted by the changes.
*A Psychologically Safe environment will enable challenges, weaknesses, waste and errors to be surfaced and addressed.
*Start from where we are with an honest and critical analysis of the current system of work with a mindset to discover, drill down and address root causes of challenges to value creation.
*Use collective workshops where stakeholders with diverse perspectives map the current context and then analyse and understand it through the lens of Scaling Principles.
*Support workshops with appropriate collaborative mapping techniques.
*Identify and prioritise options for experiments.
*“De-scale” - always consider options for reducing the complexity of the current context!
*Reduce the risk, fear and resistance to change by using small safe-to-fail experiments.
*Shape, support, and incorporate learning from experiments into emergent practices.
*Scaling success should be an evolutionary process.

==References==
https://en.wikipedia.org/wiki/Complex_adaptive_system

https://en.wikipedia.org/wiki/OODA_loop

[https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-based Concurrent Concurrent Engineering]

Minimum Viable Changes (MVCs) - Little, Jason. Lean Change Management: Innovative practices for managing organizational change (p. 36).

Darley, J. M., & Batson, C. D. (1973). [https://psycnet.apa.org/record/1973-31215-001 "From Jerusalem to Jericho": A study of situational and dispositional variables in helping behavior.]

Journal of Personality and Social Psychology, 27(1), 100.

Main Page

2024-01-29T13:41:47Z

Cbird: /* Introducing ELSE */

__NOTOC__
= ELSE: Emergent Large-Scale Evolution =

[[File:ELSE V2.png|frameless|834x834px]]

== Introducing ELSE ==
''A continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance agility at scale''.
*[[What is ELSE?]]
*[[Why ELSE?]]
*[[Actionable Principles]]
*[[How to Apply ELSE]]

== ELSE Perspectives and Principles ==

{| class="wikitable"
|+
!
!'''<big>Perspective</big>'''
!'''<big>Principles</big>'''
|-
|'''<big>General</big>'''
|
|<div class="imagelink_elseprinciple">[[General| ]]</div>
|-
|'''<big>Leadership</big>'''
| <div class="imagelink_elseperspective">[[The Leadership Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Leadership| ]]</div>
|-
|'''<big>Change</big>'''
|<div class="imagelink_elseperspective">[[The Change Perspective| ]]</div>
|
|-
|'''<big>Defining Products</big>'''
| rowspan="2" |<div class="imagelink_elseperspective">[[The Product Perspective| ]]</div>
| <div class="imagelink_elseprinciple">[[Defining Products| ]]</div>
|-
|'''<big>Product Ownership</big>'''
|<div class="imagelink_elseprinciple">[[Product Ownership| ]]</div>
|-
|'''<big>Teams</big>'''
|<div class="imagelink_elseperspective">[[The Teams' Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Teams| ]]</div>
|-
|'''<big>Craft</big>'''
|
|<div class="imagelink_elseprinciple">[[Craft| ]]</div>
|-
|'''<big>Coaching</big>'''
|<div class="imagelink_elseperspective">[[The Coaching Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Coaching| ]]</div>
|}
{|
|
|
|-
|
|
|}

{|
|[[File:Icon principle.png|left|frameless]]
|At the core of ELSE are the Principles. They are giving the "true north", the direction we aim for. Here are the links to them, categorised based on the area they belong to.
|-
|[[File:Icon perspective.png|left|frameless]]
|But principles often work together, and the perspectives are intended to capture these relationships and provide a narrative to give coherence to the system of Principles.

|}

==Practices ==
During the modelling of ELSE, we developed also several ideas and workshop formats that are good practices when implementing agile at scale, yet, not driving principles. Therefore we created a growing collection of [[Practices]] that will grown over time.

==Worked Examples ==
Real-life examples will be illustrated here.

==Tools==
During our work we have devised some techniques and workshop formats that will be documented soonish...

==References==
Here is a comprehensive set of [[references]].

== Glossary ==
Here is [[glossary]] defining the most important terms and concepts.

==Authors==
The following people are currently involved actively in this initiative: [[Colin Bird]], [[Jan B. Olsen]], [[Pierluigi Pugliese]], [[Matt Roadnight]] and [[Simon Roberts]].

Main Page

2024-01-29T13:41:14Z

Cbird: /* ELSE Perspectives and Principles */

__NOTOC__
= ELSE: Emergent Large-Scale Evolution =

[[File:ELSE V2.png|frameless|834x834px]]

== Introducing ELSE ==
''A continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance agility at scale''.
*[[What is ELSE?]]
*[[Why ELSE?]]
*[[Actionable Principles]]
*How to Apply ELSE

== ELSE Perspectives and Principles ==

{| class="wikitable"
|+
!
!'''<big>Perspective</big>'''
!'''<big>Principles</big>'''
|-
|'''<big>General</big>'''
|
|<div class="imagelink_elseprinciple">[[General| ]]</div>
|-
|'''<big>Leadership</big>'''
| <div class="imagelink_elseperspective">[[The Leadership Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Leadership| ]]</div>
|-
|'''<big>Change</big>'''
|<div class="imagelink_elseperspective">[[The Change Perspective| ]]</div>
|
|-
|'''<big>Defining Products</big>'''
| rowspan="2" |<div class="imagelink_elseperspective">[[The Product Perspective| ]]</div>
| <div class="imagelink_elseprinciple">[[Defining Products| ]]</div>
|-
|'''<big>Product Ownership</big>'''
|<div class="imagelink_elseprinciple">[[Product Ownership| ]]</div>
|-
|'''<big>Teams</big>'''
|<div class="imagelink_elseperspective">[[The Teams' Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Teams| ]]</div>
|-
|'''<big>Craft</big>'''
|
|<div class="imagelink_elseprinciple">[[Craft| ]]</div>
|-
|'''<big>Coaching</big>'''
|<div class="imagelink_elseperspective">[[The Coaching Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Coaching| ]]</div>
|}
{|
|
|
|-
|
|
|}

{|
|[[File:Icon principle.png|left|frameless]]
|At the core of ELSE are the Principles. They are giving the "true north", the direction we aim for. Here are the links to them, categorised based on the area they belong to.
|-
|[[File:Icon perspective.png|left|frameless]]
|But principles often work together, and the perspectives are intended to capture these relationships and provide a narrative to give coherence to the system of Principles.

|}

==Practices ==
During the modelling of ELSE, we developed also several ideas and workshop formats that are good practices when implementing agile at scale, yet, not driving principles. Therefore we created a growing collection of [[Practices]] that will grown over time.

==Worked Examples ==
Real-life examples will be illustrated here.

==Tools==
During our work we have devised some techniques and workshop formats that will be documented soonish...

==References==
Here is a comprehensive set of [[references]].

== Glossary ==
Here is [[glossary]] defining the most important terms and concepts.

==Authors==
The following people are currently involved actively in this initiative: [[Colin Bird]], [[Jan B. Olsen]], [[Pierluigi Pugliese]], [[Matt Roadnight]] and [[Simon Roberts]].

Main Page

2024-01-29T13:39:38Z

Cbird: /* Introducing ELSE */

__NOTOC__
= ELSE: Emergent Large-Scale Evolution =

[[File:ELSE V2.png|frameless|834x834px]]

== Introducing ELSE ==
''A continuous improvement approach that fosters emergent practices, guided by actionable principles, to enhance agility at scale''.
*[[What is ELSE?]]
*[[Why ELSE?]]
*[[Actionable Principles]]
*How to Apply ESLE

== ELSE Perspectives and Principles ==

{| class="wikitable"
|+
!
!'''<big>Perspective</big>'''
!'''<big>Principles</big>'''
|-
|'''<big>General</big>'''
|
|<div class="imagelink_elseprinciple">[[General| ]]</div>
|-
|'''<big>Leadership</big>'''
| <div class="imagelink_elseperspective">[[The Leadership Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Leadership| ]]</div>
|-
|'''<big>Change</big>'''
|<div class="imagelink_elseperspective">[[The Change Perspective| ]]</div>
|
|-
|'''<big>Defining Products</big>'''
| rowspan="2" |<div class="imagelink_elseperspective">[[The Product Perspective| ]]</div>
| <div class="imagelink_elseprinciple">[[Defining Products| ]]</div>
|-
|'''<big>Product Ownership</big>'''
|<div class="imagelink_elseprinciple">[[Product Ownership| ]]</div>
|-
|'''<big>Teams</big>'''
|<div class="imagelink_elseperspective">[[The Teams' Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Teams| ]]</div>
|-
|'''<big>Craft</big>'''
|
|<div class="imagelink_elseprinciple">[[Craft| ]]</div>
|-
|'''<big>Coaching</big>'''
|<div class="imagelink_elseperspective">[[The Coaching Perspective| ]]</div>
|<div class="imagelink_elseprinciple">[[Coaching| ]]</div>
|}
{|
|
|
|-
|
|
|}
[[File:Icon principle.png|left|frameless]]

At the core of ELSE are the Principles. They are giving the "true north", the direction we aim for. Here are the links to them, categorised based on the area they belong to.
[[File:Icon perspective.png|left|frameless]]

But principles often work together, and the perspectives are intended to capture these relationships and provide a narrative to give coherence to the system of Principles.

==Practices ==
During the modelling of ELSE, we developed also several ideas and workshop formats that are good practices when implementing agile at scale, yet, not driving principles. Therefore we created a growing collection of [[Practices]] that will grown over time.

==Worked Examples ==
Real-life examples will be illustrated here.

==Tools==
During our work we have devised some techniques and workshop formats that will be documented soonish...

==References==
Here is a comprehensive set of [[references]].

== Glossary ==
Here is [[glossary]] defining the most important terms and concepts.

==Authors==
The following people are currently involved actively in this initiative: [[Colin Bird]], [[Jan B. Olsen]], [[Pierluigi Pugliese]], [[Matt Roadnight]] and [[Simon Roberts]].