In other posts in our Agile Change Management series, we explored some of the background to Agile as an approach including:

• Why Agile organisations need Agile Change Management
• Enterprise Change Management: the key building Block of Enterprise Agility

In this post, we get a little more prescriptive and practical with a working definition of Agile Change Management itself.  We also take a look at a few Agile myths we come across on an almost daily basis and their impact on people’s view of the role of Change Management in an Agile environment. 

Creating an Agile Change Management definition to work from

A good starting point is to consider the two levels of Agile that organisations are working on right now, namely:

• Agile at the organisational level
• Agile at the development processes level

Agility at an organisational level

Agile at an organisational level is strategic and concerned with the direction and velocity of the organisation as a whole. It is about making the entire entity more Agile in the way it responds to the market, and for us, this means that Agile is about everyone being ready and able to; evolve their role and practices quickly, and to make (what are often) cultural adjustment to support new business models.   

Being able to deliver Agile at an organisational level demands a model of Enterprise Change Management support that is responsive and relevant to the needs of organisations having to transform themselves in a way that is all-encompassing.  It demands a change capability that can quickly scale to support and prepare people up, down, and across the organisation to deliver Agile at this level. 

In our high-velocity world of change, change management has to be everyone’s business –and not just the special sauce of a small number of experts. Wherever people are around the world – remote or distributed – individuals, leaders, and teams need to be able to gear up quickly and manage the risk of perpetual loading; release sufficient capacity for business-critical changes; plan and execute individual initiatives right the first time and with the right resources. 

Agility at a development/process level

Agile at the development-processes level is concerned with evolving solutions through the collaborative efforts of different teams.  It is about breaking projects into smaller iterative pieces – based on the assumption that circumstances change as a project develops, and planning, design, and development must be prepared to evolve as it makes contact with people. 

Agile project managers are not too different from other project managers, in terms of their focus on delivering successes to time, cost and scope, and for real results to be achieved, we still need change management to support adoption and usage.  It is just the pace and nature of an iterative development process that requires change management to adjust to being most effective.

Agile at the development-processes level still requires strong sponsorship, local manager engagement, effective communication, learning, and reinforcement.  It still requires an understanding of change impacts capturing and reporting on change data and key potential risks around commitment levels etc via a Change Management toolkit.  It’s just the way that you work on these activities and integrate them with the Agile team processes that will dictate change managers’ relevance and success.  

The diagram below shows an example of how we see this working in client environments, with change management able to operate at pace and ready to pivot as sprint reviews and retrospectives drive adjustments in project direction.

Challenges for Change Management – and the emergence of Agile myths

Challenges for bringing Change Management into an Agile environment, whether at an organisational level or business-processes level, play into the hands of some Agile myths which we feel are worth debunking. 

Perhaps the greatest challenge is the tendency to be less strategic and planful about the necessary process of getting people to adopt new solutions.  From our discussion with clients, this is driven by 2 common Agile myths

• • Less process – i.e. with Agile there is less of a need for a structured Change Management process. What we see in practice is that leaders and their teams are exposed to change solutions earlier, with engagement and potential disruption being more immediate and constant. Our clients are finding that Agile requires Change management that supports more people engagement and that is an accessible risk dashboard for the people side of change – ensuring that these iterative sprints can be assimilated by individuals and the organisation.
    
    
  • Less architecture – i.e. with Agile there is less opportunity to formalise and integrate change management templates and tools are less useful. We don’t see the lack of architecture argument in our client work, but what is evident is that time taken to start from scratch and re-invent change management plans is the enemy of Agility.  Our clients are calling for change plans that can be designed quickly and are easy to modify as needed.  Our clients are asking for more data, on a just-in-time basis, to help them quickly capture new project realities and challenges to help decision-making and dynamic iteration.
    
    

How organisational level and process level Agile differ

At an organisational level, Agile Change Management is institutional. 

• It is a core competency; Change Management skills are an integral part of leader & manager development, and consistent role-based practices and tools are adopted throughout the organisation, it is baked into the culture as “the way things are done around here”.
  
  
• People’s capacity and limits to changing successfully is a key metric of strategic decision-making; even the best Change Management processes will struggle to get traction if people are overwhelmed by the sheer volume of change.
  
  
• It is everyone’s business; enterprise-level capability is easy and quick to build; cross-functional teams can be mobilised cost-effectively and without geographical limitation.

At a development process level, Agile Change Management is adaptive and flexible.

It starts with the basics; after all, change management is still about standing in the shoes of people who need to adopt new solutions and putting a plan together to get them there.  Thereafter, it is about:

• letting go of “perfect” and feeling confident about where to relax and flex.
• getting off to a quick start and being ready to refine and re-focus as solutions evolve
• facilitating more conversation, earlier and being more precise about the issues and requirements
• knowing how to respond to new information about what’s happening in the moment

What is clear is that the requirements and demand of Agile development processes mean that organisations need more Change Management not less, but change management must become Agile too.  Project delivery and people adoption must have a harmonious rhythm and pace if the benefits of Agile are to be realised.