Adapting Change Management Models to Support Agile Transformation – SolutionsIQ

In my last blog post, we explored some of the classic models and frameworks that have been used successfully in the past to deal with large organizational change initiatives, such as ADKAR and Kotter’s 8-step model. We also advocated that organizations who are undergoing Agile transformation use one of these classic change models to manage the change.

In this post we shine a light on the weaknesses of the traditional change models in the context of Agile transformation. The fundamental flaw in all of these models is that they emerged to address phase-based, sequential project management and delivery with all of its upfront planning, impractical governance constraints and long phases with little feedback and actual user input. In short, none of the traditional change management models are Agile because they were designed in a much stabler world than the one we live in today.

For the purposes of this blog, what we mean by “Agile” or “an Agile mindset” can be summed up in five separate but interwoven dimensions:

1. Iterative and Incremental
2. Transparency
3. Collaboration
4. Rapid Feedback
5. Empowerment

Now let’s imagine for a moment an organization that has successfully transformed its software organization to Agile, and has adopted and internalized these Agile values. (Please don’t be confused by the fact that we use the word “values” in this work a little differently than how that word was used in the Agile Manifesto, the work that originally inspired much of our thinking.) In this brave new world, the organization is able to release valuable working software in an almost continuous state and rapidly respond to changing conditions. As software is delivered faster than ever, new challenges emerge. Downstream from software delivery, new bottlenecks emerge in testing and deployment and upstream delays mount as software delivery waits for new requirements. The value of speeding up software delivery is lost if the rest of the value stream is still bound to stage-based, linear processes and a waterfall-like mentality. The solution is to apply the Agile principles and practices used in software development more broadly throughout the organization.

For this to happen, new stakeholders will need to begin the process of adopting an Agile mindset and practices. However traditionally trained change agents will likely not have the tool set that is needed to adaptively pivot the change program that they designed for software delivery teams to meet the emergent needs of these unanticipated stakeholders. The lack of the change agents’ ability to effectively adapt the change program limits the value that could otherwise be delivered and in some scenarios jeopardize the entire program.

The problem is, as I said above, traditional change management models were originally conceived to manage large batches of change sequentially over a long duration. However, in the same way that the world of work has been transformed by Agile to produce smaller increments of value more quickly and frequently, change management must also be adapted to work at the speed of Agile. In the example given above, traditional change agents cannot hope to effect a successful Agile transformation without transforming themselves to become Agile. Before they can help others undergo the necessary personal and interpersonal transformations that will ensure the longevity and success of the Agile organization, change management practices and indeed the traditional mindset guiding them must first become Agile. The place to start, then, is with the models themselves, though not any particular one.

This blog post looks into how we can make change management models more Iterative and Incremental. We will explore some of the other Agile concepts and how they can be brought into change management models in future blog posts.

Iterative and Incremental

To understand the benefit of combining iterative and incremental, we have to understand the constituents. Steven Thomas has an excellent blog post that compares the “iterative”, “incremental” and “iterative and incremental” processes using painting the Mona Lisa as an example.

Using an iterative approach you create a work (for example, the Mona Lisa) through a process of continuous elaboration: starting with a prototype, then a rough design, then a more detailed draft, and so forth, until the entire picture is completed. An i ncremental approach instead works on completing one section at a time (for example, the upper left corner of the Mona Lisa) before moving onto another section of the picture (for example, the upper middle section), before moving onto the next section, and the next until you complete the entire picture. The two approaches complement each other when combined. With the iterative and incremental approach, you would prototype the entire picture while also working to deliver a small increment of value. For example, you may need to sketch out the entire picture so you see how the parts work together (like setting up software architecture). But you can also focus on painting a complete increment of value so that your fans (i.e., customers) have something that they can put to use and appreciate quickly (e.g., a new product feature).

What is Iterative and Incremental Change Management?

