top of page
Search

AGILE and Change Management - is ADKAR™ AGILE?


© Al Lee-Bourke – Heads of Ayr


Overview


ADKAR describes the human innovation/decision process. AGILE (Fragile, Wagile, Badgile) drives technical projects. Innovation/decision process realizes AGILE project possibilities. Change Management Action plans are about how to drive a project beyond deployment through to adoption. Change Management with AGILE typically has ‘control tower’ / strategic activities throughout and tactical/sprint activities. Integration of both gets results; one without the other doesn't. IT derived from AGILE has no inherent value; value is realized when people change how they work i.e., successfully move through their innovation/decision process.


Plan Driven Approach


It’s a false dilemma to imply that a plan-driven approach and an agile approach are mutually exclusive. Instead, a plan-driven approach and an agile approach can and do coexist and complement each other. I teach and have practiced for years that approach.


Accelerated learning, empiricism (or utilitarianism, Kantianism, existentialism, pragmatism, realism, constructivism, determinism, etc), bottom-up, top-down projects are all dependent on how people self-determine, which in turn is based on autonomy, competence, and relatedness. AGILE sometimes includes this, and ADKAR always includes this – it’s based on it.


The innovation/decision process is a powerful way to determine how to drive those three fundamental elements. Using both is key, and works.


Avoiding Lengthy Planning


Agile and change management are closely related, and the key is to avoid lengthy planning. The Prosci approach suggests creating an "ADKAR Blueprint," a basic spreadsheet of tasks using the journalist's 5W+H approach, while Agile employs spreadsheets and other tools to list tasks quickly.


Spreadsheets can become complex on global projects, so it's beneficial to group them into categories such as "stuff for leaders," "stuff for managers," and "stuff for comms." Although plans are necessary, they are constantly changing, both strategically and throughout each sprint.


The primary focus is to support individuals and groups on their innovation and decision-making journey.


Helping people decide to change needs a different approach. "Plan as you do" may work for things, but not for people who are plagued by cognitive biases; as Jung famously stated: "Even in the face of empirical evidence, I am necessarily thinking of myself.



Bureaucratic and Time Consuming?


Yes it can be, but you know what else can be time-consuming and resource-intensive? Chaos. And that's exactly what you'll get if you don't use change management (properly). A little upfront investment in change management can go a long way in minimizing disruptions and increasing the chances of successfully adopting new technologies and processes. In fact, with “excellent,” change management a program of change is six times more likely to meet or exceed project objectives..

Over the past several years, Digital Transformation programs have experienced failures amounting to USD 900 billion due to the lack of including "excellent" change management in their projects (sources available). I’ve seen this happen so often over the last 40 years, and done it myself as a CIO – twice - until I learned 😊

Ultimately, we need both, working together and understanding one another.


Consider the USD900 billion dollars worth of chaos out of USD1.3 Trillion invested. Though what the proportion of that is Agile/wagile/badgile/fragile I don't know - even if it's 1% it's still USD9 Billion which is quite a lot.


Impact on Workloads


The impact of workload depends on what it involves, such as task assignments, time constraints, or job responsibilities, etc. Change management requires examining the reasons for the high workload, for which I'd use "competing commitments" and "immunity to change." analysis. There are established approaches to mitigate these issues.


Quitting is one of the many consequences of poorly managed change. It is the ultimate manifestation of resistance and arises from a lack of support for autonomy, competence, and relatedness (self-determination). We can reduce about half of the resistance by identifying and addressing it proactively during the change program.


Working together

There is a direct connection between change management’s value proposition - to achieve business results - and the outcomes of the project (many references available). When working to create a collaborative relationship with Agile (or any other) project managers and project teams, my first step is to show that the work I do in the change management space will ultimately make the project (and them) more successful.

In the Digital Transformation arena, for example, it’s ultimately based on the following principles: (although you could substitute the word “IT” for any change e.g., “new building”, “new way of working,” etc). *

  • IT has no inherent value.

  • Benefits arise when people do things differently (no change, no value).

  • Only business leaders and managers, and end-users, can realize business benefits.

  • All IT projects have outcomes, but not all outcomes are benefits.

  • Benefits must be actively managed to be realized.


 

Postscript #1


Shannon de Rubens made some great points in response to my article. Here’s what she said:


ADKAR is always applicable, including iteratively. That said, my Prosci practice (despite best efforts) often feels one step behind. In a world (tech) where projects barely have a charter, it is a constant game of supporting basic PjM activities that CM relies upon. My emerging belief is that PM is struggling with “agile” and CM by extension. And the word “agile” is being used (especially by leaders) to mean “faster than reasonable” when it really is supposed to mean incremental release or fix forward. Sometimes I just hear the word it’s hard not to groan because of what it’s come to mean.


