Guiding an Agile Change Platform
A sustainable approach for incremental & iterative change
In an age when “the pace of change is hypersonic, not glacial”, how do individuals, teams and organizations find a mechanism that’s at once supportive and enabling in such an environment?
The days of linear change programs that simply roll out to cohorts like an unfurling rug are no longer enough. We don’t have the answers up front as to what will work nor how long it will take in a complex adaptive system. How we make change happen is as important as what is being changed. In essence, our approach to change needs to become more agile.
Building a sustainable approach for incremental & iterative change is the purpose of an Agile Change Platform, a collaborative construct that allows individuals, teams and organizations to guide their organization through a continuous mode of change. The change no longer comes to an end; your future state merely becomes your current context.
Through a collaboration with Change Designer, Sandra Daniel, we’ve pulled out a pattern than can be used as the basis for standing up an Agile Change Platform which can then applied towards organizational changes, including those adopting agile values and practices in their organization.
1. Craft Meaningful Outcomes
The starting point, before any specific actions are taken, is to craft meaningful Outcomes. The timeline for an Outcome will vary based on the needs of your organization and could range from a few months to a few years.
Each Outcome will initially be unvetted, untested, but rooted in the current context and experience of the individual or group putting it together.
A simple structure for an Outcome might read:
We believe that [Making Change X]
For [Cohort A]
Will Achieve [Outcome Y]
We Will Know When We See [Measure B]
2. Build a Change Map
Given the number of possible Outcomes and potential Change Stories associated with each of them, it can become overwhelming trying to make sense of how they fit together, where the dependencies or conflicts might lie and where to start.
To help with this Release Planning activity we need to return to foundational principles of human collaboration -> Make it Visible + High Quality Conversations.
A powerful collaborative planning pattern we can draw from is that of User Story Mapping, pioneered by Jeff Patton, and applied worldwide by teams who are co-creating their product backlogs. Using many of the same principles and practices. We’re looking to create a container wherein highly contextual conversations can happen with different stakeholders that will create alignment around priorities and plans.
A Change Story Map illustrates relationships between Outcomes, Change Stories and Actions, in a 2-dimensional format, helping stakeholders to plan incremental and iterative releases.
3. Shape a Release Plan
As one or more Outcome is broken down into Change Stories, the number of items in flight can become difficult to fully understand and plan.
Dependencies, countervailing forces, timing and other concerns all need to be understood so a coherent Release Strategy and can be articulated and planned for.
There are a range of release strategies that need to be considered and the prioritization model needs to be shared between those who are deciding. An example prioritization matrix could be as follows:
- Degree of change
- One department vs many, isolated tools vs systematic retooling
- Type of impact
- Time to market reduced by 60%, employee engagement up
- Number of audiences
- 300 local employees vs 65,000 person global workforce
- Organizational Change Capacity
- One department can manage 5 simultaneous changes
Since it is difficult to target exactly when a specific Change Story will move from being in play to the current context, it is more effective to time box the release cadence along the lines of 3 or 4 months. That way, each item can be revisited in depth on a frequent enough basis to adjust (or removed) if needed, but also provide enough time for things to unfold
4. Refine Actions
A Change Story may be too large to run in a single iteration (e.g. month) and therefore can be broken down into smaller actions with Acceptance Criteria, that can then be managed in a Change Backlog and planned in iterations.
We are looking for specificity with respect to Acceptance Criteria – meaning we try to imagine the conditions of success for any single action.
Additionally, we want to identify who is likely to be impacted and when.
5. Iteratively Guide Platform
What was the future is now the present and so the cycle will continue ad infinitum. Your change platform does not end; it is a practice. A continuous state of development and refinement.
Even beyond the more significant Release boundaries it is important to build in various forms of retrospectives to ensure that a healthy cycle of Inspect & Adapt is being followed. If something is not working and causing damage, then waiting 4 months to make a decision is too long.
Over time, as the organization gets accustomed to the regular heartbeat of change, the capacity of Change within organization should increase. There are certainly limitations and Change Capacity growth won’t rise indefinitely, instead it will reach an equilibrium that will hopefully be matched by a better understand of what works and what doesn’t so better choices can be made.
The organization will then have a sustainable Agile Change Platform in place that is both persistent and adaptive, helping underpin a culture of welcoming change. By incrementally & iteratively guiding it forward via clear outcomes and measurable experiments, individuals, teams and the broader organization will have a collaborative map of the change to work with and talk through at a sustainable pace.
In future posts, each part of the Guiding an Agile Change Platform approach will be deconstructed into further detail with real life examples. More can also be learned in our associated training class.