Agile Change Management

For those of us who sit at the intersection of people and computer systems and worked in the software or management consulting industries for the past 3 or 4 decades, work has offered a birds-eye view of two parallel disciplines which are only now starting to come together in earnest. While the pain of integrating these until now separate disciplines is real in the short term, the promise of their united philosophies in the long term is great indeed.

A (Very) Brief History of Change Management and Agile Development

Most Change Management methodologies were developed parallel to the day's software development practices. The modern field of Change Management can find its foundations in the psychology of change research like Kubler-Ross (1969), Connor & Kelly (1979), Bridges (1979), Conner & Patterson (1982), and Kanter (1983). But it really started to hit its stride in the 1990s with the rapid expansion of SAP R/3 and management consulting firms specializing in software implementation. Authors like Kissler (1991), Tichy (1992), Connor (1993), Kotter (1996), and Johnson (1998) helped popularize Change Management and propose methodologies for its use - many of these in partnership with management consulting firms.[i] Like most of the systems development practices of its day, they were designed around what we now call a “waterfall” approach of project management - meaning project-wide, stage-gated phases like “Plan, Analyze, Design, Build, & Test”. [ii]

The Agile project management approach is most notably traced to the Manifesto of Agile Software Development (2001),[iii] which itself built on principles of Human/User-Centered Design (Norman 1986, 1988, Cooley 1989),[iv] Usability Engineering (Whiteside and Bennet, 1988; Nielsen 1989, 1993),[v] Iterative and Incremental Development (Gilb 1976, 1981, 1985; Bloch 1983; Boehm 1985; Brook 1986; Sutherland & Schwaber 1986; McCarthy 1995; Kruchten 1996)[vi] and LEAN Manufacturing (Womack, Roos & Jones 1990, 1996)[vii] in the fields of software and product development. Each of these has roots in engineering and manufacturing design which dates back even further.

Challenges Adapting Change Methods to Agile Development

To date, there has been relatively little reinvestigation of Change management methods as applied to Agile development - and some teams today struggle to apply traditional change methodologies to Agile development projects. How can, for example, a change team document all the stakeholders impacted by a system under development if the system requirements are only developed one sprint at a time? How do we deliver training and communications with new functionality being launched every 3-week sprint? How do we find time to develop a sponsorship network, document organizational impacts or align talent systems amidst such early and continuous change to the user requirements?

If your project is truly working to define, build and launch a set of micro-user requirements in a time-boxed 3-week Sprint - then logically, that sprint should have its own set of micro-stakeholders, micro-readiness, micro-change impacts, micro-systems alignments, and micro-training requirements. Change Journey management would similarly need to align leadership, communicate to end users, and asses adoption around the experience of receiving a series of micro-product releases over time. Training would need to be delivered in small groups every three weeks.

What is Agile Change Management?

If change management is to adjust to Agile development processes, then the goals of change management must be reinterpreted in light of Agile principles. Therefore, we might restate the goals of change management like this:

The 12 Principles of Agile Change Management

1. Our highest priority is to satisfy the customer through early and continuous adoption of valuable software
2. Welcoming changing requirements, even late in the development cycle, change management processes continuously communicate how these changes improve the customer’s competitive advantage
3. Supporting the adoption of working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale
4. Change people, business people, and developers must work together daily throughout the project
5. Build methods to motivate project members and stakeholders. Give them the environment and support they need and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a stakeholder/end-user community is face-to-face conversation (with someone they trust)
7. Fully adopted software is the primary measure of progress
8. Change Management processes promote sustainable adoption. The sponsors, developers, and users should be able to maintain a constant pace of adoption indefinitely.
9. Continued attention to technical education and good communication enhances adoption
10. Simplicity- the art of maximizing the work not done-is essential for both teams and stakeholders
11. The best education, communication, and adoption emerge from self-organizing teams
12. At regular intervals, the team (and stakeholder) reflects on how to become more effective, then turns and adjusts its behavior accordingly

With these new principles in mind, let us revisit some of the challenges highlighted above.

Communications. If I deploy communications to prepare and raise awareness of an upcoming Sprint release to its end users, and only the end users of this sprint - it is possible that some end users would be affected by multiple sprint releases. By extension, they would receive a steady stream of communications for each sprint release. Pending the audience, some might find that repetition distracting or annoying. Imagine sending scores of repetitive emails to a physician or Sr executive. Creative techniques might need to be employed, such as a one-time email link or a desktop icon linked to a website whose announcements are updated on a regular basis.

Change Network. Building a robust champion network by first aligning leaders and then cascading sponsorship down through change champions, change agents, and power users will be significantly hampered by Agile’s rapid and continuous deployment schedule. Networks will need to either be significantly modularized or flattened. By modularized, we mean identifying just the line of sponsorship associated with each sprint’s requirements - likely bringing them all on board simultaneously or nearly so. By flattening, we mean bringing critical champions and agents directly onto the development and testing team. Agile change management often works best when each end-user community (and by this, I mean 1 per working group) is embedded in the design team and continuously conducting 2-way communications with the group they represent. This both improves the HCD inherent in Agile processes and facilitates adoption by allowing each end user to be only 1 trusted person separated from the Agile project itself.