And here’s how I think we can address those issues.


Improve project management processes by implementing formal project charters, clear goals and objectives, and comprehensive project plans that consider ADKAR™ and other change management principles.


Clarify the definition and usage of "Agile" within the organization to avoid confusion. Educate leaders and team members on its core principles, including how it can support incremental release and fix forward, rather than simply speeding up project timelines without regard for quality or outcomes.

Launch a "Move to Agile" project alongside the technical project to receive support and guidance during the decision-making process before the actual change takes place. Apply Prosci's ECM Change Management Maturity model to each project, with a specific focus on Agile, to ensure necessary change management processes and resources are in place to implement Agile methodologies and achieve desired outcomes effectively.


Provide ongoing training and development opportunities, such as workshops and webinars, to help Prosci® practitioners stay up-to-date with the latest change management techniques and best practices, including how to apply ADKAR iteratively and effectively within an agile development context.

Foster a culture of continuous improvement by encouraging team members to experiment with new ideas, collaborate effectively across departments, and share knowledge and insights. Embracing a growth mindset and a willingness to learn from mistakes helps the organization adapt quickly to changing circumstances and challenges.


Potential Objections


I can think of a few objections we might get on this lot. So, here’s how I’d respond to them.


Objection 1: "Project management processes do not need improvement."


Response: Re-evaluating and improving project management processes, especially with new methodologies like Agile, is always beneficial. Implementing more formal project charters, clear goals and objectives, and comprehensive project plans that consider ADKAR™ and other change management principles can better ensure project success.


Objection 2: "Clarifying Agile's definition is unnecessary."


Response: It's important to understand Agile's core principles across the team consistently. Educating leaders and team members on how Agile can support incremental release and fix forward can avoid confusion and ensure a smoother transition.


Objection 3: "Launching a "Move to Agile" project is a waste of time and resources."


Response: Implementing Agile can be a significant change for an organization. Launching a "Move to Agile" project alongside the technical project can receive support and guidance during decision-making, ensuring a successful transition to Agile methodologies.


Objection 4: "The ECM Change Management Maturity model is too complex and time-consuming."


Response: While implementing the ECM model may require additional effort, it's worth it to ensure that necessary change management processes and resources are in place to implement Agile methodologies effectively. Focusing on Agile within the model can streamline the process and make it more efficient.


Objection 5: "Providing ongoing training and development opportunities is too expensive."


Response: Ongoing training and development opportunities are essential to help Prosci® practitioners stay up-to-date with the latest change management techniques and best practices. Providing workshops and webinars that focus on how to apply ADKAR iteratively and effectively within an agile development context can ensure that team members have the necessary skills and knowledge to succeed.


Objection 6: "Encouraging a culture of continuous improvement is too idealistic."


Response: Fostering a culture of continuous improvement is essential to stay competitive and adapting to changing circumstances and challenges. Encouraging team members to experiment with new ideas, collaborate across departments, and share knowledge and insights can create a more innovative and agile environment that's better equipped to succeed.


Finally, I got some challenging observations on LinkedIn from Cathelijne De Vris. Cathelijne made the following points:


I am impressed by so many false statements about Agile in one article:


1) AGILE (Fragile, Wagile, Badgile) drives technical projects —> this mindset is applied in so much more!

2) IT derived from AGILE has no inherent value; —> agile is all about value delivery. I have no idea what is meant with this statement

3) on how people self-determine, which in turn is based on autonomy, competence, and relatedness. AGILE sometimes includes this, —> autonomy’s a cornerstone of agile thinking


I really hope the author takes his own point into reflection, and that he will “Clarify the definition and usage of "Agile" within the organization to avoid confusion.”


My response was:


Thanks for your feedback. Short articles can make some points unclear. I've often seen debates like this during digital transformations. One idea is a parallel 'project Agile' program, like Prosci's® advice. It would support people's innovation and decision-making for Agile. This might solve many issues and could be a book idea! 😊


You said Agile applies beyond technical projects. I agree. My article aimed to show its effectiveness in them. Agile works in various fields and can be adapted. But implementing Agile needs strong change management for cultural and process shifts.


I agree Agile is about value delivery. My point is to align Agile with organizational goals. Together Agile and Change management helps organizations realize these goals.


You highlighted autonomy in Agile thinking. These factors motivate people and support Agile. Managing people through their innovation/decision process is often overlooked. In practice, I've seen too many viewing Agile as a cure-all and forget change management. Both Agile and change management must work together for success.


© Al Lee-Bourke al@554north.scot

9 views0 comments

Comments


Leebourke Business Change Counsel
bottom of page