Full article with thanks to https://www.imaworldwide.com/blog/5-implications-for-change-management-in-an-agile-world
As change management consultants, we’re often asked how Agile and change management fit together. There are a lot of questions about how adding change management to an Agile project management cycle works; there are concerns expressed about whether change management will slow things down, and get in the way of the speed and innovation derived from Agile.
The need for change management is arguably increased in Agile because of its iterative nature, the amount of churn created, and consequently, its impact on climate and readiness. There are implications for change management when an organization adopts Agile that need to be addressed.
What is the same in both approaches is the need to focus on full implementation, not just installation. What is the same is the fact that if you marry a fit for purpose, situational change management approach that’s blended with project management protocols, you will help projects be implemented faster and to benefit realization.
5 Implications for Change Management in an Agile Environment
Agile is a project management approach that works by breaking projects into short, iterative cycles called “sprints”. At its core, Agile is based on the assumption that circumstances change as a project develops. That’s why, in an Agile project, the planning, design, development, and testing cycles are never done. They continue to change as the project takes form.
As with other project management disciplines, Agile project managers focus on doing things technically right by making certain they deliver business changes under time, cost, and quality (scope) constraints. That’s Installation. While you are still working through a life cycle, in Agile, they are doing this in short sprints, rather than saving it all for the end. This has the potential to create ongoing disruption and churn.
These differences create some implications for change management in an Agile world:
- Because there is less planning time (you are going directly from milestones to script), change management templates are less useful
- There is less opportunity to formalize and standardize
- Because Sponsors and Targets can be exposed to the changes earlier than in the traditional Waterfall approach, there is more immediate disruption, and disruption is constant. Since there is a direct correlation between levels of disruption, and resistance, resistance occurs much earlier, and must be planned for and managed earlier
- Given all of the above, change practitioners must be more adept and able to make judgment calls rapidly and often, rather than relying on templates and tools
- Impacts on Project Managers, IT, and Sponsors must be managed
The same change management deliverables are needed, although the timing for developing these may be altered in Agile. In the Initiation phase, the foundation of these deliverables should be built:
- Business Case for Action to define what the change is
- From-To Definition to identify gaps between “is” and “will be”
- Key Role Mapping to identify where Sponsors are needed, and who specifically these individuals are by name
- Readiness Planning to have strategies and tactics available to manage resistance
- Communication Planning by audience, with feedback loops to gather feedback that identifies potential sources of resistance
In both the Agile and Waterfall life cycles change management practitioners must continually ask the same questions to manage risks in real-time, and be prepared to apply situational strategies and tactics for mitigation:
- Is the Definition of the Change still accurate, and are Sponsors and Agents aligned?
- Where is Sponsorship needed?
- Where will we have resistance, and how will we manage it?
- What do we need to communicate, when, and how?
- What reinforcements are needed to drive the change to sustained, full implementation?
Blended Approach is Still Best Practice
Whether you are using Agile or Waterfall life cycles, it is still best practice to blend the technical plan with the human side plan. In fact, because of the iterative nature of Agile, it is even more critical that you do this in order not to miss implications on the people side for technical project plan changes, and vice versa. The other common options (bolting on the human side at the end, or running parallel plans) don’t work.
Instead, both the technical (aka project management) side and human (aka change management) side of implementation must be managed concurrently to achieve real project success: projects that are delivered on time, on budget, all business, technical, and human objectives met.
AIM & Agile: Two Methodologies, One Common Assumption
The Accelerating Implementation Methodology (AIM) is ideally suited for an Agile world. AIM is a change management framework designed to be flexible based on what is occurring at the moment rather than what is next on the “to do” list. AIM’s core principles guide you on what you should be doing, given the day-to-day project realities and challenges. It is a risk dashboard for the people side of a change.
Both Agile and AIM are based on the common assumption that change is not linear! In our vast experience working on business change implementations both small and large, we have yet to see a project follow the exact original plan. Most, if not all, implementations are dynamic and unpredictable. That’s why a process that is flexible, based on what is occurring at the moment, is so valuable. It’s one of the reasons Agile and AIM work so well together.
In the end, it doesn’t matter if you are working in an Agile environment, or a more traditional Waterfall development process. The blend of a fit for purpose and repeatable change management process like AIM dramatically improves the likelihood of implementation success.
Full article with thanks to https://www.imaworldwide.com/blog/5-implications-for-change-management-in-an-agile-world