Change Impacts. One of the most important lessons of Agile change management is embedding change impacts directly into sprint development. Often in waterfall projects, the documentation of change impacts is achieved separately from the design process itself - when a change team member either interviews design team members or reviews design documentation as a separate, secondary process - in parallel to or often after the design meetings and decisions are made. Once documented, review by a design team member for accuracy is often required. For Agile development, Change impacts should be captured as part of the user story requirement documentation. This can either be achieved by embedding a Change person in each design discussion or by including change impacts in the requirement definition itself, subject to verification by a Change person. For example.

User Story

• As a <stakeholder>, I need <requirement> so I can <benefit>.

With change impact capture

• This is/is not a change in who performs this task, it was previously performed by <past owner>
• This is/is not a change in process; previously <old process>
• This is/is not an automation of a manual process that previously took <old effort>

With such change impact capture, the Change team reviews all user stories for change documentation. A best practice would add the requirement that no user story cannot be marked complete without it. This turns the standard process on its head by making the change person the reviewer rather than the design team member.

Summaries of change impacts by role or processes simply become a matter of extraction, filtering, and sorting. Impacts can be quantified to communicate the value driven by the project or each sprint.

Organization and Talents System Alignment. The organizational and talent systems alignment piece may be of particular challenge. An agile project working independently of other systems (say a phone app or website) might be able to proceed as it sees fit, but an Agile project that interfaces with other systems following a waterfall project management paradigm (say an internal HR or finance system) might find it more challenging. It is likely the waterfall system will continuously ask for roadmaps, data, requirements, and other information that is comprehensive, so they can tackle all the implications at once.

Similarly, deeply embedded talent processes and policies like performance management, staffing, recruiting, or organization design may find it difficult to adjust itself piecemeal. Can you imagine changing the performance management or reward policies for just some employees in a department or company? To be sure, not all Agile projects have such systemic impacts. But some do.

Addressing these implications may require some creative approaches. In some cases, the project ‘Steering Committee’ may need to be broadened to include adjacent groups, which may need to continuously monitor the implications coming out of a new project. Change impact documentation may need to be broadened to include more systemic issues than just changes in job responsibilities and processes. In other cases, talent systems themselves may need to change to become more adaptive and iterative, such as with skills-based talent systems.

Training Needs. As highlighted above, re-sorting change impacts by the affected person, role, or persona can quickly develop a first draft of role-based training needs. The more challenging task is to determine how best to organize the training schedule and curriculum, given the inevitable overlap of change impacts to a given person/role across multiple sprints. And then making time for training build amidst that schedule.

Training Delivery. If a system of any significant size requires training a large audience across the organization being taken away from work (as most training does) - managers will likely ask for the comprehensive training requirements being asked of them so they can schedule training for their resources that is minimally disruptive to their work. Taking small groups of employees off the line for short bursts of training spread over time can be more disruptive than planning for everyone to have a pre-planned training day - pending the group involved and the type of training. The same can be true of instructors. For example,

• Physicians being trained to live and hands-on with a new EMR system may find it easier to find a replacement to see their patients for a day than to walk over to the hospital training center in 2 hr. increments several times over several days.
• Similarly, if the instructor is a rarified expert or an executive delivering ‘leader-led’ training - the instructor’s time could be at a premium.

Training deployed “in the flow of work” may be helpful where possible. This could include virtual or digital training delivered in bit-sized chunks on demand. Alternatively, it could involve more hands-on methods delivered on the job. In yet a third scenario, adaptive learning could allow users to skip past modules they already know or have taken. In some cases, training schedules may need to be maximally flexible for the students, even if offered at the expense of offering the same training multiple times or in multiple locations. Conversely, training may need to be delivered in a way that is maximally convenient for the instructor, even if at the expense of a preferred method of delivery. For smaller audiences, hands-on training might be accomplished by including most of the affected end-users in User Acceptance testing. Whatever the solution, different (more Agile) methods of training delivery must be explored.

Conclusion

In most cases, traditional change management methodologies have been developed with waterfall-based assumptions and need to be modified creatively to support Agile development. The good news, this adjustment can be managed like any other the Change team deals with. In truth, the philosophies of both Agile and Change Management are both very human/user-focused and quite complimentary. All that is required is a little creativity and discipline to make our change more agile.

‍

End Notes

[i] https://www.prosci.com/resources/articles/change-management-history-and-future

[ii] https://www.cmcpartnership.sg/blog/the-evolution-of-change-management;

https://en.wikipedia.org/wiki/Change_management

[iii] https://en.wikipedia.org/wiki/Agile_software_development

[iv] https://en.wikipedia.org/wiki/Human-centered_design; https://en.wikipedia.org/wiki/User-centered_design

[v] https://www.interaction-design.org/literature/topics/usability-engineering

[vi] https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf

[vii] https://www.lean.org/explore-lean/a-brief-history-of-lean/