You are all familiar, at least to some extent, with “Agile”. Iterative development methods have been around for almost four decades. The Agile Manifesto itself was formalised at the turn of the millennium. Originally targeting software development, Agile has grown to become a discipline in its own right, based on a set of values and principles. But how does it articulate with Change Management, the discipline that seeks to maximise adoption and usage of change(s)? Agile clearly finds an echo in Change Management through common values and symmetrical principles. This certainly enables Change management to be an effective method to move to Agile or navigate Agile projects. In fact, we could say that the two disciplines are coextensive, delivering increased value where they intersect.
This series of 6 articles offers an in-depth exploration of the intersection between Agile and Change management, down to the nuts and bolts of how to integrate Agile with PROSCI’s method. In this first article, we go back to the basics.
Do Change management assumptions hold true in Agile?
To make any change effective and long-lasting, both the technical and human sides of change must be properly addressed. There is no point in designing, developing and delivering the finest solution if it is not fully embraced, adopted and utilised. This is the basic tenet of Change Management. Now, what about Agile? Both aspects - technical and human – remain, but what is different is the transition state. While Change management usually depicts change as one big move from the present state to a future state through a transition phase, Agile is about iterating, release after release. As illustrated in the graph below, these loops or “sprints” create multiple transition and future states.
Change management is also based on the assumption that change is the aggregation of successful individual transitions. “Macro” changes affecting the organisation as a whole, such as mergers, acquisitions, new markets, the implementation of SAP or the deployment of Windows 365 … require “end users” to be fully on board, equipped for the change and able to go through their own personal transition. If Change management posits that individuals are the building blocks of change, the same holds true for Agile. No matter whether we make use of the traditional Waterfall or Agile iterative model, there is one constant: combined individual efforts shape change.
4 common values.
If we take a closer look at the values stated in the Agile Manifesto, similarities with the Change management rationale are striking:
Value 1: “People and their interactions over processes and tools”
The matching principle in Change Management is rooted in the logic of our preceding observations: individual transitions, more than solution design, bring about change. To put it simply and more accurately, there is no change without adoption, hence the importance of tackling the human side of change early on.
Value 2: “Working software over comprehensive documentation”
The binding thread here is that results are derived from utilisation, not from the solution itself. Adoption and usage bridge the gap between solution design and results.
Value 3: “Customer collaboration over contract negotiation”
From a Change management point of view, signing a few checks will only but be in vain if the change is not dealt with at the most granular levels. Just as customer collaboration comes first in Agile, Change management emphasises impact management at the individual level as a key success factor. Preliminary assessments are based on a model indexing 10 working areas likely be to be impacted by the change: processes, systems, tools, behaviour(s), mindset, role(s), hierarchy, performance, compensation, location.
Value 4: “Responding to change over following a plan”
Again, individual trajectories are everything. Impacted people have to go through different phases in sequential order to successfully complete the transition (Awareness, Desire, Knowledge, Ability, Reinforcement – or PROSCI’s ADKAR model). Any friction along the path demands adjusted actions and a course-correction if needed.
12 symmetrical principles.
Not only are Agile and Change management values congruent, at least 10 out of 12 Agile principles are mirrored in Change Management. For clarity, they are rephrased in the table below. Having examined how the two disciplines intersect and cross-fertilise, it is now time to focus on implementation. Stay tuned for the next posts!
Principle
|
Agile
|
Change Management
|
1
|
Customer satisfaction through early and
continuous software delivery.
|
Adoption and usage at the table
from the beginning and throughout.
|
2 |
Accommodate changing requirements throughout the development process.
|
Individual change journeys through ADKAR set the pace.
|
3 |
Frequent delivery of working software.
|
Frequently supporting individuals
through ADKAR.
|
4 |
Collaboration between the business stakeholders and developers throughout the project.
|
Encouraging employee engagement
and participation.
|
5 |
Support, trust, and motivate the people involved.
|
Yup!
|
6 |
Enable face-to-face interactions.
|
Communications, coaching, and sponsorship include face-to-face interactions.
|
7 |
Working software is the primary measure of progress.
|
Adoption and usage is the primary measure of Change management progress.
|
8 |
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
|
|
9 |
Attention to technical detail and design enhances agility.
|
Attention to answering peoples questions and need enhances adoption and usage.
|
10 |
Simplicity.
|
ADKAR…
|
11 |
Self-organizing teams encourage great architectures, requirements, and designs.
|
|
12 |
Regular reflections on how to become more effective.
|
Regular ADKAR pulse checks, PCT and BP Audit to improve effectiveness.
|