Part 2 of 3: Being Flexible When Navigating Agile Changes

Recently, while thinking about multi-year rapid release plans, and all the many considerations that go into them, I was reminded of being a kid and the week-long, summer road trips I would take with my family. Before the trip would begin, I was given a vision statement (e.g., “We are going to Disneyland”) and some tools (e.g., crayons and a coloring book) to support my journey. Like any Agile development team lead, my mom determined how we would get to our destination one stop at a time and adjust the route depending on weather, traffic, and distance to gas stations. With so many variables, it was impossible to create a reliable roadmap and a meaningful support plan.  

And while I had my support tool crayons in hand to get me through the drive, I was reminded by the support tools of trips past — melted into the seat next to me — that a one-size-fits-all change approach is a recipe for failure. Each trip was different, just like each Agile release is different, and therefore needs a different approach. A release aimed at only one to three people should need minimal change support if they are involved in the design, user stories, testing, and demos. However, if a release is targeting 50+ people, and the change impact has multiple aspects to it, then the support needed will be more significant and the deliverables much more comprehensive.  

Lead Agile roles, such as product owners, may plan which features get developed over time, but it is the development team that determines how it will be built and used, along with when it will be ready to implement. That means, from a change management perspective, that key pieces of information needed in a standard change plan are not known until the development team actually starts building. A change manager cannot prepare users for the totality of the change if they don’t know what the change will look like; they only know that there will be a change to a particular group and process. 

Some change managers will utilize the ADKAR® Model, created by Prosci founder Jeff Hiatt, which represents the five tangible and concrete outcomes that people need to achieve for lasting change: Awareness, Desire, Knowledge, Ability, and Reinforcement. From this perspective, “Awareness” and “Desire” can be achieved early on, but it’s only immediately prior to, or sometimes even during, the sprint build phase that a change manager can begin to create “Knowledge” and “Ability.” That gives change managers very little time to prepare end users for what’s coming. 

Those family road trips also got me thinking about how difficult it is to maintain a sense of urgency over an extended period of time. At the beginning of every trip, I would be so excited I could barely contain it, but as each mile blurred into the next, and I could no longer tell how far we had come, or how much further we had to go, my excitement would fade. It wasn’t until I could see actual proof that we were getting close to reaching our destination that I would allow myself to get excited again. This is a common struggle for those who find themselves in rapid release environments.  

Maintaining excitement and keeping people motivated with a “burning platform” during the duration of a multi-year, rapid release project is very difficult, especially when little to no progress is noticeable from an individual employee’s point of view. Individuals may be told that their jobs will be changing as part of an initiative, but if their area of work isn’t predicted to be in scope for a while, then they can easily feel forgotten, start to believe that the project isn’t a priority, or even convince others that the change isn’t going to stick. 

There are a few ways, however, a change manager can overcome these issues. The first is with transparent communications. I know, I know, change managers are always saying communication is the answer. Well, that’s because it almost always is. In this case, it’s about communicating the information that is known, along with what is unknown, when it will be known, and then showing progress. This involves restructuring change management deliverables and activities to align with the information that is available at the time. Below are some examples of how change activities can be organized based on each rapid release phase.  

Activities and Deliverables to Support Rapid Release Development Phases 

Rapid Release Initiative 

• Create awareness and desire for the overall initiative changes throughout the company 
• Articulate the vision  
• Define success 
• Communicate progress to the organization 
• Detail a governance plan 
• Develop an overall adoption plan 
• Deliver change and transition trainings for employees and leaders 

Rapid Release Themes 

• Identify targeted stakeholders 
• Create awareness and desire of the current focus with the affected stakeholders 
• Communicate the theme vision  

Rapid Release Epics 

• Create awareness and desire for the upcoming changes with the affected stakeholders 
• Create awareness for how the epic supports the theme and goal 
• Develop desire for future state capabilities 
• Create a stakeholder analysis with general timing 
• Build initial high–level gap analysis between as–is and to-be capabilities  
• Analyze high–level impacts 
• Plan for training and reinforcement  

Rapid Release Releases 

• Create awareness and desire for the specific changes with the affected stakeholders 
• Build knowledge around what users need to do differently  
• Develop abilities to use and support the change 
• Develop training  
• Implement reinforcement plan 

As I briefly described in my introductory blog on this subject, the next blog in this series will explore another aspect of change management for rapid releases that is often overlooked – Agile maturity.