- Creating an Agile Change Management definition to work from
- Challenges for Change Management including the emergence of Agile myths
- How organizational level and process level Agile differ
In other posts in our Agile Change Management series, we explored some of the background to Agile as an approach including:
- Why Agile organizations 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.
So, what is Agile Change Management - and how do we go about creating a useful definition for us?
Creating an Agile Change Management definition to work from
A good starting point is to consider the two levels of Agile that organizations are working on right now, namely:
- Agile at the organizational level
- Agile at the development processes level
Agile at an organizational level is strategic and concerned with the direction and velocity of the organization 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 organizational level demands a model of Enterprise Change Management support that is responsive and relevant to the needs of organizations 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 organization to deliver Agile at this 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. 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 organizational 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 organization.
- Less architecture – i.e. with Agile there is less opportunity to formalize 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 organizational level and process level Agile differ
At an organizational 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 organization, 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 mobilized 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 organizations 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 realized.
Read our Comprehensive Guide to Agile Change Management
To help you navigate the topic of agile successfully, we have created a single, comprehensive guide that considers: