Why ELSE?: Difference between revisions

From go-ELSE
Jump to navigation Jump to search
(Created page with "We observe a very high rate of failure of large-scale agility programmes, going by names such as Agile Transformations or scaled product delivery. Scaling agility requires fundamental changes to an organisation as it is much more than a process change. Applying a new framework rarely results in sustained and positive change, with additional processes dragging progress and old habits reasserting themselves. To increase the probability of success, ScaleAgility incorporate...")
 
m (Ppugliese moved page Why ScaleAgility? to Why ELSE? without leaving a redirect)
(No difference)

Revision as of 08:07, 24 January 2024

We observe a very high rate of failure of large-scale agility programmes, going by names such as Agile Transformations or scaled product delivery.

Scaling agility requires fundamental changes to an organisation as it is much more than a process change. Applying a new framework rarely results in sustained and positive change, with additional processes dragging progress and old habits reasserting themselves. To increase the probability of success, ScaleAgility incorporates the following high-level ideals:

  • Start from where you are: Any change has to start from the current state of an organisation.  This is the real state - how things actually get done, both formal and informal and probably not as it is written in the documentation.
  • Complexity: Recognise that organisations are complex adaptive systems, requiring an iterative change process informed by feedback loops rather than a large transactional change to a new target operating model.
  • Emergent practice: An almost infinite number of potential patterns and practices can be applied in scaling situations. The choice of a specific pattern for a given context should not be because it is considered “Best practice” and part of a collection of patterns in a framework. Instead, the choice should be informed by fundamental principles and validated and evolved through experiment.
  • Inclusive change: Ensure that change is not “done to people” but instead “with people”. Involve those impacted by a change in a collaborative exploration of the current context and generation of potential incremental improvement experiments.
  • Small changes: Reducing the size of change lowers the fear and risk of change and speeds up learning.
  • Continuous improvement is a core competitive capability. For this reason, an improved capability of supporting change is a key target outcome of the change process!
  • Success at scale requires organisational agility: A scaled challenge is unlikely to function in an isolated bubble outside an organisation’s environment. It will require improved support and reduced impediments from the organisation to reach its full potential.

Advantages of the ScaleAgility Approach

“Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation. Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves.”

Implementing Lean Software Development - From Concept to Cash, Mary and Tom Poppendieck

Regardless of their provenance, applying new processes, roles, policies, structures, and systems rarely results in sustained and positive change, with old habits reasserting themselves.

The ScaleAgility approach intends to avoid or mitigate the following contributory causes of failure common in Agile change initiatives:

  • Approaching change as a large transactional process, moving directly from the current state to a designed ideal future state. The larger the change, the greater the fear, risk and probability of failure.
  • Topdown imposition of new processes, policies and roles leads to disempowerment, a lack of buy-in and poorly informed changes.
  • Starting with incorrect assumptions or a lack of in-depth understanding of the starting context for how the organisation currently functions. This point is related to another: a failure to engage the people who have the necessary knowledge and will additionally be the people who will have to enact changes.
  • A belief in the concept of “Best practice” leads to blind and unthinking adoption of an entire set of practices or framework as a monolith, regardless of the suitability of specific elements to aspects of the organisation. The larger a framework, the less likely it will fit any given context in its entirety.
  • Simply overlaying new processes, policies, roles and systems onto the current organisational system creates additional overhead. Instead, they should be implemented with an understanding that an evolutionary but fundamental shift in leadership, roles, policies, structure, and culture will also be required.
  • Renamed but still the same - existing roles, processes, policies and systems are renamed but remain largely the same, creating confusion and little to no benefit.
  • Agile and agility are viewed as only relevant to engineering rather than understanding that agility is an end-to-end business value proposition, including leadership, organisation design and supporting services.


In summary, comprehensive scaling frameworks are seductive as they appear to be “Best Practice” and have all the answers. The reality is that there is no shortcut! The ScaleAgility approach mitigates or avoids many of the pitfalls of challenged scaling endeavours with a flexible strategy for the emergence of scale patterns.