go-ELSE - User contributions [en-gb]

The Change Perspective

2025-02-12T18:26:00Z

Ppugliese: /* Act */

__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:25:24Z

Ppugliese: /* Orient */

__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:23:31Z

Ppugliese: /* Observe */

__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/''

Accidental Complexity

2025-01-23T12:47:43Z

Ppugliese: Improved the description

Is defined as complexity added by our approach and process as opposed to the inherent complexity of solving a given problem. (Brooks)

This term was introduced by [[wikipedia:Fred_Brooks|Fred Brooks]] in "[[wikipedia:No_Silver_Bullet|No Silver Bullet—Essence and Accident in Software Engineering]]" and, though he described it in term of creation of software, we find it is relevant in many aspects of product development and of organisational structures.

Brooks claims that complexity can be divided in two parts:

* Essential Complexity, i.e. the natural complexity of the problem and
* Accidental Complexity, i.e. the complexity that exists on top of the Essential Complexity because of the way we work.

In general, in most organisations, Accidental Complexity determines what we can achieve with our effort, and this is why, given the same problem to solve, some companies manage to be more successful than others.

The Teams' Perspective

2024-05-21T21:18:18Z

Ppugliese:

__NOTOC__
== Introduction ==
“In the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” – Charles Darwin

The evolutionary pressure in the world has never been more volatile and uncertain. Surviving and thriving requires organisations to respond rapidly, adapt and navigate complex challenges.

An Agile organisation addresses these challenges by nurturing and supporting Agile teams with a high degree of autonomy, that can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services.

This section revisits the essential elements of successful Agile teams and then explores how we can scale this model to a larger product development organisation whilst retaining the advantages. The key related Scaling Principles are called out in the relevant places.

'''Sections in this Perspective:'''

* Agile Teams
*# Defining “Highly Effective”
*# Why Agile Teams Are Effective
*# Elements of a Highly Effective Agile Team
* Options for Scaling Agile Teams
*# Assumptions on the Need for Scale
*# Optimise a Single Team
*# Grow the Single Team
*# Component Teams
*# Feature Teams
* Effective Autonomy with Boundaries
* Maximise Team Learning

==Agile Teams==
===Defining "Highly Effective"===
How do we recognise that a team is highly effective, what are the visible signs and capabilities?

Here are some examples of what we might be looking for:

* Consistently realise high-value, high-quality outcomes with short lead-time and low waste
* Creative and innovative solutions to diverse, complex problems
* Learn fast and are continually improving
* Adaptable and Resilient
* Collaborative, supportive and inclusive culture

=== Why Agile Teams Are Effective ===
Agile teams are effective because they are small units of people committed and focused on getting the “job done”, autonomously delivering end-to-end products to customers.

In this context, “end-to-end” means having control over everything related to the execution of product development, from the analysis and design activities through all the technological development and testing to ensure the released product is successful.

With a high degree of autonomy, they can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services. Waste, caused by hand-offs, dependencies and coordination, is dramatically reduced as it is internalised within the boundary of the team’s collaboration.

According to Richard Hackman, the “recipe” to create great teams is the following:

# A real team
# Compelling direction
# Enabling team structure
# Supportive organisational context
# Expert team coaching

Most Agile approaches implement this model, though in slightly different ways. For example, Scrum has a Product Owner providing compelling direction and a Scrum Master providing coaching and working to achieve a supportive organisational context:

[[File:Team Image 2.png|frameless|468x468px]]

In summary, highly effective Agile teams are motivated, small, empowered and can function with significant autonomy and clarity of purpose.

''Related Principles:''

* [[Self-managed teams]]
* [[Maximise team empowerment and localised decision making]]
* [[Maximise Team autonomy]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]

''Relevant References:''

Hackman, J. R. (2002). Leading teams: Setting the stage for great performances. Harvard Business School Press.

=== Elements of a Highly Effective Agile Team ===
In this section, we dig a little deeper into the elements that go into an effective Agile team. The diagram below illustrates some of the elements incorporated within a Scrum manifestation of the Agile principles.

[[File:Effective Agile Teams.png|frameless|900x900px]]

We explore these elements required for a highly effective Agile team:

* Small Team Size
* Autonomous and Empowered
* Clarity of Purpose
* Team Membership
* Cross-functional
* Supportive Organisational Context
* Team Coaching
* Psychological Safety

==== Small Team Size ====
Research on Team size consistently finds that for complex knowledge work with high interdependency of tasks, smaller teams, 10 or less, are more effective than larger teams.

