The Agile Approach to Change Management

By Myles Bogner and David Elfanbaum  |  Posted 2011-04-06

Agile software development is designed to thrive within even the most dynamic business and technical environments. In fact, according to an article on the Website of Martin Fowler (, an agile industry leader, the name “agile” was chosen because its creators viewed “adaptiveness and response to change” as the most essential concept of the methodology.

All agile methodologies include integrated practices and processes that manage evolving requirements to efficiently develop a continuous stream of new software capabilities. However, agile does not address changes related to enterprise support of the agile process or tasks that fall outside the scope of the project work. These include how to:
• effectively manage internal personnel so appropriate stakeholders are available throughout the project;
• gather and prioritize the most important features desired by the organization throughout the development cycle;
• adjust the notion of ongoing training in a continuous release environment;
• ensure customer team members are informed by the full breadth of stakeholders needed for enterprise acceptance;
• secure timely approval of new technologies that a team would like to leverage; and
• address stakeholder discomfort with cultural, business, social or other changes related to software implementation.

Each of these challenges is compounded when organizations operate multiple agile projects simultaneously. Such unaddressed issues can cause an IT project to ultimately fail, even if it meets all project acceptance tests and is executed perfectly within the scope of the development team.

Enterprise change management provides a framework to address many missing factors. Here we focus on how organizations can leverage ECM practices in conjunction with their agile development teams to foster IT delivery adoption.

Communicate a Vision of Change

In the book The Heart of Change, co-authors John Kotter, the Konosuke Matsushita Professor of Leadership, Emeritus, at the Harvard Business School, and consultant Dan Cohen, view the core pattern associated with successful change as “see-feel-change.” To move stakeholders from negative thoughts, an ECM program must communicate a vision of the change that is compelling enough to both overcome negative preconceptions and motivate positive participation.

Some IT and project managers tend to treat people who will be affected by software initiatives as if they were Vulcans, not humans. Of course, most individuals are more like Kirk than they are like Spock: They don’t rationally evaluate information and form impressions based solely on logic. Instead of withholding judgment on an impending change—such as a new software initiative—people tend to make gut-level intuitive leaps that are often negative and resistant.

In Switch: How to Change Things When Change Is Hard, authors Chip and Dan Heath use the metaphor of “Rider, Elephant and Path” to describe three primary areas that must be addressed in change management.

The Rider is our inner Spock. A stakeholder cannot support a change until he or she can understand its purpose, as well as the concrete changes that will likely occur. The 50-page technical documents and 100-element flowcharts that developers often create must be translated into clear, high-level infographics for nontechnical people.

The Elephant represents our subconscious and emotional levels. ECM can influence the elephant through communications that create positive feelings and mitigate negative emotions, such as mistrust, anxiety and anger. For instance, messaging may focus on how the change will solve an existing problem that vexes stakeholders.

The Path addresses the environment in which the change occurs. These include alterations to the physical environment (such as the arrangement of office space) and processes or procedures (such as Kanban, a just-in-time production concept).

There are a number of formalized ECM models that have been developed to standardize change management within organizations, with processes and practices that support the entire lifecycle of a change initiative. The principles and activities described in this article can be adapted to any existing corporate ECM infrastructure. They can also be applied in organizations that do not yet have an ECM process.

Ironically, the more successful an agile project is in rapidly developing new capabilities, the greater the ECM challenge may be. Although agile’s customer-led iterative approach significantly reduces the magnitude of changes related to each software release, it greatly increases their frequency. Instead of having to adapt to a single release with a significant number of changes created within the waterfall sequential design process (typically with multiyear release cycles), stakeholders must deal with a series of small, incremental releases every month or two.

Having an ECM program is especially important for enterprises transitioning to agile from a phase-based development methodology. Corporate cultures that are accustomed to traditional development release cycles can be strained by a shift to more frequent releases and the higher level of stake-holder involvement required throughout the process.

The impact of a new agile implementation cuts across technology and functional groups, from top management down to the frontline worker. An ECM effort can help break down the sensation of feeling burdened that’s caused by the need for day-to-day customer involvement.

Introducing basic ECM concepts to an agile team can actualize the potential of existing agile practices to foster positive change. For instance, customer-focused user stories and acceptance tests can be informed by ECM considerations.

This new perspective can tangibly improve the way the IT and business sides of an organization work together. The resulting synergies build a heightened level of trust and provide a means to measure and track the success of both the technical quality of software and its acceptance by users.

If the customer already has an institutionalized change-management practice, bringing ECM personnel into the agile team’s release-planning process is a good first step. They will be able to anticipate potential change-management issues related to a release and work with the team to synchronize their efforts. For customers that are transitioning to agile from a traditional waterfall methodology, ECM involvement is a good tool to foster participation by business stakeholders.

Integrating ECM With Agile

When an organization is ready to integrate ECM tasks into an agile software development project, securing an ECM subject-matter expert is the first challenge usually faced. If the organization has existing ECM expertise, those people can be added to the agile team. If there are no available resources, it might be necessary to hire an ECM subject-matter expert or send an existing team member through an ECM training program.

Once staffed, a basic approach is to integrate ECM into the agile development process by having ECM requirements go through the same processes as technical requirements, including user stories, acceptance tests and the iterative development of deliverables. ECM team members and developers take part in the same customer planning meetings and presentations.

Take, for example, the implementation of a portion of a typical change-management plan. In conjunction with an upcoming agile software release, requirements might include:
• creating a stakeholder list;
• creating a series of surveys on stakeholder attitudes; and
• contacting these stakeholders and socializing the results.

Tasks required for the delivery of iteration can then be broken down into stories, such as:
• making a list of stakeholders in a certain business group;
• creating a survey covering these specific questions; and
• creating an analysis spreadsheet.

Creating ECM stories in the same manner as their development tasks integrates change management into the agile process. In fact, these stories can be created in a test-driven development manner. For the above story examples, a test could be written proving that:
• a stakeholder from the business group is included in the stakeholder list;
• a survey covers a specific required content item; and
• the analysis spreadsheet has a correct column.

At the start of each iteration, these tests would initially fail, but they would begin to pass as the change-management stories were fulfilled.

ECM tests and their pass/fail state can be illustrated on the agile team’s continuous integration dashboards. Making these dashboards available organizationwide gives all stakeholders maximum insight into team’s overall progress to heighten project awareness across the enterprise.

By integrating ECM into agile development, the team can escape the project stovepipe and extend its vision to the entire enterprise. Although ECM does not give the project team absolute control over its destiny, it can substantively expand the domain of its influence.

Myles Bogner is vice president of Research and Development for Asynchrony Solutions, an IT consulting firm. David Elfanbaum is co-founder of Asynchrony Solutions and recently ditched his vice president of marketing title in favor of “Geek Interpreter Guy.”