Due to rapid changes in business needs, many organizations have adopted agile software development processes rather than the traditional waterfall model. Agile projects are organized around a series of iterative “sprints”—brief development cycles typically lasting two to four weeks—that enable teams to deliver incremental value quickly and adapt to evolving requirements. The business is asked to continuously identify and prioritize needed functionality, and development groups execute these smaller packages of functionality and deliver quickly. This method allows a business to quickly adapt to new requirements from customers and new ways of doing business.
However, agile development can present challenges for a business from a change management perspective. Change management works to ensure that users are prepared for upcoming changes through regular communication and engagement. Because of the rapid pace of agile development, it can be difficult to keep stakeholders fully informed about upcoming changes and their impact on the business. Agile projects can include regular changes to requirements and rapid changes in direction of development.
When using agile methods on a large project like an enterprise resource planning (ERP) implementation, stakeholders may struggle with the lack of an overall project plan that identifies a schedule for detailed deliverables. The constant adjustments throughout a development project can leave stakeholders exhausted by change even before a fully functioning system is delivered.
It can also be challenging to assess an organization’s readiness for change when the exact nature of that change is yet to be fully understood, a hallmark of agile iterative development.
How Change Management Can Help
Agile delivery is still new to many people, so change management efforts have a huge role to play in educating team members about the process. With traditional waterfall development processes that are widely understood, change management effortscan be used to align on the “what” of delivery rather than the “how.” Communication, engagement and training activities would focus on the product being delivered and how that integrated with business process and operations, with the assumption that everyone understood the mechanics of the project plan and execution. With agile, business and development teams will need additional support to understand how to adapt their operations to participate in agile development sprints and deliveries.
During a series of ERP implementations at newly-acquired companies, we established a routine of bringing the development team together with the business team at the project initiation to give an “Agile 101” introduction to agile development processes.
Starting everyone from the same baseline understanding of how the project would be executed proved invaluable to the teams.
Change management staff need to adopt agile practices as well, folding change activities into each development sprint and working to integrate more regular and rapid feedback loops into their processes. Teams will likely need help adapting to a world where developmental activities are planned only days or weeks ahead, rather than months ahead.
On a recent Manufacturing Execution System (MES) implementation, the change manager focused on performing regular one-on-one check-ins with stakeholders, targeting people in areas specifically impacted by recent sprint’s development activities. This allowed the change manager to keep a pulse on how individual teams were adapting to the rapid pace of agile development.
Change managers should continue to do larger, longer-term activities such as workshops, newsletter and intranet articles, etc. But it’s also important to look for more quick-hit activities like regular updates via Teams and short video or audio updates delivered via social channels.
Special focus should be given to assessing change fatigue within the project team. If a given development team or business area is struggling to keep up with the pace of change in an agile project, it’s okay to take a pause and hold off on new development for that area. This requires close coordination between the business and development teams, but since development teams rely heavily on business involvement, it’s to everyone’s benefit that each team participating in the process is working at full effectiveness. Agile processes support rapid changes in development priorities, so it’s important to remember this can mean deprioritizing and slowing down on some items, not just speeding everything up!
Finally, remember that a huge part of the agile development process is learning as you go. Be sure to build in time to do retrospective reviews of your change management efforts and adapt your processes for future sprints. It can be tempting to wait until large chunks of functionality are delivered before looking back. As always with agile, though, the focus should be on smaller, more rapid iterations.
During the aforementioned ERP implementations, we made sure to include the business team in each two-week sprint retrospective and had a discussion of business issues on the agenda as well as development issues.