How might change management shift to be more iterative and incremental? The iterative aspect would be laying down a rough framework for the change, with rough estimates of how long certain organizational shifts might take and that also acknowledge that people are dynamic creatures who change at individual paces and intensities. Traditional change management models, designed to riff off of waterfall processes, had big upfront plans that were simply rolled out, the assumption being that people would just change because they were told to. An Agile model would instead plot out a rough map of the transformation required for an Agile mindset to take root and flourish, with nearer-term goals more clearly defined that farther-term ones. In terms of increments of value, change agents should focus on delivering a single increment of valuable change. For example, each sprint may have a mindset theme, such as transparency, and the change agent(s) can focus on ways that the team can measurably and visibly improve transparency, for example through visible work boards. In this example, the change organization can outline the long-term goals of long-lasting, sustainable change at the individual, group (e.g., team, department) and enterprise levels while also demonstrating the ability to instantiate some Agile change at the individual and/or group level. The overall change roadmap could be projected to take a year, but only Q1’s goals would be decently detailed, with only the first month’s goals actually broken down into user stories.

A further example of how an organization might apply the concepts of iterative and incremental to their change management would be by using a backlog to track and prioritize change activities. We could be iterative by having a series of related change activities on a backlog oriented around some of the early aspects of ADKAR, such as awareness and desire, while later items on the backlog might be oriented around knowledge, ability and reinforcement. Likewise the concept of incremental could be used by going through a sequence of iterations of ADKAR for different parts of the organization. Maybe we would first iterate on an increment of change through the Northeast region, followed by a series of backlog items for an increment of change through the Europe region.

Two increments of change management iteration

Agile Change Patterns

The question still stands: how does the Agile team interface and interact and thus benefit from the change agent(s). I have seen two distinct patterns used with some success, namely Synchronized Agile Change Management and Embedded Agile Change Management.

Synchronized Agile Change Management

The first pattern I’ve observed, I would describe as Synchronized Agile Change Management. In this pattern, we create a separate team of change management specialists who operate like their own Scrum team and work off their own distinct backlog of change management activities, and their release plan is synchronized with the release plans of the set of Agile teams they support. The stories on their backlog would likely have relationships to specific user stories on the backlogs of each of the individual Scrum teams and during release planning we would ensure that the change management backlog is synchronized to the Scrum team backlogs. Essentially the change management team, being a downstream consumer of the work being produced by the Agile team, has to do their change management work often a sprint in arrears, before the software can be released to users. This pattern might be the easiest to use to start out, and it’s quite similar to the pattern that many organizations were using for QA in early attempts at scaled Agile. One criticism of this pattern is that it introduces a handoff from Scrum teams to a separate Change Management team, thus introducing a time lag from when the Scrum team does the work to when the work is “done done.” This could be introducing some waste in the system with the delay and handoff. In some organizations, however, due to having a scarce set of talented and credentialed change management professionals, this might be the only feasible option in the short term.

Embedded Agile Change Management

The second pattern I’ve observed I would describe as Embedded Agile Change Management. In this pattern, we strive for one truly cross-functional team, and we embed the necessary change management skills and disciplines directly into the Scrum team itself. At first it might be that we have a dedicated change management professional working on each Agile team, or less desirably they could be shared across teams, provided each team has a designated change management professional. Then longer term we might start cross-training Scrum team members in the different change management skills so that eventually the team is self-sufficient again (i.e., not relying on external stakeholders to deliver value). This is a more desirable pattern because it empowers the Scrum team with all the necessary change management skills and it does not introduce any further handoffs downstream allowing the team to strive towards delivering truly shippable value at the end of the iteration. However this is a future state that will probably take much higher degree of investment and time to achieve.

Summary

Traditional change management frameworks were set up to be long-running, sequential processes to deal with large batches of change. Generally speaking the traditional Scrum team does not have any formal change management skills directly on the team. When organizations successfully transform to Agile, they will need to adapt these change management models to make them as Agile as their newly adopted Agile frameworks so that the organization can successfully manage the continuous flow of valuable changes that they are introducing into their environments and ecosystems. As we continue to improve our understanding and implementation of Agile change management, we will need to figure out how to provision Agile teams with the requisite change management skills either by integrating the existing change management professionals into the Agile flow of work, or by directly embedding those change management professionals onto the Agile teams.

This blog post focused on rethinking traditional change management to be iterative and incremental. This leaves other Agile values like transparency, collaboration, rapid feedback and empowerment. To learn more about these Agile values and about Agile change management in general, including proven practices SolutionsIQ consultants use in the field, watch our webinar “Leading Agile Change: Proven Change Management Approaches for Agile Transformation” presented by Dan Fuller.