Scrum, for example, in the [https://scrumguides.org/scrum-guide.html 2020 Scrum Guide] says,” The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive.”

Larger teams experience dramatically increased communication complexity, increased effort and time to deliver a given outcome and lower motivation and morale.

''Relevant Principles'':
*[[Scale only when you need to]]
*[[Start small and scale success]]
*[[Organise around value streams]]
*[[Minimise unnecessary complexity]]

* [[Limit Team Mental Workload]]

''Relevant references:''

* [[wikipedia:Ringelmann_effect|The Ringelmann Effect]]
* [http://psycnet.apa.org/psycarticles/2011-21070-001 Team Size and Quality of Group Experience]
* [[wikipedia:Brooks's_law|Brooks's Law]]
* [[wikipedia:Metcalfe's_law|Metcalfe’s Law]]
* [https://rework.withgoogle.com/blog/many-hands-may-not-make-light-work/ Google re:Work]
* [https://store.hbr.org/product/the-wisdom-of-teams-creating-the-high-performance-organization/15042 Katzenbach, J. R., & Smith, D. K. (2015). The wisdom of teams: Creating the high-performance organization. Harvard Business Review Press]
* [https://www.qsm.com/articles/familiar-metric-management-small-beautiful-once-again Familiar Metric Management - Small is Beautiful-Once Again, Lawrence H. Putnam and Ware Myers]

==== Autonomous and Empowered ====
An Agile team should be able to operate with a high degree of autonomy, taking a requirement or idea from concept to realisation with a minimum of outside dependencies. In addition, they will be empowered to decide how to solve the problem without the need to seek permission from outside authorities.

The team need to be free to decide how to meet the outcome described by clear goals and Product Backlog items and their Acceptance Criteria (or equivalent) - see Clarity of Purpose. However, there should be clearly understood boundaries to the team’s autonomy and empowerment. These boundary constraints can be applied via the Definition of Done (DoD) and other agreements that cover standards and compliance aspects. These agreements should be collaboratively formed with the team and other relevant stakeholders and should be viewed as living, evolving artefacts that the team can challenge.

In addition to the efficiency gains due to the speed of decision-making and reduced waste caused by delays waiting for dependencies to be resolved, teams experience increased motivation and accountability for their work.

The quality of decisions also improves due to the proximity of the decisions to the work and information, along with the skills of the people deciding.

''Relevant Principles'':
* [[Support autonomy with clear boundaries]]
* [[Leadership supports rather than drives the work]]
* [[Product solution design is driven from within development teams]]
* [[Maximise engagement]]
* [[Maximise Team autonomy]]
* [[Create clarity of purpose]]
* [[Leadership supports rather than drives the work]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Self-managed teams]]
* [[Self-managed Team of Teams]]

''Relevant References:''

[https://selfdeterminationtheory.org/theory/ A relevant excerpt from Self-Determination Theory]: “Conditions supporting the individual’s experience of autonomy, competence, and relatedness are argued to foster the most volitional and high-quality forms of motivation and engagement for activities, including enhanced performance, persistence, and creativity.”

==== Clarity of Purpose ====
In the words of Stephen Bungay, “The more alignment you have around direction, the more autonomy you can get around actions” - [https://www.stephenbungay.com/Books.ink The Art of Action by Stephen Bungay] Bungay, S. (2021).

A clear, compelling and common purpose guides and enables the team to shape their autonomous and empowered work. The fact that the team share a purpose is an important element to support and motivate a collaborative team dynamic rather than just a group of individual efforts.

Creating and maintaining the purpose of a team is an important contact point between the team and outside stakeholders. This process needs to work in such a way that it provides clear alignment and rich contextual information, whilst simultaneously protecting the autonomy and empowerment of the team. In Scrum, the Product Owner is responsible for engaging stakeholders to input into goals and requirements and feedback on team outputs, whilst retaining decision-making authority within the team.

The “Semi-permeable” boundary around a team indicates the protection the team should have from disruption and interference in their mission to achieve the agreed goals. It should, however, not exclude the team from interacting directly with sources of information external to the team.

''Relevant Principles'':
*[[Create clarity of purpose]]

*[[Shared context improves decisions]]

*[[Organise around value streams]]

*[[Maximise engagement]]

*[[Maximise Team autonomy]]
*[[Maximise team empowerment and localised decision making]]
*[[Favour Teams with broader Business Domain Competence]]
*[[Self-managed teams]]
*[[Self-managed Team of Teams]]

==== Team Membership ====
Largely stable membership enables team formation to take place, evolving from a group of individuals to a collaborating, mutually supportive team unit. A revolving set of players creates an uncertain and unstable environment for relationships and trust to build and is unlikely to lead to a strong team identity.

Team members should complement each other. Covering each other's weaknesses and providing a constructive diversity of perspectives and experiences. In addition, the team should be resilient and retain the ability to deliver outcomes even when missing individual team members through vacations and illness.

''Relevant References:''

“Teams with stable membership perform better than those that constantly have to deal with the arrival of new members and the departure of old ones.” - [https://scholar.harvard.edu/rhackman/pages/leading-teams Leading Teams by J. Richard Hackman].

''Relevant Principles'':

* [[Favour teams with maximised cognitive diversity]]
*[[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
*[[Maximise engagement]]

*[[Maximise Team autonomy]]

==== Cross-functional ====
Teams are cross-functional – they have all the business and delivery domain skills required to autonomously turn backlog items from ideas to outcomes. In other words, the team is not dependent on external capability to deliver items from their backlog. In this context, “outcomes” refers to realised value to the organisation and/or customers.

''Relevant Principles'':
* [[Favour teams with maximised cognitive diversity]]
* [[Favour Teams with broader Solution Accountability]]
* [[Limit Team Mental Workload]]
* [[Maximise Team autonomy]]
* [[Cultivate learning between teams]]
* [[Product solution design is driven from within development teams]]
* [[Create a Learning Organisation]]

==== Supportive Organisational Context ====
Leaders are considered to be “Stakeholders” when it comes to influencing what the team focus on. They don’t directly tell the team what to work on or how to accomplish their work. However, they have an essential role in supporting the evolution of the environment around the team to ensure that the team can maximise their value creation for customers and stakeholders. Where the team are hindered by issues such as unnecessary or overly heavy bureaucracy, leadership should work to understand and evolve the organisational systems and structures.

''Relevant Principles'':
* [[Leadership supports rather than drives the work]]
* [[Create clarity of purpose]]
* [[Limit Team Mental Workload]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]
* [[Maximise Team autonomy]]
* [[Create a Learning Organisation]]
* [[Cultivate learning between teams]]
* [[Involve those affected by change]]
* [[Provide an impediment removal service]]

==== Team Coaching ====
Assembling all the correct ingredients is a good start, but on its own is unlikely to result in a successful team. A coach (e.g. a Scrum Master) helps the individual players learn how to work together as a collaborating team, accelerating the learning from group experience to continuously improve their collective processes, capabilities and interactions.

''Relevant Principles'':
* [[Leadership supports rather than drives the work]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise Team autonomy]]
* [[Cultivate learning between teams]]
* [[Create a Learning Organisation]]

==== Psychological Safety ====
Amy Edmondson defines [https://amycedmondson.com/psychological-safety/ Psychological Safety] as ”a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…”

A simple definition of a fundamental element that is required for a team to learn from its mistakes, innovate products, services and processes, take accountability, and collaborate and support each other.

Leadership within and external to the team has a major role in creating and maintaining the environment to promote high levels of psychological safety and realise the resultant performance improvements.

''Relevant Principles'':
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]
* [[Maximise Team autonomy]]
* [[Cultivate learning between teams]]
* [[Involve those affected by change]]
* [[Create a Learning Organisation]]
* [[Leadership supports rather than drives the work]]
''Relevant References:''

* [https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/introduction/ Project Aristotle]: On team performance factors -“Psychological safety was by far the most important of the five key dynamics we found. It's the underpinning of the other four (Dependability, Structure & Clarity, Meaning and Impact)."
* Edmondson, A. C. (2019). The fearless organization: Creating psychological safety in the workplace for learning, innovation, and growth. John Wiley & Sons, Inc.

== Options for Scaling Agile Teams ==

=== Assumptions on the Need for Scale ===
Many companies operate under the assumption that one team will be insufficient in larger product development challenges. This thinking is often rooted in assembly line thinking, where higher output means higher value and, to double production, there is a need to double the assembly line and the people working in it. Product development does not function based on that logic:

* The difference between the best and worst performers in a knowledge-based organisation is way larger than in manufacturing
* In developing high-tech products, the results are more dependent on the generated outcome than on the output. Those outputs that do not generate value are waste!

So, assuming that scale is required is often incorrect. One small team working in the right organisational ecosystem can, in many cases, deliver exceptional results. This should be the default assumption, as scaling a development organisation using more teams will inevitably add complexity and overhead.

''Related Principles:''

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

=== Optimise a Single Team ===
Before moving to a multi-team scaled model, first, implement options to improve the delivery capabilities of the single team. This strategy will result in increased value delivery by the team and additionally provide valuable empirical data on which to base the decision on the need to scale beyond a single team.

However, in many cases, it is necessary to have several teams collaborate on the same product development. For example, the complexity and diversity of the technical or business domains may exceed the cognitive capabilities of a single small team.

''Related Principles'': [[Limit Team Mental Workload]]

=== Grow the Single Team ===
One possible option is to enlarge the Team by adding more and more people. We know from the research on Teams that this approach will only be viable for up to approximately 10 people. Most research puts the optimum team size as less than 10, so there will be a balance point at which the overhead of multiple smaller teams will be less than the suboptimal performance likely for a large team. Scrum, for example, says only up to 9 people in the Development Team (Scrum Guides until 2017) or, in the current version, up to 10 people, including Scrum Master and Product Owner ([https://scrumguides.org/scrum-guide.html Scrum Guide 2020]).

[[File:Team Image 3.png|frameless|502x502px]]

There are two competing forces impacting the Team's size:

* Smaller Teams performing better: Functioning team dynamics, collaboration, knowledge transfer, and alignment are more straightforward with fewer people being involved.
* In order to have all the necessary skills in a Team, there might be the need to have more people in it. This issue becomes more critical the greater the number and diversity of technologies involved.

Eventually, in large product development, this is not a viable option as we reach a maximum effective size for a single team and have to explore options to increase then umber of teams.

''Related Principles:''

* [[Maximise team empowerment and localised decision making]]
* [[Favour teams with maximised cognitive diversity]]
* [[Limit Team Mental Workload]]

=== Divide the development into separate parts - "Component teams" ===
The second option would be to have several Teams divide the solution accountability, i.e. each Team takes part in the product development with the aim of working as much as possible in isolation from the other Teams, a configuration usually known as Component Teams. The usual boundaries used for the split are knowledge, hierarchy, politics, sites, ... Rarely, though, is this split planned according to sound organisational design principles and is more often the result of years of action of many competing forces.

[[File:Team Image 4.png|frameless|547x547px]]

This strategy might sometimes result in what appears to be a higher local development speed, though often a lot of the work done by the Teams is actually coordination with other parts of the organisation rather than actual output creation. In any case, the drawbacks are enormous:

* Knowledge silos, with teams not understanding how to create a complete solution
* Lack of focus on a complete solution: Each team considers the work as done when they have implemented their part according to whatever definition they agreed on
* Lack of accountability, often resulting in finger-pointing and partisan thinking: what we did works; it's somebody else's fault if the complete solution does not work!
* Increased department thinking and internal politics games
* Increase of local solutions, further complicating the technological landscape and the opportunities for product-wide learning
* Very few people in the organisation have sufficient knowledge to talk to and understand the actual customers and end users, resulting in a system of Chinese Whispers and the relative distortion of information that this causes along the way

A particular form of this accountability split is when one Team is established to define the work for other Teams. This creates a thinker-worker split that is typical of the Tayloristic view of a company but is highly problematic in knowledge-creating ones. Typical examples of this are Analysts vs. Developers, Architects vs. Developers, Developers vs. Testers, ... The structure is just as problematic as having Component Teams, with the addition of creating some Teams that have a perceived higher authority, thus exacerbating morale problems.

=== End-to-end "Feature Teams" ===
The other option is to create Teams capable of developing end-to-end products, also known as Feature Teams. Each Team can develop separately from the others without the (or, usually, with limited) need to coordinate with other Teams.

[[File:Team Image 5.png|frameless|488x488px]]

There are, however, two challenges:

* Each Team needs to have a much broader knowledge about the solution domain and about the business domain, i.e. learning becomes a central aspect of how the organisation works. This is fully aligned with what many regards as the way a modern knowledge-based organisation should work ([[Maximise team empowerment and localised decision making]]). Nonetheless, it requires an investment in learning that many organisations don't consider or see as needed.
* While knowledgeable Teams can develop end-to-end parts of a solution independently, they still need to integrate their contributions. This problem also exists for Component Teams, but in the case of Feature Teams, the probability of colliding changes is higher because they are more likely to apply changes in the same places as other teams. How problematic this is in practice depends on how the development is organised. In software, for example, there are several practices and technologies that help to reduce this issue a lot: continuous integration/continuous delivery, modern development tools, collective code ownership, ..., so that for properly organised software development, this point is de facto irrelevant (though the investment many companies have to do to reach that point is huge!) In other disciplines, your mileage might vary. The section on [[Craft]] describes several options.

We suggest this option is the preferred one, though sometimes, in very large product development, Component Teams may have to be considered as part of the team model design. If you are including Component Teams, we suggest to keep looking for ways to implement more and more Feature Teams and optimise towards the relevant ELSE principles.

''Related Principles:''
*[[Organise around value streams]]
*[[Shared context improves decisions]]
*[[Minimise unnecessary complexity]]

*[[Maximise Team autonomy]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]

*[[Maximise team empowerment and localised decision making]]

* [[Use the Definition of Done as an enabling constraint]]
*[[Regular small changes: Scale the number of changes rather than the size]]
*[[Amplify Speed and Quality of Learning Cycles]]
* [[Collective responsibility for complete product development]]
*[[Support autonomy with clear boundaries]]
* [[Product solution design is driven from within development teams]]
*[[Invest in quality]]

== Effective Autonomy with Boundaries ==
How do we direct Agile teams without telling them what to do and destroying their autonomy and empowerment? This challenge is often not well addressed even for a single Agile product team, but scaling scenarios often experience dramatically undermined autonomy and empowerment.

The answer is to ensure that there are carefully cultivated and agreed boundaries around the teams that make clear what they can and what they can not decide and act on independently. Team autonomy should be “Bounded”.

[[File:Autonomy Boundary Graphic (1).png|frameless|507x507px]]

Careful design and co-creation of team boundaries enable:

* Explicitly agreed boundaries – teams won’t have to guess what decision authority they have.
* Focus – teams have meaningful clarity of purpose and priorities guided by their Product Owner.
* Constraints – the team understand the technology, design and compliance standards within which they need to work.
* Emergence – boundaries should evolve when teams find that they limit end-to-end value creation (be wary of and avoid the local optimisation trap!).

The diagram below illustrates an array of “Control Surfaces” that serve as mechanisms to bound interactions with the team and actions by the team:

[[File:Agile Team Control Surfaces.png|frameless|900x900px]]

==== Team Focus ====
It is easy to lose the idea of “Meaningful clarity of purpose” when decomposing a large product across multiple teams. Often they are reduced to working on arbitrary elements of technology layers or product components, with little idea of the customer context and how their work contributes to end-to-end value. A common telltale sign of this scenario is “technical” backlog items that have no direct business or customer value.

Careful attention is required to ensure that the team structure is designed to match end-to-end aspects of the value stream to retain clarity of meaningful purpose and clear sight of the value of their work. Evidence that this is working will be that the teams can autonomously deliver backlog items that are articulated in business and customer outcomes with clear value.

Consideration should also be given to the dual nature of a team’s mission when working as part of a team of teams. There will be a balance between team-specific goals and the wider collective mission of the product group. Shared goals across teams can encourage inter-team collaboration, however the stronger the need for collaboration, the less autonomous the teams are likely to be.

==== Team Constraints ====
Teams need to be free to decide how to meet the outcome described by Product Backlog items and their Acceptance Criteria. However, constraints can be applied via the Definition of Done (DoD) and other agreements that cover cross-team integration, standards and compliance aspects. These agreements should be collaboratively formed with the team and other relevant stakeholders and should be viewed as living, evolving artefacts that the team can challenge.

Supporting environments and tooling will also be required to ensure that the aspirations expressed in the constraints can be met in an effective and practical manner.

==== Boundary Permeability ====
The “Semi-permeable” boundary around the team indicates the protection the team should have from disruption and interference in their mission to achieve the agreed goals. It should, however, not exclude the team from interacting directly with sources of information external to the team.

In a team of teams setting, this may well include other teams. These interactions can be supported by practices such as joint Sprint Planning, cross-team pairing, group design workshops, shared Sprint Goals and joint Sprint Reviews.

==== Role of Leadership ====
Leadership are considered as “Stakeholders” when it comes to influencing what teams focus on. They also have an essential role in supporting the evolution of the environment around the teams to ensure that they can maximise their collective value creation for customers and stakeholders.

Where the team are hindered by issues such as unnecessary or overly heavy bureaucracy, leadership should work to understand and evolve the organisational systems and structures. Other impediments to value creation can come from policies and systems that promote unhelpful behaviours, for example, performance reviews and objective setting that encourage individualistic or tribal actions.

==== Preconditions ====
The boundary delineates who is in the team and assumes that the membership is largely stable and committed to accomplishing the shared team mission - what Richard Hackman refers to as a “Real Team” - Leading Teams by J. Richard Hackman. Sharing specialist team members across multiple teams is a common anti-pattern that erodes this concept of a Real Team.

Teams must be cross-functional – they have all the skills required to autonomously turn backlog items from ideas to outcomes. In other words, the team is not dependent on external capability to deliver items from their backlog.

A further precondition is that backlog items themselves are autonomously valuable and articulated in business domain outcome form and not as technical or component level work.

=== Protecting Autonomy at Scale ===
In scaled situations, where there can be multiple teams contributing to a large and complex outcome, there is often a loss of team autonomy. There are a number of potential causes, including:

* Top-down imposition of bureaucracy and additional process controls
* Additional team coordination functions external to the teams
* Lack of clarity about what is within a given team’s decision-making authority
* Poor Value Stream/Product and Team design leads to interdependent and overlapping work
* Over-specialisation of skills leads to teams that are not fully cross-functional
* Design decisions imposed by functions external to the teams. E.g. Architectural, User Experience, Security, etc…

Ideally, the design of the team of teams structure should be optimised to provide an environment that will support greater team autonomy. Look to incrementally improve the following factors to foster the conditions for greater potential team autonomy:

# Design the Product and team structures so that they align closely with the business and customer Value Stream.
#*[[Organise around value streams]]
#*[[Favour Teams with broader Business Domain Competence]]
# Optimise the team structures and skills mixture to minimise interdependencies with other teams whilst staying true to number 1.
#*[[Maximise team empowerment and localised decision making]]
#*[[Maximise Team autonomy]]
#*[[Favour teams with maximised cognitive diversity]]
# Avoid external subject matter experts injecting design decisions into teams. This requires that the team membership includes the relevant competencies and has the authority to emerge design from within the team.
#*[[Product solution design is driven from within development teams]]
#*[[Technical leaders as coaches, mentors and community leaders]]

Building on the evolving improvements to the structural team model, work with the teams and relevant stakeholders to create boundaries to support autonomous team behaviour at scale:

# Create explicitly agreed boundaries around each team so that they understand what they can decide and execute autonomously, versus what they need to escalate and discuss externally. Boundaries should be set and evolved collaboratively with the teams rather than imposed on them.
# Use shared “Enabling Constraints” to encourage teams to collaborate enough that their autonomous design and output integrate to support the outcomes of the Value Stream. A combined integrated Sprint Review on a shared environment at the end of each Sprint is a great example.
# Ensure that the teams work within a shared context of the end-to-end Value Stream so that they understand the bigger picture of the overall mission.
# Continuously evolve all of the above!

Consider a number of teams contributing to the same Value Stream. Each team will need a clear set of boundaries within which they can be autonomous. These team boundaries may also need to share some common elements to support consistency for decisions that have a Value Stream-wide impact. For example, there may need to be common interface or user experience standards so that the combined work has cohesion and user interaction consistency.

''Related Principle: [[Support autonomy with clear boundaries]]''

The diagram below illustrates this relationship where the effective team boundaries include common Value Stream level boundary elements. Each team should also be able to exert influence on the Value Stream boundaries, for example, identifying new elements or those that need to be updated and removing excess restrictions and bureaucracy.

[[File:Value Stream Boundary.png|frameless|800x800px]]

All Value Stream teams sharing a common set of core Definition of Done elements is a good example of a shared boundary that will support inter-team collaboration and consistent quality of the integrated whole.

''Related Principle:'' [[Use the Definition of Done as an enabling constraint]]

The DoD is also an example of where an explicit boundary, may be, and usually is, influenced by organisation-wide quality standards.

The model can be thought of as a “Russian Doll”, with the effective boundary from a team’s perspective being an amalgam of the organisational + Value Stream + team-specific boundaries. As per the diagram below:

[[File:Business_Unit_Organisational_Boundary.png|frameless|1000x1000px]]

== Maximise Team Learning ==
In order to have Teams that can develop end-to-end Products, the organisation needs to create an environment where learning is possible, i.e. a Learning Organisation. The concept was coined and popularised by Peter Senge. While it's relevant for every knowledge-based organisation, it is even more important in large-scale product development due to the increased cognitive load with larger product scope.

Creating a learning organisation is everybody's responsibility, but leadership has a more important systemic role of enabling learning to happen.

For more details, there are several principles related to this:

* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Cultivate learning between teams]]
* [[Create a Learning Organisation]]

== Team Perspective Summary ==
* Start small and retain the power of small autonomous Agile teams until reaching the threshold where scaling is no longer optional.
*How teams are designed is a key determining factor in enabling their autonomy.
* Team design should be based on a Product structure that is aligned with Value Streams.
*Teams should have a clear sight of the value they deliver in terms of business outcomes, and end-to-end value stream is ideal.
* Team design should be optimised to reduce interdependencies between teams, external experts and external services.
* The right boundary constraints, explicitly articulated, and collaboratively set and evolved, will establish the conditions for autonomous and empowered teams.
* Scaled teams should collaborate and agree on the boundary constraints that will be necessary to support clear autonomy at a team level and understand why some constraints need to be set and evolved at a Value Stream level.
* Value stream and team boundaries have to consider what constraints need to be included from the wider organisation.
* Although boundary constraints define the limit of team and Value Stream autonomy, they are open to challenge whenever they appear to impede value flow.
*Maximise learning within and between teams - the value of your teams is in their knowledge and capabilities!
*Continuously evolve your team structures and models of collaboration using the ELSE Principles as a guide.

The Teams' Perspective

2024-05-21T21:17:15Z

Ppugliese:

__NOTOC__
== Introduction ==
“In the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” – Charles Darwin

The evolutionary pressure in the world has never been more volatile and uncertain. Surviving and thriving requires organisations to respond rapidly, adapt and navigate complex challenges.

An Agile organisation addresses these challenges by nurturing and supporting Agile teams with a high degree of autonomy, that can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services.

This section revisits the essential elements of successful Agile teams and then explores how we can scale this model to a larger product development organisation whilst retaining the advantages. The key related Scaling Principles are called out in the relevant places.

'''Sections in this Perspective:'''

* Agile Teams
*# Defining “Highly Effective”
*# Why Agile Teams Are Effective
*# Elements of a Highly Effective Agile Team
* Options for Scaling Agile Teams
*# Assumptions on the Need for Scale
*# Optimise a Single Team
*# Grow the Single Team
*# Component Teams
*# Feature Teams
* Effective Autonomy with Boundaries
* Maximise Team Learning

==Agile Teams==
===Defining "Highly Effective"===
How do we recognise that a team is highly effective, what are the visible signs and capabilities?

Here are some examples of what we might be looking for:

* Consistently realise high-value, high-quality outcomes with short lead-time and low waste
* Creative and innovative solutions to diverse, complex problems
* Learn fast and are continually improving
* Adaptable and Resilient
* Collaborative, supportive and inclusive culture

=== Why Agile Teams Are Effective ===
Agile teams are effective because they are small units of people committed and focused on getting the “job done”, autonomously delivering end-to-end products to customers.

In this context, “end-to-end” means having control over everything related to the execution of product development, from the analysis and design activities through all the technological development and testing to ensure the released product is successful.

With a high degree of autonomy, they can respond rapidly, operating with minimum dependencies on external decision-makers and other teams and services. Waste, caused by hand-offs, dependencies and coordination, is dramatically reduced as it is internalised within the boundary of the team’s collaboration.

According to Richard Hackman, the “recipe” to create great teams is the following:

# A real team
# Compelling direction
# Enabling team structure
# Supportive organisational context
# Expert team coaching

Most Agile approaches implement this model, though in slightly different ways. For example, Scrum has a Product Owner providing compelling direction and a Scrum Master providing coaching and working to achieve a supportive organisational context:

[[File:Team Image 2.png|frameless|468x468px]]

In summary, highly effective Agile teams are motivated, small, empowered and can function with significant autonomy and clarity of purpose.

''Related Principles:''

* [[Self-managed teams]]
* [[Maximise team empowerment and localised decision making]]
* [[Maximise Team autonomy]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]

''Relevant References:''

Hackman, J. R. (2002). Leading teams: Setting the stage for great performances. Harvard Business School Press.

=== Elements of a Highly Effective Agile Team ===
In this section, we dig a little deeper into the elements that go into an effective Agile team. The diagram below illustrates some of the elements incorporated within a Scrum manifestation of the Agile principles.

[[File:Effective Agile Teams.png|frameless|900x900px]]

We explore these elements required for a highly effective Agile team:

* Small Team Size
* Autonomous and Empowered
* Clarity of Purpose
* Team Membership
* Cross-functional
* Supportive Organisational Context
* Team Coaching
* Psychological Safety

==== Small Team Size ====
Research on Team size consistently finds that for complex knowledge work with high interdependency of tasks, smaller teams, 10 or less, are more effective than larger teams.

Scrum, for example, in the [https://scrumguides.org/scrum-guide.html 2020 Scrum Guide] says,” The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive.”

Larger teams experience dramatically increased communication complexity, increased effort and time to deliver a given outcome and lower motivation and morale.

''Relevant Principles'':
*[[Scale only when you need to]]
*[[Start small and scale success]]
*[[Organise around value streams]]
*[[Minimise unnecessary complexity]]

* [[Limit Team Mental Workload]]

''Relevant references:''

* [[wikipedia:Ringelmann_effect|The Ringelmann Effect]]
* [http://psycnet.apa.org/psycarticles/2011-21070-001 Team Size and Quality of Group Experience]
* [[wikipedia:Brooks's_law|Brooks's Law]]
* [[wikipedia:Metcalfe's_law|Metcalfe’s Law]]
* [https://rework.withgoogle.com/blog/many-hands-may-not-make-light-work/ Google re:Work]
* [https://store.hbr.org/product/the-wisdom-of-teams-creating-the-high-performance-organization/15042 Katzenbach, J. R., & Smith, D. K. (2015). The wisdom of teams: Creating the high-performance organization. Harvard Business Review Press]
* [https://www.qsm.com/articles/familiar-metric-management-small-beautiful-once-again Familiar Metric Management - Small is Beautiful-Once Again, Lawrence H. Putnam and Ware Myers]

==== Autonomous and Empowered ====
An Agile team should be able to operate with a high degree of autonomy, taking a requirement or idea from concept to realisation with a minimum of outside dependencies. In addition, they will be empowered to decide how to solve the problem without the need to seek permission from outside authorities.

The team need to be free to decide how to meet the outcome described by clear goals and Product Backlog items and their Acceptance Criteria (or equivalent) - see Clarity of Purpose. However, there should be clearly understood boundaries to the team’s autonomy and empowerment. These boundary constraints can be applied via the Definition of Done (DoD) and other agreements that cover standards and compliance aspects. These agreements should be collaboratively formed with the team and other relevant stakeholders and should be viewed as living, evolving artefacts that the team can challenge.

In addition to the efficiency gains due to the speed of decision-making and reduced waste caused by delays waiting for dependencies to be resolved, teams experience increased motivation and accountability for their work.

The quality of decisions also improves due to the proximity of the decisions to the work and information, along with the skills of the people deciding.

''Relevant Principles'':
* [[Support autonomy with clear boundaries]]
* [[Leadership supports rather than drives the work]]
* [[Product solution design is driven from within development teams]]
* [[Maximise engagement]]
* [[Maximise Team autonomy]]
* [[Create clarity of purpose]]
* [[Leadership supports rather than drives the work]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Self-managed teams]]
* [[Self-managed Team of Teams]]

''Relevant References:''

[https://selfdeterminationtheory.org/theory/ A relevant excerpt from Self-Determination Theory]: “Conditions supporting the individual’s experience of autonomy, competence, and relatedness are argued to foster the most volitional and high-quality forms of motivation and engagement for activities, including enhanced performance, persistence, and creativity.”

==== Clarity of Purpose ====
In the words of Stephen Bungay, “The more alignment you have around direction, the more autonomy you can get around actions” - [https://www.stephenbungay.com/Books.ink The Art of Action by Stephen Bungay] Bungay, S. (2021).

A clear, compelling and common purpose guides and enables the team to shape their autonomous and empowered work. The fact that the team share a purpose is an important element to support and motivate a collaborative team dynamic rather than just a group of individual efforts.

Creating and maintaining the purpose of a team is an important contact point between the team and outside stakeholders. This process needs to work in such a way that it provides clear alignment and rich contextual information, whilst simultaneously protecting the autonomy and empowerment of the team. In Scrum, the Product Owner is responsible for engaging stakeholders to input into goals and requirements and feedback on team outputs, whilst retaining decision-making authority within the team.

The “Semi-permeable” boundary around a team indicates the protection the team should have from disruption and interference in their mission to achieve the agreed goals. It should, however, not exclude the team from interacting directly with sources of information external to the team.

''Relevant Principles'':
*[[Create clarity of purpose]]

*[[Shared context improves decisions]]

*[[Organise around value streams]]

*[[Maximise engagement]]

*[[Maximise Team autonomy]]
*[[Maximise team empowerment and localised decision making]]
*[[Favour Teams with broader Business Domain Accountability]]
*[[Self-managed teams]]
*[[Self-managed Team of Teams]]

==== Team Membership ====
Largely stable membership enables team formation to take place, evolving from a group of individuals to a collaborating, mutually supportive team unit. A revolving set of players creates an uncertain and unstable environment for relationships and trust to build and is unlikely to lead to a strong team identity.

Team members should complement each other. Covering each other's weaknesses and providing a constructive diversity of perspectives and experiences. In addition, the team should be resilient and retain the ability to deliver outcomes even when missing individual team members through vacations and illness.

''Relevant References:''

“Teams with stable membership perform better than those that constantly have to deal with the arrival of new members and the departure of old ones.” - [https://scholar.harvard.edu/rhackman/pages/leading-teams Leading Teams by J. Richard Hackman].

''Relevant Principles'':

* [[Favour teams with maximised cognitive diversity]]
*[[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
*[[Maximise engagement]]

*[[Maximise Team autonomy]]

==== Cross-functional ====
Teams are cross-functional – they have all the business and delivery domain skills required to autonomously turn backlog items from ideas to outcomes. In other words, the team is not dependent on external capability to deliver items from their backlog. In this context, “outcomes” refers to realised value to the organisation and/or customers.

''Relevant Principles'':
* [[Favour teams with maximised cognitive diversity]]
* [[Favour Teams with broader Solution Accountability]]
* [[Limit Team Mental Workload]]
* [[Maximise Team autonomy]]
* [[Cultivate learning between teams]]
* [[Product solution design is driven from within development teams]]
* [[Create a Learning Organisation]]

==== Supportive Organisational Context ====
Leaders are considered to be “Stakeholders” when it comes to influencing what the team focus on. They don’t directly tell the team what to work on or how to accomplish their work. However, they have an essential role in supporting the evolution of the environment around the team to ensure that the team can maximise their value creation for customers and stakeholders. Where the team are hindered by issues such as unnecessary or overly heavy bureaucracy, leadership should work to understand and evolve the organisational systems and structures.

''Relevant Principles'':
* [[Leadership supports rather than drives the work]]
* [[Create clarity of purpose]]
* [[Limit Team Mental Workload]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]
* [[Maximise Team autonomy]]
* [[Create a Learning Organisation]]
* [[Cultivate learning between teams]]
* [[Involve those affected by change]]
* [[Provide an impediment removal service]]

==== Team Coaching ====
Assembling all the correct ingredients is a good start, but on its own is unlikely to result in a successful team. A coach (e.g. a Scrum Master) helps the individual players learn how to work together as a collaborating team, accelerating the learning from group experience to continuously improve their collective processes, capabilities and interactions.

''Relevant Principles'':
* [[Leadership supports rather than drives the work]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise Team autonomy]]
* [[Cultivate learning between teams]]
* [[Create a Learning Organisation]]

==== Psychological Safety ====
Amy Edmondson defines [https://amycedmondson.com/psychological-safety/ Psychological Safety] as ”a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes…”

A simple definition of a fundamental element that is required for a team to learn from its mistakes, innovate products, services and processes, take accountability, and collaborate and support each other.

Leadership within and external to the team has a major role in creating and maintaining the environment to promote high levels of psychological safety and realise the resultant performance improvements.

''Relevant Principles'':
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]
* [[Maximise Team autonomy]]
* [[Cultivate learning between teams]]
* [[Involve those affected by change]]
* [[Create a Learning Organisation]]
* [[Leadership supports rather than drives the work]]
''Relevant References:''

* [https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/introduction/ Project Aristotle]: On team performance factors -“Psychological safety was by far the most important of the five key dynamics we found. It's the underpinning of the other four (Dependability, Structure & Clarity, Meaning and Impact)."
* Edmondson, A. C. (2019). The fearless organization: Creating psychological safety in the workplace for learning, innovation, and growth. John Wiley & Sons, Inc.

== Options for Scaling Agile Teams ==

=== Assumptions on the Need for Scale ===
Many companies operate under the assumption that one team will be insufficient in larger product development challenges. This thinking is often rooted in assembly line thinking, where higher output means higher value and, to double production, there is a need to double the assembly line and the people working in it. Product development does not function based on that logic:

* The difference between the best and worst performers in a knowledge-based organisation is way larger than in manufacturing
* In developing high-tech products, the results are more dependent on the generated outcome than on the output. Those outputs that do not generate value are waste!

So, assuming that scale is required is often incorrect. One small team working in the right organisational ecosystem can, in many cases, deliver exceptional results. This should be the default assumption, as scaling a development organisation using more teams will inevitably add complexity and overhead.

''Related Principles:''

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

=== Optimise a Single Team ===
Before moving to a multi-team scaled model, first, implement options to improve the delivery capabilities of the single team. This strategy will result in increased value delivery by the team and additionally provide valuable empirical data on which to base the decision on the need to scale beyond a single team.

However, in many cases, it is necessary to have several teams collaborate on the same product development. For example, the complexity and diversity of the technical or business domains may exceed the cognitive capabilities of a single small team.

''Related Principles'': [[Limit Team Mental Workload]]

=== Grow the Single Team ===
One possible option is to enlarge the Team by adding more and more people. We know from the research on Teams that this approach will only be viable for up to approximately 10 people. Most research puts the optimum team size as less than 10, so there will be a balance point at which the overhead of multiple smaller teams will be less than the suboptimal performance likely for a large team. Scrum, for example, says only up to 9 people in the Development Team (Scrum Guides until 2017) or, in the current version, up to 10 people, including Scrum Master and Product Owner ([https://scrumguides.org/scrum-guide.html Scrum Guide 2020]).

[[File:Team Image 3.png|frameless|502x502px]]

There are two competing forces impacting the Team's size:

* Smaller Teams performing better: Functioning team dynamics, collaboration, knowledge transfer, and alignment are more straightforward with fewer people being involved.
* In order to have all the necessary skills in a Team, there might be the need to have more people in it. This issue becomes more critical the greater the number and diversity of technologies involved.

Eventually, in large product development, this is not a viable option as we reach a maximum effective size for a single team and have to explore options to increase then umber of teams.

''Related Principles:''

* [[Maximise team empowerment and localised decision making]]
* [[Favour teams with maximised cognitive diversity]]
* [[Limit Team Mental Workload]]

=== Divide the development into separate parts - "Component teams" ===
The second option would be to have several Teams divide the solution accountability, i.e. each Team takes part in the product development with the aim of working as much as possible in isolation from the other Teams, a configuration usually known as Component Teams. The usual boundaries used for the split are knowledge, hierarchy, politics, sites, ... Rarely, though, is this split planned according to sound organisational design principles and is more often the result of years of action of many competing forces.

[[File:Team Image 4.png|frameless|547x547px]]

This strategy might sometimes result in what appears to be a higher local development speed, though often a lot of the work done by the Teams is actually coordination with other parts of the organisation rather than actual output creation. In any case, the drawbacks are enormous:

* Knowledge silos, with teams not understanding how to create a complete solution
* Lack of focus on a complete solution: Each team considers the work as done when they have implemented their part according to whatever definition they agreed on
* Lack of accountability, often resulting in finger-pointing and partisan thinking: what we did works; it's somebody else's fault if the complete solution does not work!
* Increased department thinking and internal politics games
* Increase of local solutions, further complicating the technological landscape and the opportunities for product-wide learning
* Very few people in the organisation have sufficient knowledge to talk to and understand the actual customers and end users, resulting in a system of Chinese Whispers and the relative distortion of information that this causes along the way

A particular form of this accountability split is when one Team is established to define the work for other Teams. This creates a thinker-worker split that is typical of the Tayloristic view of a company but is highly problematic in knowledge-creating ones. Typical examples of this are Analysts vs. Developers, Architects vs. Developers, Developers vs. Testers, ... The structure is just as problematic as having Component Teams, with the addition of creating some Teams that have a perceived higher authority, thus exacerbating morale problems.

=== End-to-end "Feature Teams" ===
The other option is to create Teams capable of developing end-to-end products, also known as Feature Teams. Each Team can develop separately from the others without the (or, usually, with limited) need to coordinate with other Teams.

[[File:Team Image 5.png|frameless|488x488px]]

There are, however, two challenges:

* Each Team needs to have a much broader knowledge about the solution domain and about the business domain, i.e. learning becomes a central aspect of how the organisation works. This is fully aligned with what many regards as the way a modern knowledge-based organisation should work ([[Maximise team empowerment and localised decision making]]). Nonetheless, it requires an investment in learning that many organisations don't consider or see as needed.
* While knowledgeable Teams can develop end-to-end parts of a solution independently, they still need to integrate their contributions. This problem also exists for Component Teams, but in the case of Feature Teams, the probability of colliding changes is higher because they are more likely to apply changes in the same places as other teams. How problematic this is in practice depends on how the development is organised. In software, for example, there are several practices and technologies that help to reduce this issue a lot: continuous integration/continuous delivery, modern development tools, collective code ownership, ..., so that for properly organised software development, this point is de facto irrelevant (though the investment many companies have to do to reach that point is huge!) In other disciplines, your mileage might vary. The section on [[Craft]] describes several options.

We suggest this option is the preferred one, though sometimes, in very large product development, Component Teams may have to be considered as part of the team model design. If you are including Component Teams, we suggest to keep looking for ways to implement more and more Feature Teams and optimise towards the relevant ELSE principles.

''Related Principles:''
*[[Organise around value streams]]
*[[Shared context improves decisions]]
*[[Minimise unnecessary complexity]]

*[[Maximise Team autonomy]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Accountability]]

*[[Maximise team empowerment and localised decision making]]

* [[Use the Definition of Done as an enabling constraint]]
*[[Regular small changes: Scale the number of changes rather than the size]]
*[[Amplify Speed and Quality of Learning Cycles]]
* [[Collective responsibility for complete product development]]
*[[Support autonomy with clear boundaries]]
* [[Product solution design is driven from within development teams]]
*[[Invest in quality]]

== Effective Autonomy with Boundaries ==
How do we direct Agile teams without telling them what to do and destroying their autonomy and empowerment? This challenge is often not well addressed even for a single Agile product team, but scaling scenarios often experience dramatically undermined autonomy and empowerment.

The answer is to ensure that there are carefully cultivated and agreed boundaries around the teams that make clear what they can and what they can not decide and act on independently. Team autonomy should be “Bounded”.

[[File:Autonomy Boundary Graphic (1).png|frameless|507x507px]]

Careful design and co-creation of team boundaries enable:

* Explicitly agreed boundaries – teams won’t have to guess what decision authority they have.
* Focus – teams have meaningful clarity of purpose and priorities guided by their Product Owner.
* Constraints – the team understand the technology, design and compliance standards within which they need to work.
* Emergence – boundaries should evolve when teams find that they limit end-to-end value creation (be wary of and avoid the local optimisation trap!).

The diagram below illustrates an array of “Control Surfaces” that serve as mechanisms to bound interactions with the team and actions by the team:

[[File:Agile Team Control Surfaces.png|frameless|900x900px]]

==== Team Focus ====
It is easy to lose the idea of “Meaningful clarity of purpose” when decomposing a large product across multiple teams. Often they are reduced to working on arbitrary elements of technology layers or product components, with little idea of the customer context and how their work contributes to end-to-end value. A common telltale sign of this scenario is “technical” backlog items that have no direct business or customer value.

Careful attention is required to ensure that the team structure is designed to match end-to-end aspects of the value stream to retain clarity of meaningful purpose and clear sight of the value of their work. Evidence that this is working will be that the teams can autonomously deliver backlog items that are articulated in business and customer outcomes with clear value.

Consideration should also be given to the dual nature of a team’s mission when working as part of a team of teams. There will be a balance between team-specific goals and the wider collective mission of the product group. Shared goals across teams can encourage inter-team collaboration, however the stronger the need for collaboration, the less autonomous the teams are likely to be.

==== Team Constraints ====
Teams need to be free to decide how to meet the outcome described by Product Backlog items and their Acceptance Criteria. However, constraints can be applied via the Definition of Done (DoD) and other agreements that cover cross-team integration, standards and compliance aspects. These agreements should be collaboratively formed with the team and other relevant stakeholders and should be viewed as living, evolving artefacts that the team can challenge.

Supporting environments and tooling will also be required to ensure that the aspirations expressed in the constraints can be met in an effective and practical manner.

==== Boundary Permeability ====
The “Semi-permeable” boundary around the team indicates the protection the team should have from disruption and interference in their mission to achieve the agreed goals. It should, however, not exclude the team from interacting directly with sources of information external to the team.

In a team of teams setting, this may well include other teams. These interactions can be supported by practices such as joint Sprint Planning, cross-team pairing, group design workshops, shared Sprint Goals and joint Sprint Reviews.

==== Role of Leadership ====
Leadership are considered as “Stakeholders” when it comes to influencing what teams focus on. They also have an essential role in supporting the evolution of the environment around the teams to ensure that they can maximise their collective value creation for customers and stakeholders.

Where the team are hindered by issues such as unnecessary or overly heavy bureaucracy, leadership should work to understand and evolve the organisational systems and structures. Other impediments to value creation can come from policies and systems that promote unhelpful behaviours, for example, performance reviews and objective setting that encourage individualistic or tribal actions.

==== Preconditions ====
The boundary delineates who is in the team and assumes that the membership is largely stable and committed to accomplishing the shared team mission - what Richard Hackman refers to as a “Real Team” - Leading Teams by J. Richard Hackman. Sharing specialist team members across multiple teams is a common anti-pattern that erodes this concept of a Real Team.

Teams must be cross-functional – they have all the skills required to autonomously turn backlog items from ideas to outcomes. In other words, the team is not dependent on external capability to deliver items from their backlog.

A further precondition is that backlog items themselves are autonomously valuable and articulated in business domain outcome form and not as technical or component level work.

=== Protecting Autonomy at Scale ===
In scaled situations, where there can be multiple teams contributing to a large and complex outcome, there is often a loss of team autonomy. There are a number of potential causes, including:

* Top-down imposition of bureaucracy and additional process controls
* Additional team coordination functions external to the teams
* Lack of clarity about what is within a given team’s decision-making authority
* Poor Value Stream/Product and Team design leads to interdependent and overlapping work
* Over-specialisation of skills leads to teams that are not fully cross-functional
* Design decisions imposed by functions external to the teams. E.g. Architectural, User Experience, Security, etc…

Ideally, the design of the team of teams structure should be optimised to provide an environment that will support greater team autonomy. Look to incrementally improve the following factors to foster the conditions for greater potential team autonomy:

# Design the Product and team structures so that they align closely with the business and customer Value Stream.
#*[[Organise around value streams]]
#*[[Favour Teams with broader Business Domain Competence]]
# Optimise the team structures and skills mixture to minimise interdependencies with other teams whilst staying true to number 1.
#*[[Maximise team empowerment and localised decision making]]
#*[[Maximise Team autonomy]]
#*[[Favour teams with maximised cognitive diversity]]
# Avoid external subject matter experts injecting design decisions into teams. This requires that the team membership includes the relevant competencies and has the authority to emerge design from within the team.
#*[[Product solution design is driven from within development teams]]
#*[[Technical leaders as coaches, mentors and community leaders]]

Building on the evolving improvements to the structural team model, work with the teams and relevant stakeholders to create boundaries to support autonomous team behaviour at scale:

# Create explicitly agreed boundaries around each team so that they understand what they can decide and execute autonomously, versus what they need to escalate and discuss externally. Boundaries should be set and evolved collaboratively with the teams rather than imposed on them.
# Use shared “Enabling Constraints” to encourage teams to collaborate enough that their autonomous design and output integrate to support the outcomes of the Value Stream. A combined integrated Sprint Review on a shared environment at the end of each Sprint is a great example.
# Ensure that the teams work within a shared context of the end-to-end Value Stream so that they understand the bigger picture of the overall mission.
# Continuously evolve all of the above!

Consider a number of teams contributing to the same Value Stream. Each team will need a clear set of boundaries within which they can be autonomous. These team boundaries may also need to share some common elements to support consistency for decisions that have a Value Stream-wide impact. For example, there may need to be common interface or user experience standards so that the combined work has cohesion and user interaction consistency.

''Related Principle: [[Support autonomy with clear boundaries]]''

The diagram below illustrates this relationship where the effective team boundaries include common Value Stream level boundary elements. Each team should also be able to exert influence on the Value Stream boundaries, for example, identifying new elements or those that need to be updated and removing excess restrictions and bureaucracy.

[[File:Value Stream Boundary.png|frameless|800x800px]]

All Value Stream teams sharing a common set of core Definition of Done elements is a good example of a shared boundary that will support inter-team collaboration and consistent quality of the integrated whole.

''Related Principle:'' [[Use the Definition of Done as an enabling constraint]]

The DoD is also an example of where an explicit boundary, may be, and usually is, influenced by organisation-wide quality standards.

The model can be thought of as a “Russian Doll”, with the effective boundary from a team’s perspective being an amalgam of the organisational + Value Stream + team-specific boundaries. As per the diagram below:

[[File:Business_Unit_Organisational_Boundary.png|frameless|1000x1000px]]

== Maximise Team Learning ==
In order to have Teams that can develop end-to-end Products, the organisation needs to create an environment where learning is possible, i.e. a Learning Organisation. The concept was coined and popularised by Peter Senge. While it's relevant for every knowledge-based organisation, it is even more important in large-scale product development due to the increased cognitive load with larger product scope.

Creating a learning organisation is everybody's responsibility, but leadership has a more important systemic role of enabling learning to happen.

For more details, there are several principles related to this:

* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Cultivate learning between teams]]
* [[Create a Learning Organisation]]

== Team Perspective Summary ==
* Start small and retain the power of small autonomous Agile teams until reaching the threshold where scaling is no longer optional.
*How teams are designed is a key determining factor in enabling their autonomy.
* Team design should be based on a Product structure that is aligned with Value Streams.
*Teams should have a clear sight of the value they deliver in terms of business outcomes, and end-to-end value stream is ideal.
* Team design should be optimised to reduce interdependencies between teams, external experts and external services.
* The right boundary constraints, explicitly articulated, and collaboratively set and evolved, will establish the conditions for autonomous and empowered teams.
* Scaled teams should collaborate and agree on the boundary constraints that will be necessary to support clear autonomy at a team level and understand why some constraints need to be set and evolved at a Value Stream level.
* Value stream and team boundaries have to consider what constraints need to be included from the wider organisation.
* Although boundary constraints define the limit of team and Value Stream autonomy, they are open to challenge whenever they appear to impede value flow.
*Maximise learning within and between teams - the value of your teams is in their knowledge and capabilities!
*Continuously evolve your team structures and models of collaboration using the ELSE Principles as a guide.

Shared context improves decisions

2024-05-21T21:16:44Z

Ppugliese:

__NOTOC__
== Description ==
A shared understanding of a common collective valuable purpose improves collaboration, decision-making and motivation.

Ensure that all those involved in the value stream are informed and invested in the end-to-end purpose at an appropriate level of detail to provide context for decision-making. Appropriate, in this context, means that the individuals or groups understand both the higher level collective mission and the specific level of detail to usefully contribute to decomposed elements of work that align with the collective purpose. This should be true for those contributing to developing the product and those providing feedback on the work outcomes.

== Rationale ==
A key element of successful empowerment and motivation is a compelling direction. It also creates an essential "Binding" pressure, converting a group of people into a team(s) with a shared mission. At scale, this is even more vital to prevent locally optimised decisions and team tribal behaviour that can result in them actively competing and working against each other. Diverse opinions are a fundamental component of good design. Having a clear shared target outcome enables constructive discussion about how to implement a solution and avoids disjointed and emotional arguments trying to solve different problems.

Shared context must exist at multiple levels of detail. At a high level, to align multiple teams and stakeholders to an overall mission that they will need to collaborate across. At a more detailed level, to align a team to collaborate and make local decisions that are aligned with the overall mission. This will require practices to envision, shape, decompose, communicate and refresh the appropriate levels of purpose with all stakeholders in the value stream in an ongoing process - see Aligned Autonomy in the [[Leadership|Leadership Perspective]].

== Related Principles ==
* [[Organise around value streams]]
* [[Maximise engagement]]
* [[Create clarity of purpose]]
* [[Maximise team empowerment and localised decision making]]
* [[Support autonomy with clear boundaries]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Organise around value streams]]
* [[Use the Definition of Done as an enabling constraint]]
* [[Product solution design is driven from within development teams]]
* [[Outcome is the primary measure of success]]
* [[End-to-End Product]]
* [[Architectural cohesion]]
* [[Avoid Components]]
* [[Align towards business synergies]]

Minimise unnecessary complexity

2024-05-21T21:16:32Z

Ppugliese:

__NOTOC__
== Description ==
To keep the system of work (e.g. structure and processes) simple, you might need to reduce unnecessary complexity before you start to scale. Scaling an overly complex system is likely to result in inefficiencies and reduced effectiveness of the scaled system, e.g. scale teams aligned to value streams not specialists.

Keep the scaled system simple, applying appropriate scaling approaches as needed and as simply as possible. Make small incremental changes, validate the outcome with evidence before introducing more change.

=== Complexity in Organisations ===

A great part of the literature on scaling starts from the assumption that the Product or the system of Products being developed is too big to be handled by one Product Owner and one Team.

But: is it?

Yes, many Products being developed are very complex and will require some form of scaling concept, but are we sure the complexity we’re dealing with is necessary? Fredrick Brooks in his seminal paper “No Silver Bullet” (http://worrydream.com/refs/Brooks-NoSilverBullet.pdf) examines various aspects of software systems and distinguishes between two types of complexities in a software: Essential and Accidental.

The Essential Complexity is the natural complexity of the problem being solved and it cannot be reduced, while the Accidental Complexity is the complexity added to the problem because of the way we work.

While Brooks refers mostly to the technologies used in building software, a similar reasoning can be applied to organisations: imagine you have a small product to develop, but all your Developers are working from different locations, with bad communication tools, with the customer very far away, using ancient technologies, ... The Product might be small and easy to build, but it is very hard to do so with the setup we have. Let’s call this Product Development Complexity where a part of that is Essential and the rest Accidental.

Now look at it from the perspective of a big company with many development centres who might be even competing for the company’s resources, a structure of management focused on their own careers, silos of information, ... and you can easily understand how the Accidental Complexity of the organisation might make your life very difficult. Trying to make such an organisation agile will give very limited benefits because the problems are not only in the Teams but mostly in an organisational structure that prevents focusing on Products.

So the process we suggest here is to divide the Value Stream[s] in your system in a way to minimise the organisational complexity in selected dimensions, hence creating zones where Product Owners can have a Scope of Accountability where they can be effective and make that part of the system adaptive, i.e. agile. While you might never be able to reach the setup with a single Product Owner having the complete Scope of Accountability, the goal to try and reach there is a powerful way to inform how you can re-arrange your company and reduce Product Development Complexity.

== Rationale ==

A single agile team has a small coordination overhead within the team that a good Scrum Master will work to optimise. As we scale to teams-of-teams we now have additional complexity in our system of work supporting inter-team coordination, that increases with the number of teams in a non-linear fashion.

Even a small reduction of that complexity results, at scale, in large gains and might make a difference between the capability of delivering a product or drowning in overhead.
=== Relevance at Scale ===
While this principle is true in every company implementing agility, at scale it usually becomes a much larger problem: large product development is often spread among many departments, many component teams, …, which makes reducing the accidental complexity a huge but nonetheless crucially important problem to solve.

== Related Principles ==
* [[Scale only when you need to]]
* [[Start small and scale success]]
* [[Organise around value streams]]
* [[Optimise the system of work for the majority of cases rather than the exceptions]]
* [[Maximise team empowerment and localised decision making]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Self-managed teams]]
* [[Self-managed Team of Teams]]
* [[Maximise Team autonomy]]
* [[Provide an impediment removal service]]
* [[Minimum Viable Product Owners]]
* [[Each team "sees" exactly one Product Owner]]
* [[End-to-End Product]]
* [[Architectural cohesion]]
* [[Avoid Components]]
* [[Align towards business synergies]]
* [[Reduce factors increasing product complexity]]

Invest in quality

2024-05-21T21:16:20Z

Ppugliese:

== Description ==
At scale, it is even more essential that we continuously invest time and effort in the quality of the emerging integrated product so that the team of teams can maintain a sustainable pace.

Quality is a complex concept that can include many dimensions, most of which are "Internal" in that customers should be unaware of them, at least until there is an issue at which point they become "External":

* Extensibility - the product's openness to extension and ease with which new or modified capabilities can be added.
* Simplicity - how far the product is from the minimum essential level of complexity required to satisfy required capabilities.
* Maintainability - the ease with which the system can be maintained in an optimum running state.
* Operability - the ease with which the dynamic state of the product can be understood and managed.
* Debug - the ease with which unexpected and undesired product behaviours can be investigated and root causes discovered.
* Testability - the ease with which functional and non-functional product capabilities can be validated.
* Functionality - how well the developed features support the intended outcomes of the product.
* Deployability - the ability to build and deploy the emerging product to any given target environment.
* Reality simulation - how closely target environments simulate the intended or actual production environment.
* Understandability - the cognitive load experienced when learning and comprehending the product.
* Performance and load characteristics - how the emerging product conforms to the intended performance and loading requirements.
* Security - how well the product conforms to the required levels of security.
* Resilience - how the product behaves in failure scenarios and the ease with which it can be recovered to an operational state.
* Standards conformance - how the product conforms to applicable standards, including those for how it is crafted and operated.

== Rationale ==
One of the twelve Agile Manifesto principles states: "Continuous attention to technical excellence and good design enhances agility".

We know from painful experience that an Agile team that trades shortcuts on quality for additional speed cannot sustain the apparent increase in output. They soon suffer additional friction adding new capabilities and spend greater proportions of their time remediating issues. Over the longer term, the team delivers less capability with poorer quality than if they had continuously attended to the quality of the product.

As we scale, the quality problems created by one team impact not only the originating team but also their fellow scaled teams. In addition, due to the challenges of scaling and the additional complexity of the product, there are pressures to compromise many of the dimensions of quality. This leads to delayed feedback, greater rework and longer and less predictable timescales for delivery.

== Related Principles ==
*[[Minimise unnecessary complexity]]
*[[Maximise the Scope of Product Increment]]
*[[Regular small changes: Scale the number of changes rather than the size]]
*[[Amplify Speed and Quality of Learning Cycles]]
*[[Collective responsibility for complete product development]]
*[[Support autonomy with clear boundaries]]
*[[Product solution design is driven from within development teams]]
*[[Technical leaders as coaches, mentors and community leaders]]
*[[Shared context improves decisions]]
*[[Favour Teams with broader Business Domain Competence]]
*[[Maximise Team autonomy]] - ''Contending''
*[[Favour Teams with broader Solution Accountability]]
*[[Limit Team Mental Workload]] - ''Contending:''
*[[Maximise team empowerment and localised decision making]] - ''Contending:''

Maximise engagement

2024-05-21T21:16:05Z

Ppugliese:

__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 Competence]]
* [[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 />

Cultivate learning between teams

2024-05-21T21:15:53Z

Ppugliese:

__NOTOC__
== Description ==
The role of leadership is to foster an environment and incentive for teams to share learning. Teams are the centre for knowledge generation. However, natural tribal instincts tend to drive a "Not invented here" culture, leading to reinvention and wasted effort. In addition, hard-won knowledge stays within team boundaries leading to relearning waste in other teams.

Leaders work to catalyse and support an environment that encourages and rewards learning and knowledge sharing as a successful part of the outcome of teams' work.

== Rationale ==
Principle 11 of the Manifesto for Agile Software Development, "The best architectures, requirements, and designs emerge from self-organizing teams", makes it clear that knowledge is best created from within teams rather than imposed by an external domain expert. However, there is a clear need to create a shared purpose between teams to create a broader scope of "us" to include fellow teams to avoid a “not invented here” syndrome. If teams have discovered a good way of working, this should be shared with other teams. When it comes to factors such as “how to do end-to-end testing” or “having an aligned architecture”, there needs to be incentive, time and mechanisms in place to incorporate knowledge and practice into the collective team of teams "[[wikipedia:Transactive_memory|Transactive Memory]]".

The traditional management solution for creating alignment is to have special-purpose teams (e.g. an architecture board) which then impose their decisions on the value-creating teams. This strategy has a number of challenges. It undermines the autonomy and empowerment of teams and usually results in lower-quality solutions suffering a lack of feedback and learning loops, which teams then find hard to buy into. Instead, trust value-creating teams to make these decisions themselves but provide mechanisms and time so that teams can collaborate across team boundaries to create the necessary alignment.

=== Related Principles ===
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]
* [[Create clarity of purpose]]
* [[Create a Learning Organisation]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Self-managed Team of Teams]]
* [[Amplify Speed and Quality of Learning Cycles]]
* [[Use the Definition of Done as an enabling constraint]]
* [[Maximise the Scope of Product Increment]]
* [[Support autonomy with clear boundaries]]
* [[Technical leaders as coaches, mentors and community leaders]]
* [[Invest in quality]]
* [[Product solution design is driven from within development teams]] - Contending
* [[Self-managed teams]] - ''Contending''
* [[Maximise Team autonomy]] - ''Contending''
* [[Maximise team empowerment and localised decision making]] - ''Contending''
== Related Patterns ==

* [[wikipedia:Inner_source|Inner Source]] - shared code ownership across teams with open source patterns and culture for ongoing evolution.
* Group Design Workshops - cross-team and cross-discipline workshops to evolve design and evaluate experiment outcomes.
* [https://www.lean.org/lexicon-terms/set-based-concurrent-engineering/ Set-Based Concurrent Engineering] across multiple teams running parallel experiments with collective learning.
* Communities of Practice or Community of Interest

Examples:
* Salesforce’s Virtual Architecture Team (VAT)
* Spotify’s Chapters (and partially guilds, when it comes to sharing knowledge, rather than creating alignment
These are effectively examples of Nonaka and Taceuchi’s Middle-Up-Down management described in The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation (Nonaka & Takeuchi, 1995)

Organise around value streams

2024-05-21T21:15:15Z

Ppugliese:

__NOTOC__
== Description ==
The design of the way product teams are structured should be optimised for the customer and business value streams in preference to designing them around departmental or delivery domain capabilities. This principle is predicated on the assumption that the value streams themselves have first been optimised for customer and business needs.

A value stream provides a container within which teams can self-manage, coordinate and observe the results of their output to ensure that it creates valuable outcomes for their customers and business stakeholders.

== Rationale ==
The design of the product team structure is critical to the success of a team-of-teams, impacting:

* Autonomy - the ability of each team to produce customer value with minimal external dependencies on decisions and artefacts (code, designs, information, etc.).
* Empowerment - the authority to make decisions within team boundaries.
* Clarity of purpose - the team's view and understanding of customer needs, which improves decision-making and drives motivation.
* Product shape and cohesion - how well the products and services fulfil customer needs. See Conway's Law below.
* Speed and quality of learning - the elapsed time taken to understand the impact on the overall product system due to changes.
* Scaled losses and waste - the amount of process overhead required to orchestrate and collaborate across multiple teams.
'''Conway's Law:'''

''Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.''

''Melvin E. Conway''

In summary, Conway's law is an observation that the resulting product will mirror the structure of the teams that produced it. Given that the value streams have been well designed around customers, we design the team structure to match the value stream model.

This strategy enables:

* Working on a value stream provides a shared context and vision, hence improving the motivation and goal orientation of the group of teams.
*Keep complexity under control by allowing teams to broaden their competencies and have end-to-end responsibility. This results in a reduction in dependencies between people and teams and decreased planning complexity.
*Avoiding the alignment of teams to technical platforms or specialist skillsets, which in turn decreases the number of dependencies.
*Reduced dependencies result in reduced planning and coordination complexity, bottlenecks and deadlocks, which in turn dramatically decreases the time required to bring new value to customers.
*A level of [[The Teams' Perspective#Effective Autonomy with Boundaries|bounded autonomy]] that supports all the individuals in the value stream to overcome planning and coordination complexities.

== Related Principles ==
* [[End-to-End Product]]
* [[Avoid Components]]
* [[Align towards business synergies]]
* [[Reduce factors increasing product complexity]]
* [[Minimise unnecessary complexity]]
* [[Maximise team empowerment and localised decision making]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Maximise engagement]]
* [[Maximise Team autonomy]]
* [[Maximise the Scope of Product Increment]]
* [[Collective responsibility for complete product development]]
* [[Support autonomy with clear boundaries]]
* [[Outcome is the primary measure of success]]

Maximise team empowerment and localised decision making

2024-05-21T21:15:01Z

Ppugliese:

__NOTOC__
== Description ==
Put the decision authority where the information is richest and most current. This is important to avoid escalations, delegations and information hand-offs.

Team empowerment and localised decision-making are supported by shaping the teams. They are aligned to business services, features and value streams instead of technical components, services or platforms. In addition, ensure that effective empowerment is supported by boundaries that clearly communicate what the team have authority to decide unilaterally (enabling constraints).

== Rationale ==

Team empowerment is one of the core ideas of agile, and it is a well-understood concept for a single team agile. In a multi-team scenario, it is more challenging to implement this principle because of several organisational aspects:

* Local knowledge of teams might structurally limit the empowerment of a team, i.e. they cannot take decisions alone
* The product's architecture might force teams to work in a small part of the system, hence promoting local optimisation. While decision-making should be localised, they should take into account the overall system complexity
* The organisational structure might impede team empowerment. Both the “vertical” structure, i.e. the management system the team belongs to, and the “horizontal” structure, i.e. some other department mandating company-wide rules. As a leader working in an organisation with such complexities, it will be your job to understand what you can change and what you have to lobby for: this requires long-term strategic thinking, cross-organisation relationship building and patience.
The lack of empowerment might cause:
* The presence of much escalation, delayed decisions pending permission, conflict of competencies and priorities are signs teams are not empowered.
* Teams revert to tribalistic behaviour and focus on their local work rather than being motivated by delivering a whole product.
* Suboptimal decision-making caused by reduced contextual information.

== Related Principles ==
* [[Support autonomy with clear boundaries]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Self-managed teams]]
* [[Organise around value streams]]
* [[Leadership supports rather than drives the work]]
* [[Shared context improves decisions]]
* [[Use the Definition of Done as an enabling constraint]]

Self-managed teams

2024-05-21T21:14:48Z

Ppugliese:

__NOTOC__
== Description ==
When an agile team implements self-management well, all the internal planning, coordination and integration is run within the team. This can be very effective and results in highly productive teams that run themselves with little external effort needed. In order for the team to decide what they work on as well as how, the team should have a guiding mission and clarity of purpose that motivates and guides their work.

== Rationale ==
This is a fundamental principle when implementing any form of agility.

At scale, this is:
# Difficult to implement as the size of the development makes it hard for the people involved to understand the whole system.
# Not attractive because the busyness of the average organisation tends to promote local optimisations to get quick short-term results rather than the global optimisation needed to keep the development sustainable in the long term. This results in:
#* local knowledge silos
#* local technological optimisations
# Fundamental for functioning scaled agility - as the coordination time increases with the number of people and teams involved in the development, so maximising team self-management reduces the coordination overhead.

== Related Principles ==
* [[Maximise team empowerment and localised decision making]]
* [[Maximise Team autonomy]]
* [[Support autonomy with clear boundaries]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Shared context improves decisions]]
* [[Avoid Components]]
* [[Leadership supports rather than drives the work]]
* [[Technical leaders as coaches, mentors and community leaders]]
* [[Product solution design is driven from within development teams]]
* [[Self-managed Team of Teams]]
* [[Use the Definition of Done as an enabling constraint]]
* [[Maximise the Scope of Product Increment]]
* [[Create the environment for people to thrive]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]

Favour teams with maximised cognitive diversity

2024-05-21T21:14:36Z

Ppugliese:

__NOTOC__
== Description ==
Build teams with people who think differently and have different perspectives (i.e., cognitive diversity), regardless of the team’s technical focus.

== Rationale ==
Teams with maximised cognitive diversity outperform other teams, all other things being equal. Scott E. Page, in his book “The Difference”<ref>Page, S. E. (2007). ''The difference: How the power of diversity creates better groups, firms, schools, and societies'' (3. print., and 1. paperback print., with a new preface). Princeton Univ. Press.</ref> , examines the evidence for this.

Teams with a high deviation (cognitive diversity) from the standard perspective are more likely to solve a problem than non-diverse teams, according to an experiment reported in the Harvard Business Review<ref>Lewis, D. G., & Reynolds, Alison. (2017). Teams Solve Problems Faster When They’re More Cognitively Diverse. ''Harward Business Review''.</ref>. A high degree of cognitive diversity could generate accelerated learning and performance in the face of new, uncertain, and complex situations.

In a scaled environment, there is often a tendency to choose team members with a focus on knowledge, skills and experiences and to forget about selecting for broader cognitive diversity.

The following are aspects that can be observed in a Team where cognitive diversity is having an impact on the life of the team:
* More options are offered and discussed before agreeing on a solution
* Multiple alternative perspectives are visible in discussions
* There is an appreciation for different ideas
* Creativity sparks from different ideas being discussed
* Often there is more tolerance to the other’s point of views

== Related Principles: ==
* [[Maximise team empowerment and localised decision making]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Maximise Team autonomy]]
* [[Limit Team Mental Workload]]
* [[Maximise the Scope of Product Increment]]
* [[Product solution design is driven from within development teams]]
* [[Amplify Speed and Quality of Learning Cycles]]
* [[Technical leaders as coaches, mentors and community leaders]]
* [[Invest in quality]]
* [[Create a Learning Organisation]]

== References ==

Architectural cohesion

2024-05-21T21:14:26Z

Ppugliese:

__NOTOC__
== Description ==
When a Value Stream is too large to be managed by a single Product Owner and Team, it should be broken into smaller parts, each of which should be as cohesive as possible whilst still aligning with business synergies.

The Team working in that part needs to be able to:

# Do the work with the least possible amount of technological and functional dependencies on other parts (low coupling)
# Be able to validate their work in a fast and effective way, both within the context of that part of the Value Stream and in the context of the full Composite Value Stream (local and end-to-end testing)
# Work within the combined team Cognitive and Mental Workload

== Rationale ==
Larger products are often divided into smaller parts without parts using high-level logical system diagrams and/or technological interfaces without considering their interdependencies, leading to significant coordination efforts for the resulting sub-products.

It is important, however, to look for splits that enable the team to contribute outcomes that are aligned with the end-to-end business needs of the Value Stream rather than output to be consumed by other teams. Choosing splits aligned to end-to-end value will help avoid experiencing the negative consequences of Conway's Law.

Where it is not practical to align a team’s work directly to outcomes, then examine how to improve the constraints that are impeding this. For example:

* A Product Definition that is not aligned to an end-to-end Value Stream
* Over specialised team skills that can’t cover the breadth of an end-to-end slice through the Value Stream.
* Unnecessary architectural complexity of the end-to-end system.
* Too many different technologies and platforms.
* Lack of development infrastructure supporting the development lifecycle.

== Related Principles ==
* [[End-to-End Product]] ''- Contending''
* [[Align towards business synergies]] ''- Contending''
* [[Avoid Components]]
* [[Create a Learning Organisation]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Favour Teams with broader Solution Accountability]]
* [[Cultivate learning between teams]]
* [[Limit Team Mental Workload]]

Product solution design is driven from within development teams

2024-05-21T21:14:15Z

Ppugliese:

__NOTOC__
==Description==
Push design authority to the teams. Conversely, avoid making design decisions externally and then imposing them on teams.

With "design" we mean every activity related to product development:

* Architecting
* Interaction design
* Development
* Testing
* Security
* Information models
* Deploy in production
* Operations
* ...

==Rationale==
Devolving design authority to the teams will have the following impacts:

* Increase motivation, autonomy and engagement of teams
*Engage and harness the scale and diversity of the combined cognitive capability of the teams
*Increase speed and quality of learning through fast feedback on the consequences of design decisions
A common approach to harmonise design across multiple teams at scale is to centralise the design work. This leads to reduced team autonomy and empowerment and degrades the emergent quality of design in a complex product.

To support a decentralised emergent design process, consider the following:
*A regular cadence of joint inter-team design workshops to evolve the overall design, agree boundaries and recognise interdependent concepts.
*Regularly review and evolve how the local and wider product design supports the Quality Dimensions see [[Invest in quality]].
*Clarify the scope of team empowerment and boundaries within which to operate.

== Related Principles==

*Optimise Speed and Quality of Learning
*[[Invest in quality]]
*[[Technical leaders as coaches, mentors and community leaders]]
*[[Support autonomy with clear boundaries]]
*[[Organise around value streams]]
*[[Favour Teams with broader Solution Accountability]]
*[[Favour Teams with broader Business Domain Competence]]
*[[Maximise the Scope of Product Increment]]
*[[Shared context improves decisions]]
*[[Maximise Team autonomy]]
*[[Limit Team Mental Workload]] - ''Contending''

Collective responsibility for complete product development

2024-05-21T21:14:05Z

Ppugliese:

__NOTOC__
==Description==
Whilst a single team may focus on a subset of the value stream, all teams are collectively responsible for the cohesion and success of the overall product. This applies to both the collective elements that form the product as well as the end-to-end lifecycle from idea to customer outcome.

==Rationale==
As we scale, there is a risk that teams generate elements of the system that are inconsistent with the local optimisation of design decisions. Think of it as trying to assemble a jigsaw puzzle picture using pieces from different puzzles.

Whilst it is important to have a good level of team autonomy, this needs to be balanced by having them understand and contribute to the design of a cohesive whole product. Their unique team perspective should be a valuable input into the product, and their understanding of the wider system should provide essential context for their local work.

It is essential that multiple teams see themselves, not as separate tribes, but instead as a team of teams that win or lose as a whole. So, rather than "Us" and "Them", it should be a wider version of "Us" that includes all value stream teams.

==Related Principles==
*[[Organise around value streams]]
*[[Shared context improves decisions]]
*[[Favour Teams with broader Solution Accountability]]
*[[Favour Teams with broader Business Domain Competence]]
*[[Support autonomy with clear boundaries]]
*[[Product solution design is driven from within development teams]]
*[[Cultivate learning between teams]]
*[[Create clarity of purpose]]
*[[Avoid Components]]
*[[Maximise team empowerment and localised decision making]] - ''Contending''
*[[Maximise Team autonomy]] - ''Contending''
*[[Limit Team Mental Workload]] - ''Contending''

Use the Definition of Done as an enabling constraint

2024-05-21T21:13:54Z

Ppugliese:

__NOTOC__
== Description ==
Where multiple teams have a collective responsibility to increment a Product Increment, they should work to a shared Definition of Done (DoD) to improve transparency, inter-team collaboration, sustained quality and predictability.

* The DoD applies to the Product Increment.
* There may be team-specific DoD elements where there is high diversity between the team's respective delivery technologies. However, ensure that there are appropriate shared DoD elements to sufficiently cover the successful functional and quality aspects of the integrated whole.
* The scope of the Product Increment should provide end-to-end value.

== Rationale ==
There are a number of benefits to using a broader Definition of Done in a multi-team endeavour:

* Widen the perspective of all involved teams to the broader mission and remind them that they win or lose as a collective.
* Increase transparency and quality of their planning to incorporate concerns relevant to the integrated whole Product Increment.
* Reduce the risks and problems caused by poor assumptions.
* Increase the level of trust and understanding between interdependent teams.
*Helps identify interdependent Product backlog Items.
* Using joint workshops to create and evolve the Definition of Done, increases the breadth and depth understanding of the technical challenges.
*Clarifies the scope of team empowerment and boundary within which to self-organise.

== Related Principles ==

* [[Support autonomy with clear boundaries]]
* [[Maximise the Scope of Product Increment]]
* [[Invest in quality]]
* [[Organise around value streams]]
* [[Shared context improves decisions]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Favour Teams with broader Solution Accountability]]
* [[Self-managed teams]]
* [[Maximise Team autonomy]]
* [[Limit Team Mental Workload]] - ''Contending'': a broader Definition of Done could result in too much mental workload for a team. The right balance needs to be found between a broad, enabling Definition of Done and not overloading the teams.

Maximise the Scope of Product Increment

2024-05-21T21:13:43Z

Ppugliese:

__NOTOC__
For each team, the scope of the Product Increment should be as close as is practicable to releasable end-to-end value.

== Description ==
The Scrum Guide describes the Increment as a concrete stepping stone toward the Product Goal, i.e. to realisable value to customers and stakeholders. The Definition of Done provides the guardrails to ensure that the incremental work of the team(s) will be of sufficient quality to release. Where a product is a composite of the output of multiple teams, then they should be working to a collective broadly scoped Increment with a common set of Definition of Done elements. A combined Sprint Review provides a further enabling constraint, encouraging the team to regularly collaborate and integrate their work.

== Rationale ==

* Widen the perspective of all involved teams to the broader mission and remind them that they win or lose as a collective.
* Increase transparency and quality of their planning to incorporate concerns relevant to the integrated whole Product Increment.
* Reduce the risks and problems caused by poor assumptions.
* Provides faster feedback on changes that may impact other teams' work.
* Reduces the technical debt and waste caused by unintegrated work.

== Related Principles ==

* [[Use the Definition of Done as an enabling constraint]]
*[[Organise around value streams]]
*[[Shared context improves decisions]]
*[[Favour Teams with broader Business Domain Competence]]
*[[Favour Teams with broader Solution Accountability]]
*[[Maximise Team autonomy]] - ''Contending''
*[[Limit Team Mental Workload]] - ''Contending''

Avoid Components

2024-05-21T21:13:32Z

Ppugliese:

__NOTOC__
== Description ==
Where a product needs to be scaled across multiple teams and possibly Product Owners, the product should be decomposed in such a way as to retain the ability for teams to deliver slices of end-to-end value autonomously. As far as practical, avoid shaping teams and product ownership around vertical slices through the Value Stream.

The recommended alternative strategy is to [[Align towards business synergies]].

== Rationale ==
Although it might appear to be a neat solution to align teams to technical boundaries and components, the apparent benefits are generally outweighed by many challenges caused by this strategy:

* Reduced team motivation due to a loss of “Purpose” as the work results in outputs rather than valuable outcomes.
*Local optimisation focused on improving the output over the end-to-end outcome.
*Meaningless Definition of Done that is far from releasable quality.
*Increased interdependent work between teams, causing delays, planning overhead and reduced predictability.
*The need for integration of multiple teams' work and subsequent feedback delays
*Translation of business backlog items into constituent technical backlog items with an associated need for technical Product Owners.
*Early commitment to design choices in order to allocate work to teams.
*Delayed feedback from business stakeholders.
*Technical work prioritisation rather than business value prioritisation.

== Related Principles ==
* [[End-to-End Product]]
* [[Align towards business synergies]]
* [[Architectural cohesion]]
* [[Organise around value streams]]
* [[Minimise unnecessary complexity]]
* [[Maximise team empowerment and localised decision making]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Maximise Team autonomy]]
* [[Limit Team Mental Workload]] - C''ontending''

Maximise learning: Craft skills development

2024-05-21T21:13:20Z

Ppugliese:

__NOTOC__
==Description==

Continuous development of Craft skills (business and delivery domain) is an intensional part of all work to collaborate and create value stream outcomes. This is reflected in outcome goals at all levels, along with the necessary support within the environment, time and ways of working.

This principle acknowledges that developing and improving knowledge, capability, and practices is an essential element to sustain an organisation in a complex and fast-changing world.
==Rationale==

Delivery time pressure results in the balance of ''work'' to ''learning'' almost always being in the favour of work - just get it done! Continuously skipping opportunities to develop Craft skills results in demotivated people with out-of-date skills and a less capable organisation. This, in turn, leads to lower quality and quantity of output, which leads to reduced value outcomes. A collateral effect is a higher employee churn rate with the loss of valuable knowledge along with the cost of their replacement.

A deeper focus is put on this principle at scale due to the additional skills and know-how required to implement support for rapid learning cycles across multiple teams - see [[Amplify Speed and Quality of Learning Cycles|Amplify Speed and Quality of Learning Cycles.]]
==Related Principles==
*[[Create the environment for people to thrive]]
*[[Cultivate learning between teams]]
*[[Create a Learning Organisation]]
*[[Invest in quality]]
*[[Favour Teams with broader Business Domain Competence]]
*[[Favour Teams with broader Solution Accountability]]
*[[Maximise Team autonomy]]
*[[Limit Team Mental Workload]] - ''Contending: avoid overloading the team with additional learning load on top of too much delivery work.''
*[[Leadership supports rather than drives the work]]

Teams

2024-05-21T21:13:04Z

Ppugliese:

__NOTOC__
== Introduction ==
The Team is one of the most fundamental concepts in agility: a small group of people working together to achieve a common goal. As the size of the product development increases, we might need to increase the number of people involved, hence having a team that is too big to function effectively. This means that at scale, there will be multiple teams working together. How can they organise themselves so that they retain their agility and are as effective as a group as possible? What about collaboration, knowledge creation and sharing, common and specific processes, ...?

[[The Teams' Perspective]] briefly introduces the topic and explores how Teams can work together in a scaled environment. The principles of this section highlight the many facets of multi-team collaboration.

== Principles ==
* [[Maximise team empowerment and localised decision making]]
* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Self-managed teams]]
* [[Self-managed Team of Teams]]
* [[Maximise Team autonomy]]
* [[Favour teams with maximised cognitive diversity]]
* [[Limit Team Mental Workload]]

Maximise Team autonomy

2024-05-21T21:12:51Z

Ppugliese:

__NOTOC__
== Description ==
In developing large products where many Teams are involved, reducing the amount of coordination needed to ensure Teams' coordination is paramount. It is, therefore, fundamental to find ways to maximise the autonomy of each Team in a Team of Teams.

This can be achieved in several ways:

* The creation of Teams with broader [[Favour Teams with broader Business Domain Competence|problem]] understanding and [[Favour Teams with broader Solution Accountability|solution]] accountability is a crucial step in the right direction: when developing complex products, the competence of being able to work on broader parts of it means reducing the need of coordinating with other Teams
* Agreeing on development standards that are accepted among all Teams reduces the need for ad-hoc processes that are prone to failures and difficult to improve, requiring additional coordination at the process level
* Enabling Teams to validate their work as close as possible to when the work is being done to reduce coordination needed to integrate the contribution of each Team

== Related Principles ==

* [[Self-managed teams]]
* [[Self-managed Team of Teams]]
* [[Maximise team empowerment and localised decision making]]
* [[Favour teams with maximised cognitive diversity]]

Maximise Team autonomy

2024-05-21T21:12:37Z

Ppugliese:

__NOTOC__
== Description ==
In developing large products where many Teams are involved, reducing the amount of coordination needed to ensure Teams' coordination is paramount. It is, therefore, fundamental to find ways to maximise the autonomy of each Team in a Team of Teams.

This can be achieved in several ways:

* The creation of Teams with broader [[Favour Teams with broader Business Domain Competence|problem]] and [[Favour Teams with broader Solution Accountability|solution]] accountability is a crucial step in the right direction: when developing complex products, the competence of being able to work on broader parts of it means reducing the need of coordinating with other Teams
* Agreeing on development standards that are accepted among all Teams reduces the need for ad-hoc processes that are prone to failures and difficult to improve, requiring additional coordination at the process level
* Enabling Teams to validate their work as close as possible to when the work is being done to reduce coordination needed to integrate the contribution of each Team

== Related Principles ==

* [[Self-managed teams]]
* [[Self-managed Team of Teams]]
* [[Maximise team empowerment and localised decision making]]
* [[Favour teams with maximised cognitive diversity]]

Limit Team Mental Workload

2024-05-21T21:12:12Z

Ppugliese:

__NOTOC__
== Description ==
Ensure that all teams are working with a [[Mental Workload]] that they can cope with on a sustained basis. Each team will have a practical limit to the breadth and depth of solution and business domain complexity that they can deal with and maintain a sustained high quality outcome.

Factors to balance when considering the practical mental workload limit for a team:

* Inherent business domain complexity
*Level of Product Owner support
* Number of inter-team collaborative relations and their intensity
* Solution domain skills diversity spectrum required
* Solution platform complexity and ease of use
* Solution architecture complexity
*Team maturity - team cohesion and agility
*Level of Scrum Master support

== Rationale ==
At scale, there is a higher probability that the potential mental workload will exceed a single team's capacity. Team design must therefore balance a practical distribution of mental workload across teams whilst maximising other team design principles.

This results in:
* A high learning curve on much of the team's work leading to extended delivery times and less than optimal quality design decisions
* High stress reducing teams' creativity and motivation levels

== Related Principles ==

* [[Favour Teams with broader Solution Accountability]]
* [[Favour Teams with broader Business Domain Competence]]
* [[Maximise Team autonomy]]
* [[Minimum Viable Product Owners]]
* [[Favour teams with maximised cognitive diversity]]

Favour Teams with broader Business Domain Competence

2024-05-21T21:11:54Z

Ppugliese:

__NOTOC__
== Description ==
At the core of agility, the basic idea is to adapt our development to deliver customer value more effectively and quickly. Therefore, the organisational form should be designed to support this mode of operation.

This means two things:

# Team membership is independent of organisational structure. Teams are shaped around Customer Value rather than within organisational departmental boundaries. A team should contain members from across the organisation, with the combination of skills required to create value for customers. This means the typical structure “per departments”, where every department delivers a part of the product, is not suitable to provide value, and the organisation should instead be organised in Teams that are capable of delivering working functionality for the Customer, where “working” in this context means from the conception through the implementation to the validation and the packaging needed to create a deliverable product
# It is important to create Customer Value for the actual customers for that Product, so the Teams must understand the Business Domain. Many companies instead opt for Teams that deliver to other organisational departments (so-called “internal customers”): this hides the actual customers from parts of the organisation and impedes delivering real customer value (Denning, 14-17). The goal of adequately organising Teams should be to create “Feature Teams”, i.e. Teams that are capable of delivering end-to-end functionality to actual customers, hence reducing drastically the need for coordination among Teams, which is the primary driver of a heavy project management infrastructure and the major cause of slowness in decision making.

Customers don’t buy a part of the product but the whole product. This seems obvious, but it is essential to remember. Teams that depend on other teams will have limited impact and will be slower to deliver value due to handovers and wait-time.

This also connects teams to their impact and purpose, significantly increasing engagement.

In real-world scaled agile implementations, there might be exceptions - e.g. be some teams building reusable components which are orchestrated by other, more customer-centric teams, but most teams should be customer-centric.

== Rationale ==

Probably the biggest challenge in creating an agile product organisation is to move away from the line/department based and towards a customer-centric feature-teams based organisation.

This requires a lot of perseverance from the management team, time and a good amount of self-reflection capability. But without this change, there is no significant benefit in implementing agility. While implementing the agile technical practices might help locally, in large scale product development, the primary source of dysfunctions is in the coordination overhead needed to ensure the whole development organisation is aligned and synchronised.

* Are teams involved in all phases of product development: ideation, discovery, ..., constantly '''interacting with the stakeholders''' to implement a product vision?
* Do teams deliver value for end users or, instead, mostly deliver artefacts to other parts of the organisation for additional processing?
* The teams will often reference “their” customers, end users, … and there will be a noticeable sense of purpose and motivation to achieve results.

== Related Principles ==
* [[Favour Teams with broader Solution Accountability]]
* [[Maximise team empowerment and localised decision making]]
* [[Organise around value streams]]
* [[Favour teams with maximised cognitive diversity]]

Favour Teams with broader Business Domain Competence

2024-05-21T21:11:06Z

Ppugliese: Ppugliese moved page Favour Teams with broader Business Domain Accountability to Favour Teams with broader Business Domain Competence without leaving a redirect

__NOTOC__
== Description ==
At the core of agility, the basic idea is to adapt our development to deliver customer value more effectively and quickly. Therefore, the organisational form should be designed to support this mode of operation.

This means two things:

# Team membership is independent of organisational structure. Teams are shaped around Customer Value rather than within organisational departmental boundaries. A team should contain members from across the organisation, with the combination of skills required to create value for customers. This means the typical structure “per departments”, where every department delivers a part of the product, is not suitable to provide value, and the organisation should instead be organised in Teams that are capable of delivering working functionality for the Customer, where “working” in this context means from the conception through the implementation to the validation and the packaging needed to create a deliverable product
# It is important to create Customer Value for the actual customers for that Product, so the Teams must understand the Business Domain and be empowered to take decisions in that domain. Many companies instead opt for Teams that deliver to other organisational departments (so-called “internal customers”): this hides the actual customers from parts of the organisation and impedes delivering real customer value (Denning, 14-17). The goal of adequately organising Teams should be to create “Feature Teams”, i.e. Teams that are capable of delivering end-to-end functionality to actual customers, hence reducing drastically the need for coordination among Teams, which is the primary driver of a heavy project management infrastructure and the major cause of slowness in decision making.

Customers don’t buy a part of the product but the whole product. This seems obvious, but it is essential to remember. Teams that depend on other teams will have limited impact and will be slower to deliver value due to handovers and wait-time.

This also connects teams to their impact and purpose, significantly increasing engagement.

In real-world scaled agile implementations, there might be exceptions - e.g. be some teams building reusable components which are orchestrated by other, more customer-centric teams, but most teams should be customer-centric.

== Rationale ==

Probably the biggest challenge in creating an agile product organisation is to move away from the line/department based and towards a customer-centric feature-teams based organisation.

This requires a lot of perseverance from the management team, time and a good amount of self-reflection capability. But without this change, there is no significant benefit in implementing agility. While implementing the agile technical practices might help locally, in large scale product development, the primary source of dysfunctions is in the coordination overhead needed to ensure the whole development organisation is aligned and synchronised.

* Are teams involved in all phases of product development: ideation, discovery, ..., constantly '''interacting with the stakeholders''' to implement a product vision?
* Do teams deliver value for end users or, instead, mostly deliver artefacts to other parts of the organisation for additional processing?
* The teams will often reference “their” customers, end users, … and there will be a noticeable sense of purpose and motivation to achieve results.

== Related Principles ==
* [[Favour Teams with broader Solution Accountability]]
* [[Maximise team empowerment and localised decision making]]
* [[Organise around value streams]]
* [[Favour teams with maximised cognitive diversity]]

File:SA Principles Continuum-2.png

2024-02-20T11:02:22Z

Ppugliese: Ppugliese uploaded a new version of File:SA Principles Continuum-2.png

The Leadership Perspective

2024-02-01T10:41:33Z

Ppugliese:

__NOTOC__
= Agile Leadership at Scale =
The genesis of the Agile movement emerged from the challenge of trying to solve problems in the complex world of software development. Today's complex, fast-moving business environment requires a different leadership style that incorporates many of the ideas from Lean and Agile.

It is possible for a few Agile teams to “fly under the radar” and use their agility to improve their performance within an unfavourable, less than agile organisational context. However, this individual team performance gain will have a limited impact on customer and business value generation and will ”fail to scale” unless there is wider, end-to-end change. Transforming to an Agile organisation that can successfully scale value generation improvements requires systemic and cultural change that requires the sustained support of leaders.

Here's a summary of some of leadership's key responsibilities and concepts involved in creating an agile organisation at any scale:

== The Context for Agile Leadership ==
Organisations are challenged to stay relevant and competitive in today's [https://www.vuca-world.org/roles-of-nanus-and-bennis/ VUCA] (Volatile, Uncertain, Complex, Ambiguous) world. Outstanding leadership effectively harnesses an organisation's collective capabilities into a resilient, responsive, adaptive and ever-improving entity - an Agile organisation - that will be more likely to survive and thrive.

== Focus on People ==
Agile leaders perceive their organisations as intricate human systems, acknowledging the complexity of their behaviour, interactions, and development, necessitating a systemic approach.

Agile leadership focuses on growing and nurturing the environment for people to thrive and less on traditional ideas of people management. A fertile environment is one that includes high levels of [https://amycedmondson.com/psychological-safety/ Psychological Safety] that encourages experimentation, learning and growth and provides aligned autonomy of action and engagement through clear and meaningful purpose and involved decision-making.

== Apply Systems Thinking ==
Agile is broader than delivery teams. Agile incorporates high-function teams as the atomic entity of value creation, but its values and principles extend to the whole organisation as this provides much of the context within which teams operate. The result is that regardless of size, almost any serious Agile endeavour involves Agile at Scale. This will require leadership support for the systemic improvement of the entire system of value creation to be successful and sustained.

== Build Leadership Capability ==
Leadership is not a role but a capability that should exist and be nurtured throughout the organisation, from team members to CEO. Peter Drucker famously said that the role of leadership is to create an alignment of strengths (quote: https://www.azquotes.com/quote/872896).

In modern knowledge-based organisations, this alignment comes from what David Marquet (ref Turn the Ship Around) calls Leader – Leader relationship, to differentiate from the traditional Leader – Follower approach.

Put another way, it is a core responsibility of leadership to promote participation and collaboration while growing more people capable of leadership to establish the backbone for an empowered and engaged organisation.

== Own Your Own Approach ==
Steve Denning has [https://www.forbes.com/sites/stevedenning/2019/03/17/how-mapping-the-agile-transformation-journey-points-the-way-to-continuous-innovation/?sh=712562e04b24 researched] many organisations that have scaled Agile; he has published findings across organisations that highlight the leadership required to support and sustain a successful Agile journey. As well as the observation that longterm leadership support was required for the Agile journey, another key finding was that the approach was homegrown and emerged organically.

Simply copying and pasting in “[https://blogs.ripple-rock.com/colinbird/2023/12/05/dont-be-a-best-practice-sheep/ Best Practice]” from other organisations or consultancies 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.

(Principle: Own your own approach)

== Catalyst for Change ==
Agility is not achieved through a transactional transformation from the old way of working to a new way! Instead, it is a long-term commitment to improve the value realised by the organisation. A key leadership responsibility is to help the organisation build into its cultural DNA the imperative and capability to evolve perpetually.

Some changes will be challenging and will require the courage and support of leadership to accomplish the structural changes needed to reduce complexity. The average organisation is the result of cumulative changes that have been applied over years, often using a scientific reductionistic approach implemented through a hierarchical ladder (ref: https://explorable.com/scientific-reductionism), often resulting in short-sighted local optimisations.

However, optimising for outcome generation requires a holistic approach to continuously adapt the value streams to the ever-changing challenges of the VUCA world. Modern leadership has the incredibly important challenge of working together at all levels to adapt the organisational structures beyond, and often against, current locally optimised silo-thinking. This work requires a long-term strategic vision, and, at the same time, it’s an emergent evolutionary process that requires broad participation, learning and commitment.

= Aspects of Agile Leadership =

== Leadership Behaviours ==
Great leaders can inspire, orient, give trust and respect, offer purpose, invite participation, and promote growth. At all levels, the leaders of an organisation are role models for how leadership is implemented in an organisation. Employees' perception of their leaders is a critical factor in how they will choose to act in the company. Leaders positively “infect” the organisation with their values because they live them, not because they state them!

On the contrary, bad leaders criticise, are selfish, use people, don’t trust others, and work for their own interests. This creates a corrupted environment where the company goals are subordinated to those of individuals, severely reducing cohesion and effectiveness.

In his book, Leadership is Language, David Marquet neatly articulates the impact and responsibility of leaders for the organisation's culture:

[[File:Leaders Shape the Environment - ELSE.png|frameless|458x458px]]

An Agile Leader strives to understand the impact of the current environment on behaviours and catalyse and support the changes required to promote positive changes in behaviours. Examples of environmental factors include leadership behaviours, policies, Psychological Safety, purpose, performance management, procedures, facilities etc.

The very culture of a company, i.e. the system of beliefs and values espoused throughout the organisation, is shaped to a large extent by the actions of leaders:

With their visibility and connectedness, leaders have significant systemic importance in spreading and shaping the system of beliefs and values espoused throughout the organisation. By doing this, they actively cultivate the company culture.

Leaders can catalyse a meaningful purpose by being role models (Principle: Create meaningful purpose). We deliberately use the word “catalyse” here because, to empower our human capital, leaders should avoid “giving orders” but instead support the emergence of a collaboratively created shared vision.

In particular, with their behaviours, leaders can support the creation of a culture of change and adaptiveness by showing openness to it and acting as catalysts for change (Principle: Catalyst for change) while, in parallel, maintaining an environment where people feel psychologically safe.

For more information on the importance of being a role model, see these articles as an entry point into the research on the subject:

https://people-equation.com/leaders-as-role-models-research/

https://www.sciencedirect.com/science/article/pii/S0167268118302063?via%3Dihub

== Human Aspects ==
Both Lean and Agile are people-centred approaches. Regardless of how smart our processes and systems are, we will fail if we do not engage and harness the capabilities of our people. The current potential of an organisation is a function of its past recruitment and growth of its people and the environment that supports them. Continuous investment and attention to developing people is the key to the sustained success of any organisation.

== Autonomy ==
We define Autonomy as the ability to effectively function with a high degree of independence with limited reliance on outside decision authority or services.

Leadership seek to create an environment that provides a high level of team autonomy to provide the following benefits:

* Motivated people
* Engaged people
* Low latency decision-making
* Responsive organisation

However, for autonomy to be effective, it is essential:

# That there is good clarity of meaningful purpose to guide and align decision-making and actions in a cohesive and productive direction. Additionally, the purpose should be expressed as outcomes rather than execution instructions - the “what” and the “why” rather than the “how”.
# Those responsible for the work are also accountable for and have the authority to make decisions and take actions within a set of agreed constraints (outcome, quality, tactics, etc...).
# Accountability is balanced by the “safety” to fail, learn and improve.
# The level of autonomy and authority provided is compatible with the capability to execute in combination with leadership coaching and support.
# To grow the capability to enable greater autonomy and authority to be devolved - see Creating a Learning Organisation below.

=== Alignment and Autonomy ===
To answer the challenge of engaging many minds in a cohesive, collaborative and effective manner, we must ensure clarity of shared and meaningful purpose to provide essential alignment. A meaningful purpose is an important aspect of motivation. It is also necessary for teams to function with good autonomy - another aspect of motivation (see Bounded Autonomy).

[[File:Autonomy with Alignment - ELSE.png|frameless|931x931px]]

Leaders “Catalyse purpose” rather than “Set purpose”. This might seem like a subtle distinction, but nonetheless, it is vital. In many organisations, senior leadership sets the purpose and pushes it down the organisation. However, this approach has shortcomings:

* A lack of understanding, buy-in and engagement from the people delivering the strategy.
* The strategy formulation needed to achieve impactful product and service delivery will suffer due to missing more detailed and diverse perspectives, data and feedback.
* High-level goals will require decomposition into more detail as they move down the layers. A cascade hand-off process leads to a loss of tacit information in transit and a “Chinese whisper” effect reducing the quality and alignment, resulting in less meaningful and valuable work sub-components.

There are many techniques and formats that can be used to express purpose and track progress, including OKRs. Regardless of the method chosen, the critical factor is how the objectives are created, communicated and measured. To catalyse rather than "set" purpose, leaders facilitate an iterative and collaborative process with two-way feedback loops. The diagram below illustrates a Hoshin Kanri approach (also known as Strategy Deployment) that, if utilised correctly, will support the emergence of a well-formulated and aligned purpose:

[[File:Hoshin Kanri - ELSE.png|frameless|934x934px]]

The diagram contains 4 example levels of detail; however, specific organisations and contexts could require more or less. What is essential is how collaboration and consensus-building work through the layers. There are many different patterns and interpretations that can be applied within this model. However, here are some core guiding principles:

* Collaborative conversations and understanding-building are more critical than documented expressions of purpose.
* Formulation of purpose at each layer is in collaboration with adjacent layers.
* Align to value streams and promote end-to-end cross-functional collaboration.
* Agree on appropriate time horizons at each layer.
* It is an iterative process with regular refinement and learning. Regular refresh cadences should be established, but there should also be iteration within these cadences - i.e. ideas should be honed through rapid iterative feedback loops.
* The outcome should result in objectives at the lowest level being cohesive with, and traceable back to, the highest level mission.
* Just Enough Detail - keep it light and outcome-focused to avoid over-analysis waste and protect empowerment to decide how the objectives are met.
* Leaders seek to elicit diverse ideas and avoid anchoring group input within the constraints of their own thinking.
* This is not a cascade model!

=== Balance Autonomy ===
Simply handing out the freedom and authority to be autonomous with instructions to self-manage and do great work is not enough. It will more than likely lead to chaos!

Having established alignment and [[Shared context improves decisions|Shared Context]] through the [[Create clarity of purpose|Creation of Clarity of Purpose]] (see Aligned Autonomy), we balance autonomy by:

* Ensuring that the level of responsibility applied is proportionate to the capabilities of the people. The level of capability will vary by group and over time, so will need to be context-specific and evolutionary.
* Supporting as needed to resolve impediments, coach, grow capability and adjust the level of responsibility as required.
* Bound Autonomy (see Effective Autonomy with Boundaries in the [[The Teams' Perspective|Team Perspective]]) to ensure that people know what they have the authority to autonomously decide versus what may need outside consultation.

The aim of balancing responsibility and capability is to provide a challenging and enabling environment without overwhelming individuals. Leadership ensures that learning is incorporated into the ways-of-working to grow capabilities and enable careful adjustment of responsibilities in alignment with growth.

== Trust and Safety ==
In this Leadership Perspective, we discuss many facets of Agile Leadership. Ideas such as devolving autonomy, accountability and authority, leading and supporting change, and creating a Learning Organisation will stall or fail unless there is a strong basis of trust and safety.

Leaders have a duty to build an environment that broadly (i.e. beyond senior leaders) promotes and supports:

* Challenge the status quo - the ability to honestly and critically analyse the current system of work with a mindset to discover, drill down and fundamentally address root causes of challenges to value creation.
* Process Innovation - engage people who live the process to contribute their deep knowledge to shape and run change experiments with new or modified processes, systems, tools, policies, etc.
* Product Innovation - innovating, by definition, means taking different and divergent approaches with an inherently higher risk of failure. If trying and failing are career-limiting, people will disengage and stop trying anything new or perceived as risky.
* Accountability and autonomy - without the trust that it is safe to take accountability and autonomous decision-making, people will switch to a passive mode, disengage and wait for permission or to be told what to do.
* Learning - the ability to safely admit that we don’t know something opens up the opportunity to learn as well as potentially unblock progress or avoid failure and rework.
* Critical failure avoidance - through the safety and trust that constructively raising early visibility of potential issues will not be penalised.

[https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html Project Aristotle], a multi-year study of team effectiveness at Google, concluded that Psychological Safety was the number one determining factor differentiating the highest-performing teams. The study found that how the team collaborated and functioned as a unit was far more important than the capabilities of individual team members.

Five key aspects were identified:

# Psychological Safety to take risks, speaking up, supported by team members
# Dependability - they can count on their team members
# Structure and Clarity - clear direction and goals
# Meaning - work is personally meaningful
# Impact - the work matters and will deliver benefit

Psychological Safety was the key enabler for the four other aspects to prove valuable.

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. Reducing the “fear of failure” will enable experiments to safely explore innovative solutions and identify and apply learnings.

That said, Psychological Safety is not about being nice or avoiding accountability. Instead, it is an environment where it is expected and safe to hold difficult conversations and be accountable for high-performance delivery towards target outcomes. Psychological Safety does not mean that accountability is compromised. Instead, they are, in fact, two different dimensions - see how they relate in the graphic below.

[[File:Psychological Safety - ELSE.png|frameless|1002x1002px]]

== Create a Learning Organisation ==
The current potential of an organisation is founded on the collective capabilities of its people. Today’s knowledge and capabilities are a function of previous learning and experiences. To ensure sustained success, intentional, ongoing investment and attention to developing people are required.

Below we discuss some strategies that will help build a Learning Organisation.

=== Create the Space to Learn ===
Create time to learn by building in and protecting time in day-to-day work to avoid the state of constant busyness denying the opportunities to learn and develop skills. Encourage and value the inclusion of learning outcomes in addition to delivery outcomes (e.g. include a learning outcome within a Sprint Goal).

Working and collaborating closely in small groups helps create an environment where learning is a natural byproduct of getting the work done. Extreme Programming introduced the concept of Pair Programming, where two developers work with a single keyboard – pilot and co-pilot. Although not the primary intention, one of the collateral benefits is a safe learning environment. The broad concept of pairing can be adapted and applied to many types of knowledge work. In scaled environments, it can even be used with people from different teams for specific cross-team challenges. One of the reasons this strategy is used less than it should be is the perceived loss of productivity and efficiency. Counterintuitively, long-term value creation will likely increase for many reasons, including the learning benefit.

=== Recognise the Value of Learning ===
The valuable outcomes from the work people perform include both what they deliver (products & services) and what they learn! Of course, a great environment is required to provide the platform to turn potential into realised value.

Personal objective setting and performance sessions should include learning and coaching objectives where appropriate. Where a person has deep subject matter expertise, they should be encouraged and recognised for raising the skills of others as well as contributing to delivery outcomes. Conversely, the same person may have potential growth areas that can be encouraged with suitable objectives and recognition.

=== Leaders Develop Themselves ===
Leaders lead by example, making the time for their own learning and developing their leadership skills. Additionally, they seek constructive feedback with an open mind to reflect and target improvements in weaker areas. These practices have the following benefits in addition to the obvious advantage of greater leadership capability:

* Demonstrates humility and vulnerability by acknowledging that they are never the finished article and have things to learn.
* Peer coaching helps practice and improve coaching skills as well as accelerate leadership skills development.
* Reinforces the learning culture and perception of the value of learning.

=== Safety to Learn ===
It should be recognised that in complex domains, failure is highly likely. It is also true that in these domains, there is a great deal of learning potential from things that don’t work as intended. Leadership creates the safety to attempt challenging outcomes and support the learning from “failure”. Another way of looking at this is to consider and lower the current level of bravery required to attempt something difficult and learn from the result. Leaders frame the work to include the appropriate expectation on the predictability or otherwise of the outcome. This is followed by constructive responses to unexpected results and guide inspection with curiosity and a genuine interest to maximise learning.

Admitting that we don’t know something is a vital start to initiate the opportunity to learn. But what will my colleagues or boss think if I don’t know something I suspect they think I am paid to know? To help build a learning-friendly environment, leaders lead by example, demonstrate vulnerability and a Growth Mindset, admit where they don’t know something, and model desired behaviour by asking questions.

=== Leaders Coach and Support ===
Leaders act as coaches and mentors to grow and support people in addition to formal training as part of personal learning and development plans.

Leaders adjust the level of autonomy and authority based on capability. Ideally, the balance should achieve a level of challenge that is inspiring and leads to growth but does not overstress.

[[File:Competence and Control - ELSE -2.png|frameless|823x823px]]

For more information on the ideas of Tuning Control to Competence, and Clarity, see David Marquet's [https://www.youtube.com/watch?v=J5jQsrMousE video]

== Support Change ==
[[The Change Perspective]] discusses why the ability for continuous improvement should be a core capability and cultural mindset and presents an evolutionary change model as a practical approach for achieving this.

Leadership has a vital role in shaping and supporting change:

* Catalyse a clarity of purpose to provide context and motivation for change.
* Create the safety necessary to challenge the status quo and experiment with new ideas.
* Provide support where experiments inevitably lead to parts of the organisations at different states of change.
* Provide the authority to make fundamental changes across organisational boundaries and politics.
* Support a systems thinking approach to optimise end-to-end value streams and avoid local optimisation pitfalls.
* Lead by example, for example, demonstrating an openness to question assumptions, especially your own.
* Reinforce the concept that this is not a change initiative but rather a long-term commitment to continuously seek perfection in the way the organisation creates value.
* Create the time for change. Ensure time is built into busy schedules to understand the current context and create and evaluate hypotheses. This includes key stakeholders making the time to engage in change activities.

We recommend organisations identify Value Streams that can be used to align teams to deliver value towards strategic business objectives (a greater good). Applying an incremental, evolutionary change approach to identified value streams [ref link] . [link to change perspective].

This approach will lead to parts of organisations at different states of change, with some departments operating more bureaucratically alongside Agile Value Streams. We have observed this causes tension in areas such as project budgeting, scope/time/cost project-based approach, line management, departmental structures and functional departments trying to work with Agile teams. Leadership is required to support and work through these challenges.

Most sizeable organisations do not change as a whole entity; instead, parts evolve at different speeds and often in different directions. We recommend that this phenomenon be embraced and formalised, using go-ELSE principles to guide evolutionary change, supported and protected by recognised boundaries, with the authority to challenge existing procedures where they impede the effectiveness of Agile Value Streams.

== Enable Effective Value Delivery ==
Following the scaling principles should create organisations that are aligned to and are able to observe the impact of their value creation. Leadership should ensure that “this line of sight” is available to any of the teams working within that value stream and the direction of purpose is clear for those working towards it.

Progress towards goals should be visible and widely available, and the measures used should be meaningful, actionable and easily understood. Principle [<nowiki/>[[Outcome is the primary measure of success|Outcome is the primary measure of progress]]].

The more often output can be provided for feedback, the more frequently teams can learn from that feedback and act on the information. The wider the audience and the closer the product is to a released version, the more reliable the data.

Earlier product iteration feedback from smaller audiences will require greater judgment. Create an environment with structures that enable effective decision-making by the people with the most knowledge of the work.

Leadership should ensure they leave biases aside and can adapt when new information challenges previously held beliefs. Engaging in dialogue based on data insights, providing guidance and clarity of judgement to continue or change the direction of experimentation for the benefit of the wider organisation.

Leadership should ensure that they embrace this discovery and outcome-led approach, supporting teams using product iterations to sense and respond to feedback in order to enable effective value creation and outcome realisation. Embracing the idea that even the seemingly most certain requirements should be treated as assumptions that require validation.

Throughout this process, leadership should encourage and support alignment across teams, enabling cross-team collaboration and effective dialogue and making the best decisions based on the information available rather than based on opinions and positions in the hierarchy.

= Leadership Perspective Summary =
Agile Leadership at Scale highlights the necessity for a leadership style that is adaptable and responsive to the complexities of the modern business world. Central to this approach is the focus on fostering resilient and agile organisations capable of thriving in an environment characterised by volatility, uncertainty, complexity, and ambiguity.

Agile leadership strongly emphasises understanding organisations as dynamic human systems and creating environments encouraging psychological safety, learning, and autonomy.

There is an emphasis on systems thinking, integrating Agile principles throughout the organisation, and developing leadership as a widespread capability across all levels. Leaders are encouraged to tailor Agile practices to their unique organisational contexts and act as catalysts for systemic and cultural change.

The human element is pivotal, with a balance between autonomy and capability and the establishment of trust and safety being fundamental. Creating a learning organisation is crucial, where leaders support and coach team members, fostering continuous learning and adaptation.

In driving change, leaders need to catalyse a clear purpose, encourage experimentation, and align organisational changes with business objectives.

Overall, Agile leadership at Scale advocates for an adaptable culture, focused on continuous learning and centred around people, where leaders guide and facilitate rather than control, ensuring effective execution and ongoing organisational improvement.

MediaWiki:Sidebar

2024-01-30T12:20:12Z

Ppugliese:

Glossary

2024-01-30T12:03:49Z

Ppugliese:

__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]]

Glossary

2024-01-30T12:03:31Z

Ppugliese:

__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]]
*[[Bounded Autonomy|<nowiki>[[The Teams' Perspective#Effective Autonomy with Boundaries|B</nowiki>'''ounded Autonomy'''<nowiki>]]</nowiki>]]
*[[Team of Teams]]
*[[Team Autonomy]]
*[[Cognitive Diversity]]
*[[Product Increment]]
*[[Learning Cycles]]

Create a Learning Organisation

2024-01-30T11:58:22Z

Ppugliese: /* Rationale */

__NOTOC__
== Description ==
Agile leaders perceive their organisations as intricate human systems, acknowledging the complexity of their behaviour, interactions and development, necessitating a systemic approach.

A systematic approach has been referred to by [[wikipedia:Learning_organization|Peter Senge as a Learning Organisation]]. Leaders should focus their efforts on creating an organisation where individuals can work effectively together when responding to market complexities. Individuals will need the safety and space to explore the creation of a Learning Organisation. They will need to explore and challenge their own assumptions and views on the world to participate effectively in collaborative dialogue, towards a purpose that leaders ensure everyone engages in and understands.

== Rationale ==
Peter Senge has highlighted five disciplines that enable us to create Learning Organisations, these disciplines should not be developed independently, but as an ensemble.

He has captured this in his work [[wikipedia:The_Fifth_Discipline|The Fifth Discipline]].

'''1. [[Systems Thinking]]'''

Thinking of organisations as whole systems that are bound by invisible fabrics of interrelated actions. System Thinking is a conceptual framework, a body of knowledge and tools to make full patterns clearer and help us see how to change them effectively. Systems Thinking is seen as the fifth discipline, as it integrates the following four disciples together.

'''2. [[Mental Models]]'''

Challenge deeply ingrained assumptions that we hold, these are formed from our memories & experiences and influence how we understand the world and take action. Very often, we are not consciously aware of our mental models or the effects they have on our behaviour. In order to work effectively with others, we must be prepared to re-frame our own mental models.

Re-framing these models can be hugely disruptive for people, finding out a belief they held no longer serves them. As this can be a painful experience, we are well-versed in creating defensive routines that insulate our mental models from examination.

'''3. [[Personal Mastery]]'''

Individuals are committed to their own lifelong learning, develop patience, treat each other with respect and see things objectively. Personal mastery enables individuals to effectively take part in team dialogue, challenge their own mental models and commit to a shared vision.

'''4. [[Create clarity of purpose|Shared Vision]]'''

Unearthing shared pictures of the future that foster genuine commitment and enrolment rather than compliance.

'''5. Team Learning'''

Create an environment for genuine dialogue, individuals should suspend their assumptions in order to do genuine thinking together.

“To the Greeks dia-logos meant a free-flowing of meaning through a group, allowing the group to discover insights not attainable individually.” “The discipline of dialogue also involves learning how to recognize the patterns of interaction in teams that undermine learning. The patterns of defensiveness are often deeply ingrained in how a team operates. If unrecognized, they undermine learning. If recognized and surfaced creatively, they can accelerate learning.”

== Related Principles ==

* [[Foster a high trust environment]]
* [[Are lean practitioners]]
* [[Create clarity of purpose]]
* [[Create the environment for people to thrive]]
* [[Maximise engagement]]
* [[Cultivate learning between teams]]
* [[Amplify Speed and Quality of Learning Cycles]]

Create a Learning Organisation

2024-01-30T11:54:52Z

Ppugliese: /* Rationale */

__NOTOC__
== Description ==
Agile leaders perceive their organisations as intricate human systems, acknowledging the complexity of their behaviour, interactions and development, necessitating a systemic approach.

A systematic approach has been referred to by [[wikipedia:Learning_organization|Peter Senge as a Learning Organisation]]. Leaders should focus their efforts on creating an organisation where individuals can work effectively together when responding to market complexities. Individuals will need the safety and space to explore the creation of a Learning Organisation. They will need to explore and challenge their own assumptions and views on the world to participate effectively in collaborative dialogue, towards a purpose that leaders ensure everyone engages in and understands.

== Rationale ==
Peter Senge has highlighted five disciplines that enable us to create Learning Organisations, these disciplines should not be developed independently, but as an ensemble.

He has captured this in his work [[wikipedia:The_Fifth_Discipline|The Fifth Discipline]].

'''1. [[Systems Thinking]]'''

Thinking of organisations as whole systems that are bound by invisible fabrics of interrelated actions. System Thinking is a conceptual framework, a body of knowledge and tools to make full patterns clearer and help us see how to change them effectively. Systems Thinking is seen as the fifth discipline, as it integrates the following four disciples together.

'''2. [[Mental Models]]'''

Challenge deeply ingrained assumptions that we hold, these are formed from our memories & experiences and influence how we understand the world and take action. Very often, we are not consciously aware of our mental models or the effects they have on our behaviour. In order to work effectively with others, we must be prepared to re-frame our own mental models.

Re-framing these models can be hugely disruptive for people, finding out a belief they held no longer serves them. As this can be a painful experience, we are well-versed in creating defensive routines that insulate our mental models from examination.

'''3. [[Personal Mastery]]'''

Individuals are committed to their own lifelong learning, develop patience, treat each other with respect and see things objectively. Personal mastery enables individuals to effectively take part in team dialogue, challenge their own mental models and commit to a shared vision.

'''4. [[Create clarity of purpose|Shared Vision]]'''

Unearthing shared pictures of the future that foster genuine commitment and enrolment rather than compliance.

'''5. [[Team Learning]]'''

Create an environment for genuine dialogue, individuals should suspend their assumptions in order to do genuine thinking together.

“To the Greeks dia-logos meant a free-flowing of meaning through a group, allowing the group to discover insights not attainable individually.” “The discipline of dialogue also involves learning how to recognize the patterns of interaction in teams that undermine learning. The patterns of defensiveness are often deeply ingrained in how a team operates. If unrecognized, they undermine learning. If recognized and surfaced creatively, they can accelerate learning.”

== Related Principles ==

* [[Foster a high trust environment]]
* [[Are lean practitioners]]
* [[Create clarity of purpose]]
* [[Create the environment for people to thrive]]
* [[Maximise engagement]]
* [[Cultivate learning between teams]]
* [[Amplify Speed and Quality of Learning Cycles]]

Personal Mastery

2024-01-30T11:53:13Z

Ppugliese: Created page with "Individuals are committed to their own lifelong learning, developing patience, treating each other with respect, and seeing things objectively. Personal mastery enables individuals to effectively take part in team dialogue, challenge their own mental models and commit to a shared vision. == Related Practices == * 1 to 1 coaching ([https://www.performanceconsultants.com/grow-model GROW model], Co-Active Coaching) * [https://www.youtube.com/watch?v=Ch9j0d1VOuE Edge Model..."

Individuals are committed to their own lifelong learning, developing patience, treating each other with respect, and seeing things objectively. Personal mastery enables individuals to effectively take part in team dialogue, challenge their own mental models and commit to a shared vision.

== Related Practices ==

* 1 to 1 coaching ([https://www.performanceconsultants.com/grow-model GROW model], Co-Active Coaching)
* [https://www.youtube.com/watch?v=Ch9j0d1VOuE Edge Model for change],
* [https://www.gottman.com/blog/the-four-horsemen-recognizing-criticism-contempt-defensiveness-and-stonewalling/ John & Julie Gottman - 4 relationship toxins]
* Threat based Neuroscience:
** [https://www.psychologytoday.com/sites/default/files/attachments/31881/managingwbraininmind.pdf David Rock SCARF model]
** [https://partneringresources.com/wp-content/uploads/SCARF-Final.pdf How to prevent a threat response]
* [https://www.viacharacter.org/ VIA Strengths finder]: lots of research shows that playing to our strengths improves performance - this is one of the bases of Martin Seligman's positive Psychology
* [https://www.gallup.com/cliftonstrengths/en/252137/home.aspx?utm_source=google&utm_medium=cpc&utm_campaign=uk_branded_cs_ecom&utm_term=gallup%20strengths%20finder&gclid=Cj0KCQiAq7COBhC2ARIsANsPATGDd5qmEFDdS7BUVMm5Y6sMRNFuh5ZiqubVFCGSxlx0ueC91RGRWeQaAn8fEALw_wcB Gallup Clifton Strengths Finder]

Mental Models

2024-01-30T11:50:51Z

Ppugliese:

Challenge deeply ingrained assumptions that we hold, these are formed from our memories & experience they influence how we understand the world and how we take action. Very often, we are not consciously aware of our mental models or the effects they have on our behaviour. In order to work effectively with others we must be prepared to re-frame our own mental models.

Re-framing these models can be hugely disruptive for people, finding out a belief they held no longer serves them. As this can be a painful experience we are well versed in creating defensive routines that insulate our mental models from examination.

== References ==
[https://i2insights.org/2019/05/28/collaboration-groan-zone/ Kaner : Divergent and Convergent Thinking]

[https://www.youtube.com/watch?v=Ch9j0d1VOuE Edge Model for change],

[https://www.gottman.com/blog/the-four-horsemen-recognizing-criticism-contempt-defensiveness-and-stonewalling/ John & Julie Gottman - 4 relationship toxins]

Threat based Neuroscience:
* [https://www.psychologytoday.com/sites/default/files/attachments/31881/managingwbraininmind.pdf David Rock SCARF model]
* [https://partneringresources.com/wp-content/uploads/SCARF-Final.pdf How to prevent a threat response]

Mental Models

2024-01-30T11:50:39Z

Ppugliese:

Challenge deeply ingrained assumptions that we hold, these are formed from our memories & experience they influence how we understand the world and how we take action. Very often, we are not consciously aware of our mental models or the effects they have on our behaviour. In order to work effectively with others we must be prepared to re-frame our own mental models.

Re-framing these models can be hugely disruptive for people, finding out a belief they held no longer serves them. As this can be a painful experience we are well versed in creating defensive routines that insulate our mental models from examination.

== References ==
[https://i2insights.org/2019/05/28/collaboration-groan-zone/ Kaner : Divergent and Convergent Thinking]

[https://www.youtube.com/watch?v=Ch9j0d1VOuE Edge Model for change],

[https://www.gottman.com/blog/the-four-horsemen-recognizing-criticism-contempt-defensiveness-and-stonewalling/ John & Julie Gottman - 4 relationship toxins]

Threat based Neuroscience:
- [https://www.psychologytoday.com/sites/default/files/attachments/31881/managingwbraininmind.pdf David Rock SCARF model]
- [https://partneringresources.com/wp-content/uploads/SCARF-Final.pdf How to prevent a threat response]

Mental Models

2024-01-30T11:50:18Z

Ppugliese: Created page with "Challenge deeply ingrained assumptions that we hold, these are formed from our memories & experience they influence how we understand the world and how we take action. Very often, we are not consciously aware of our mental models or the effects they have on our behaviour. In order to work effectively with others we must be prepared to re-frame our own mental models. Re-framing these models can be hugely disruptive for people, finding out a belief they held no longer se..."

Challenge deeply ingrained assumptions that we hold, these are formed from our memories & experience they influence how we understand the world and how we take action. Very often, we are not consciously aware of our mental models or the effects they have on our behaviour. In order to work effectively with others we must be prepared to re-frame our own mental models.

Re-framing these models can be hugely disruptive for people, finding out a belief they held no longer serves them. As this can be a painful experience we are well versed in creating defensive routines that insulate our mental models from examination.

== References ==
[https://i2insights.org/2019/05/28/collaboration-groan-zone/ Kaner : Divergent and Convergent Thinking]

[https://www.youtube.com/watch?v=Ch9j0d1VOuE Edge Model for change],

[https://www.gottman.com/blog/the-four-horsemen-recognizing-criticism-contempt-defensiveness-and-stonewalling/ John & Julie Gottman - 4 relationship toxins]

Threat based Neuroscience :- [https://www.psychologytoday.com/sites/default/files/attachments/31881/managingwbraininmind.pdf David Rock SCARF model] [https://partneringresources.com/wp-content/uploads/SCARF-Final.pdf How to prevent a threat response]

Systems Thinking

2024-01-30T11:49:26Z

Ppugliese: Created page with "Thinking of organisations as whole systems that are bound by invisible fabrics of interrelated actions. System Thinking is a conceptual framework, a body of knowledge and tools to make full patterns clearer and help us see how to change them effectively. Systems Thinking is seen as the fifth discipline, as it integrates the following four disciples together. * Mental Models * Personal Mastery * Team Learning * Create clarity of purpose == Related Practi..."

Thinking of organisations as whole systems that are bound by invisible fabrics of interrelated actions. System Thinking is a conceptual framework, a body of knowledge and tools to make full patterns clearer and help us see how to change them effectively. Systems Thinking is seen as the fifth discipline, as it integrates the following four disciples together.

* [[Mental Models]]
* [[Personal Mastery]]
* [[Team Learning]]
* [[Create clarity of purpose]]

== Related Practices ==
[https://blog.odd-e.com/yilv/2020/08/systems-thinking-primer.html Causal Loop Diagrams]

Ground Conditions for successful change - Margaret Wheatley

2024-01-30T11:46:37Z

Ppugliese: Created page with "Margaret Wheatley identifies three conditions that support successful change initiatives for groups, teams or organizations.<ref>https://margaretwheatley.com/books-products/books/leadership-new-science/</ref> # Change cannot occur without new information entering the system. #* Give employees as much information as possible. #* This keeps people informed, builds trust, and cuts down on rumors. #* It’s also useful to set the context “Here is who we have been, and her..."

Margaret Wheatley identifies three conditions that support successful change initiatives for groups, teams or organizations.<ref>https://margaretwheatley.com/books-products/books/leadership-new-science/</ref>

# Change cannot occur without new information entering the system.
#* Give employees as much information as possible.
#* This keeps people informed, builds trust, and cuts down on rumors.
#* It’s also useful to set the context “Here is who we have been, and here is why we need to change and where we hope to go.”
# Develop a sense of shared purpose.
#* Help employees develop a sense of personal meaning of the change for them and their teams.
#* If a situation is personally meaningful to me I am more likely to be engaged. Improving engagement is necessary so that employee satisfaction is high and is also a key part of achieving better business results.
# Allow people to have input on how the change will occur.
#* Input creates buy-in.
#* People who play a part in the change process feel valued and more in control.
#* People in every part of the company have critical information for the change process.

Involve those affected by change

2024-01-30T11:46:28Z

Ppugliese: /* Related Practices */

__NOTOC__
== Description ==
In order to increase the likelihood of successful change, leaders engage those affected by the change and also those stakeholders with critical perspectives, data and understanding of the current context. The aim is to increase the quality of the intended changes and reduce the resistance by avoiding imposing change on underinformed and underinvolved people.

Significant collateral benefits include increased trust, [https://amycedmondson.com/psychological-safety/ Psychological Safety] and staff empowerment.

== Rationale ==

A quote by Leo Tolstoy sums up the challenge of change quite nicely: “Everybody wants change, nobody wants to be changed”.

Human systems are inherently stable as behavioural norms are at a group level, along with a preference for the status quo, which makes them hard to change from the perspective of a single change agent. The reactions to an impending change are generally fearful due to a perception of loss of control and a natural fear of the unknown. The result tends to be emotional reactions and resistance before a change even starts.

To counter this fear, leaders should ensure:

* There is good motivation for the change, and it is shared by the people impacted.
* People have input and are involved rather than victims
* Generate options for change collaboratively
* Frame changes as experiments to run and then learn from
* Explore, understand and address sources of fear

Many change initiatives are designed by senior stakeholders who have useful but high-level perspectives. When changes are enacted, they suffer from poor assumptions and can often be mistargeted.

By genuinely engaging broadly and collaboratively with those in the areas impacted by the potential change, the changes are better informed and more likely to be supported and successful. Genuine engagement would look like meaningful consideration of perspectives and suggestions rather than just being sold to. Engaging more broadly enables more perspectives, data, and understanding to be fed into the process of identifying more appropriate improvement areas and change options.

== Related Principles ==

* [[Evolutionary over revolutionary change]]
* [[Foster a high trust environment]]
* [[Maximise engagement]]
* [[Catalyst for change]]
* [[Shared context improves decisions]]

== Related Practices ==

* Self-selecting teams (Fahmy, n.d., #)
* Open Space Agility (Mezick, 2015, #)
* Host Leadership (McKergow & Bailey, n.d., #)
* [https://www.huffpost.com/entry/invitational-leadership-essential-guide_b_1861139 Invitational Leadership]
* [[Ground Conditions for successful change - Margaret Wheatley]]
* Liberating Structures

The Full Power of Engagement - Jim Loehr & Tony Schwartz

2024-01-30T11:43:53Z

Ppugliese:

In their text Jim and Tony state: to be fully engaged, we need to be fully present. To be fully present we must be “physically energized, emotionally connected, mentally focused and spiritually aligned with a purpose beyond our own immediate self-interest.”

They provide 4 energy management principles that drive performance:

# Full engagement requires drawing on four separate but related sources of energy: physical, emotional, mental and spiritual.
# Because energy capacity diminishes both with overuse and underuse, we must balance energy expenditure with intermittent energy renewal.
# To build capacity, we must push beyond our normal limits, training in the same systematic way that elite athletes do.
# Positive energy rituals—highly specific routines for managing energy— are the key to full engagement and sustained high performance.

The Full Power of Engagement - Jim Loehr & Tony Schwartz

2024-01-30T11:43:22Z

Ppugliese: Created page with "In their text Jim and Tony state: to be fully engaged, we need to be fully present. To be fully present we must be “physically energized, emotionally connected, mentally focused and spiritually aligned with a purpose beyond our own immediate self-interest.” They provide 4 energy management principles that drive performance: <nowiki>#</nowiki> Full engagement requires drawing on four separate but related sources of energy: physical, emotional, mental and spiritual...."

In their text Jim and Tony state: to be fully engaged, we need to be fully present. To be fully present we must be “physically energized, emotionally connected, mentally focused and spiritually aligned with a purpose beyond our own immediate self-interest.”

They provide 4 energy management principles that drive performance:

<nowiki>#</nowiki> Full engagement requires drawing on four separate but related sources of energy: physical, emotional, mental and spiritual.

<nowiki>#</nowiki> Because energy capacity diminishes both with overuse and underuse, we must balance energy expenditure with intermittent energy renewal.

<nowiki>#</nowiki> To build capacity, we must push beyond our normal limits, training in the same systematic way that elite athletes do.

<nowiki>#</nowiki> Positive energy rituals—highly specific routines for managing energy— are the key to full engagement and sustained high performance.

Self-Determination Theory - Deci & Ryan

2024-01-30T11:42:50Z

Ppugliese: Created page with "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, they define 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 le..."

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, they define 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.

'''Autonomy'''

* The bounded autonomy provided to Self Managing Teams should be as broad as possible. For example, given all the time and resources to solve complex problems towards a measurable outcome.
* Teams should be masters of their own destiny and should not need to routinely hand off work to others. Leaders should seek actively to remove such handoffs.

'''Competence'''

* Ensure that people have opportunities to improve their skills through, for example, training and practice (e.g. running coding dojos).
* Encourage a culture of finding value in personal growth and motivation.

Make sure that people’s need for competence is not removed, for example, by seeking to de-skill work

'''Relatedness'''

* Set up teams so that they develop people’s deep need to be connected, interact with and experience caring for others.
* Establish stable teams which have a clear purpose to which the members can relate.
* Make it clear how that team purpose is related to the overall objectives of the organisation.

Building Trust in High-Performing Teams - Mila Hakanen and Aki Soudunsaari

2024-01-30T11:41:12Z

Ppugliese: Created page with " Mila Hakanen and Aki Soudunsaari Published their initial research into Building Trust in High-Performing Teams in June 2012<ref>https://timreview.ca/sites/default/files/article_PDF/HakanenSoudunsaari_TIMReview_June2012.pdf</ref>. In that paper they explored a number of different definitions for trust, for their research they settled on: ''"Trust is considered as faith in others’ behaviour and goodwill that can grow or vanish due to interaction and experiences"''..."

Mila Hakanen and Aki Soudunsaari Published their initial research into Building Trust in High-Performing Teams in June 2012<ref>https://timreview.ca/sites/default/files/article_PDF/HakanenSoudunsaari_TIMReview_June2012.pdf</ref>. In that paper they explored a number of different definitions for trust, for their research they settled on:

''"Trust is considered as faith in others’ behaviour and goodwill that can grow or vanish due to interaction and experiences"''

Trust is difficult to define. Ring and van de Ven (1992)<ref>https://onlinelibrary.wiley.com/doi/10.1002/smj.4250130702</ref> define trust as “confidence in another’s goodwill”. Trust is a commitment to cooperate before there is any certainty about how the trusted people will act (Coleman, 1990) <ref>https://books.google.ca/books?id=a4Dl8tiX4b8C</ref> . Adler (2001)<ref>https://www.jstor.org/stable/3086057</ref> distinguishes three sources of trust:

# a calculative form of trust via assessment of costs and benefits;
# familiarity through continuing interaction; and
# values and norms that cultivate trustworthy behaviour.

Fukuyama (1996) <ref>https://books.google.ca/books?id=kNSLBoJqIm8C&hl=en</ref> describes trust as arising from expectations of honest and cooperative behaviour. Thus, trust is expressed in the behaviour towards others (Costa, 2003)<ref>https://www.researchgate.net/publication/235260441_Work_Team_Trust_and_Effectiveness</ref> . Trust also can be seen as a flexibility that turns up in difficult circumstances (Ilmonen et al., 1998;). Trust is also based on the probability calculus where the emphasis is on advantages and disadvantages of an interaction (Tyler and Degoey, 1996) <ref>https://books.google.ca/books?id=A_8LbcsgrNMC</ref>). Past experiences and interactions affect trust, which usually takes a long time to develop.

Their final research paper was published in 2015.<ref>http://ejbo.jyu.fi/pdf/ejbo_vol20_no2_pages_43-53.pdf</ref>

==References==
<references/>

The Anatomy of Trust - Brene Brown

2024-01-30T11:41:07Z

Ppugliese: Created page with "Brene Brown is an American professor, lecturer, author, and podcast host. Brown has spent decades studying the topics of courage, vulnerability, shame, and empathy. Her TED talk, "The Power of Vulnerability"<ref><nowiki>https://www.ted.com/talks/brene_brown_the_power_of_vulnerability</nowiki> </ref>, has been widely viewed. Trust is built slowly over time, Brene uses a marble jar metaphor; “We can deposit marbles and build up our sense of trust or withdraw them a..."

Brene Brown is an American professor, lecturer, author, and podcast host. Brown has spent decades studying the topics of courage, vulnerability, shame, and empathy. Her TED talk, "The Power of Vulnerability"<ref><nowiki>https://www.ted.com/talks/brene_brown_the_power_of_vulnerability</nowiki> </ref>, has been widely viewed.

Trust is built slowly over time, Brene 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”.

Trust can be deposited through<ref>https://www.uncrushed.org/content/2019/7/1/the-anatomy-of-trust-brene-brown</ref>:
* Asking for help
* Receiving the generosity of others
* Giving without recompense
* Contributing constructive and helpful feedback
* Designating and maintaining clear boundaries,
* Being capable and reliable
* Owning your sh*t
* Being a vault
* Choosing courage over comfort
* Practicing non-judgement
* Standing up for someone through integrity
* Creating a generous narrative about others.

Brene has defined the acronym BRAVING for elements that makeup trust.

* '''B'''oundaries
* '''R'''eliability
* '''A'''ccountability
* '''V'''ault
* '''I'''ntegrity
* '''N'''on-judgment
* '''G'''enerosity

==References==
<references/>

Trust and Purpose - Paul Zak

2024-01-30T11:41:01Z

Ppugliese: Created page with "Paul Zak states that teams fundamentally need two key components, trust and purpose.<ref>https://www.thoughtleadersllc.com/2017/04/leading-with-trust/</ref> A foundation of trust opens teams up to high levels of collaboration, creativity and performance. “Trust is a powerful lever to improve economic performance because it reduces the frictions that occur when individuals interact. If I trust you, and you are trustworthy, we are an effective team because we reliably..."

Paul Zak states that teams fundamentally need two key components, trust and purpose.<ref>https://www.thoughtleadersllc.com/2017/04/leading-with-trust/</ref>

A foundation of trust opens teams up to high levels of collaboration, creativity and performance. “Trust is a powerful lever to improve economic performance because it reduces the frictions that occur when individuals interact. If I trust you, and you are trustworthy, we are an effective team because we reliably complete our tasks – usually – and that is where things get complicated.”

This, in turn, should raise people’s levels of oxytocin, a key indicator for the brain to signal the motivation to cooperate. Based on research<ref>https://greatergood.berkeley.edu/article/item/how_oxytocin_can_make_your_job_more_meaningful</ref> eight building blocks that leaders can influence to create a high trust, high-performance culture are:
*Ovation (recognize those who meet or exceed goals)
*eXpectation (design difficult but achievable challenges and hold colleagues accountable to reach them)
*Yield (enable employees to complete their work as they see fit)
*Transfer (facilitate self-management in which colleagues choose the work they want to do)
*Openness (share information broadly)
*Caring (intentionally build relationships with colleagues)
*Invest (promote personal and professional growth)
*Natural (behave authentically and ask for help)

== References ==
<references />

Foster a high trust environment

2024-01-30T11:39:51Z

Ppugliese: /* 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]]
* [https://www.youtube.com/watch?v=kJdXjtSnZTI 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:30:50Z

Ppugliese:

__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]]
* [[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 />