Applying ADKAR in Agile.

We cannot discuss CM and Agile integration, unless we explain how ADKAR gets reconfigured in Agile. If you are already familiar with PROSCI’s ADKAR model, you will find out how it supports individual transitions in an incremental environment. If you aren’t, we’ve got you covered. This post gives you everything you need to know, from a detailed breakdown of ADKAR’s change sequence to a comparative overview of how it operates when coupled with waterfall and Agile approaches.

ADKAR at a glance.

At the organisational level, change is nothing other than the sum of successful individual transitions, which can be achieved in five steps. Skip one or leave people behind, and the whole initiative will be ruined. Fail to put the right “building block” at the bottom, and the change will be, at best, short-lived. A powerful tool that has gradually become the change model standard, ADKAR can be summarised as follows:

Any change starts with some sort of Awareness [A] of the need to change. Not that change will occur because of this shift in mindset. It means that a person has come to terms with the fact that maintaining the status quo is not an option and that he or she understands what risks are involved. This is the seedbed in which people’s Desire [D] to change - and get on board - takes root and grows. Knowledge [K] building comes next. Simply put, people need to know what to do during the transition phase and after the change has been implemented. A common mistake is to rush headlong into the third phase and equip collaborators for the change, without talking them through the strategic reasons (organisational incentives) and personal implications (personal incentives). The fourth step refers to the Ability [A] to implement the required skillset, that is, to be comfortable with the new process, to master the use of new tools and systems, to adopt new behaviours and a different mindset, to fulfil a different role, to be efficient within the new hierarchical structure and understand how performance is now assessed. This is when change truly comes to life and where coaching activities can make a real difference. Last but not least, Reinforcement [R] activities and monitoring aim at making the change long-lasting, preventing people from reverting to their old habits, something quite usual and inherent to human nature. 

An easy and intuitive way to gauge progress is to scrutinise the language. It reflects how collaborators relate with the change as it unfolds. If you hear « I understand why… » that is Awareness, “I decided to take part in…”, that is Desire, “I know how to do…”, that is Knowledge, “I am able to, capable of…”, that is Aptitude, “I will keep on doing…”, that is Reinforcement. As will be discussed below, the same holds true for Agile, with the difference that discourses will be formulated at three different levels: the release, the project and the approach.

« ADKAR in Agile » illustrated.

So how does ADKAR support individual transitions in an Agile initiative? It boils down to a balancing act between the project level and sprints or releases. Let’s take a real-life example, say, a new ordering system.

Should the Awareness process be attached to the project or the sprint level? You will probably agree that it is project-specific. Collaborators must understand why the new ordering system is necessary. Creating desire to actively participate in its implementation is also project-specific, for the most part - even though it makes perfect sense that someone would be expressing a desire to take part in a particular release. Since the development and deployment of the new system is iterative, it is only logical that employees be equipped in accordance with the specificities of each release. The point of inflexion corresponds to the phases of Knowledge and Ability, where releases become ADKAR’s dominant operational levels. Knowledge refers to what should be done during and after a particular release, and Aptitude refers to what this release requires in terms of performance or tangible actions. The new system must be adopted on an uninterrupted basis and made use of proficiently. Logically, reinforcement takes place at both levels, project and releases. Once the system has been deployed, in parts or as a whole, it is crucial to monitor its utilisation and duly register incidences reported by users with a view to taking corrective actions and nurture the developmental process, which is incremental in nature and calls for constant feedback.

From Waterfall to Agile.

If you operationalise ADKAR in a Waterfall framework, you must align the Ability phase with the deployment of the new ordering system in order to empower the agent of change (collaborator) and to transition towards the envisioned future state. From there, you can retro-engineer the ADKAR sequence and define when to build Knowledge, drive engagement (Desire), create Awareness and, of course, Reinforce.

If you switch to Agile, you will first operate at the project level, creating Awareness and Desire for the new ordering system. Next up, you will align Knowledge and Ability with each release. Promoting some Awareness and Desire-related actions at this sublevel also creates iterative ADKAR trajectories. Each release may certainly benefit from reinforcement activities, but remember that the main focus here is on Knowledge and Ability. Later on, and as a final step, you will reinforce the whole project.

In short, ADKAR stays pretty much the same but its key components are redistributed across the whole project and releases. As a process, it is found at three different interdependent levels. At the most basic level, people are expected to understand the reasons of the release, to be willing to participate and know what to do in this particular case. But ADKAR also makes sense at the project level as collaborators have to understand why the new ordering system is a plus, must be engaged and know how to proceed. At the meta level, we find Agile as an approach, which has to be adopted in much the same way as the project/change itself.

To keep up with our series, do not miss our next post on applying the five Change Management levers in Agile!

 

PROSCI’s ADKAR Model	Definition	Anwers to  :	ADKAR’s 3 levels
Awareness	…of the need to change.	Why ? Why now ? What if we don’t do it ?	« I understand  why… » For this release For this projet For Agile as an approach
Desire	…to participate in the change and support it.	What’s in it for me ? Personal Incentives Organisational Incentives	« I have decided to participate … » In this release In this project In Agile as an approach
Knowledge	…on how to change.	In context (after R&D) Knowledge before Knowledge after	« I know how to do what’s needed… » For this release For this project For Agile as an approach
Ability	…to implement skills and required behaviours	Size of the gaps? K=A Barriers/Ability Practice/Coaching	« I am able to do what’s needed … » For this release For this project For Agile as an approach
Reinforcement	…to make change long-lasting	Mechanisms Metrics Support	« I will continue to do what’s needed … » For this release For this project For Agile as an approach