Epic 5: Foster Two-Way Communications

Contents

The Epic

As change agents, we want to proactively seek input, squelch rumors, address concerns, and publicize successes, to prevent and reduce resistance throughout the project.

Photo of two co-workers seated at a table and talkingSummarizing the organizational change (OC) literature, it seems managers and agents can create resistance, primarily through A) making assumptions about employee support levels; B) failing to make personal changes they claim to support; and/or C) failing to communicate accurately or enough. Regarding A, in a study of legal firm mergers, as many as 40% of the change agents thought no employees had concerns about the merger, even though around 85% of employees did. During a plant spin-off from a manufacturing firm, managers considered it a “paper change” with no significant impact and made minimal effort to communicate with line workers. The result was high levels of cynicism and low commitment to the change among workers.[1]

In the opposite circumstance, “Management should never assume that the reason resistance… is occurring is because people don’t like change,” two researchers wrote.[2] “To object in writing to a change initiative or to stand in front of management and verbalize it is an act of courage.” This explains why you may not hear complaints, and why you should listen when you do.

Sussing out the source of resistance to change (RTC) would seem to be a primary task of change agents. Indeed, one research team wrote, “Part of the challenge for a change leader is to identify the level of resistance, identify its causes, and take action to minimize its undesirable effects…”[3]

“Ineffective communication” was found to impact 56% of projects in a 2017 PMI survey of its members,[4] the most pervasive problem on the list—and this may be an underestimate, given how much managers underestimate the extent of RTC! Two OC scientists wrote, “Intensive communication helps to rectify rumors, to preclude misunderstandings, to overcome resistance, and to dispel… fears.”[5]

Encouraging open, two-way communications is a theme running through most of these epics. This one is ranked here to emphasize that the effort must begin before the implementation. But it also must continue to the end of the project, in addition to “how-to” communications about the implementation.

Evangelize the change to all stakeholder groups with repeated communications through multiple channels, leveraging peer-to-peer conversations. Include techniques that create psychological safety for speaking out, such as forums in which higher-level managers are not present and comments are reported as anonymous summaries. Treat initial RTC as a positive form of feedback, and revisit previous decisions if resistance remains significant or patterns of comments arise. How you respond to feedback can make or break resistance. Tactics for success include: assuming RTC is based on misinformation or positive motives; responding with evidence and logic, not defensiveness; finding new ways to relay the same information; admitting “I don’t know” when you don’t; and following up when you promise answers. All go a long way toward building trust.

Once the transformation begins, monitor and broadcast performance metrics to identify potential failure points and communicate interim wins. Consider a digital Agile tool instead of wall charts to provide greater transparency and roll-up reporting. Use Scrum “demonstration ceremonies” or something similar to emphasize continuous achievements and, again, take feedback. Besides maintaining the sense of participation, this will help prevent backsliding to old behaviors. Finally, continue Epic 5 communication efforts until the “point of no return” is clearly reached, rather than assuming everyone is on board.

User Story 5.1: Create Stakeholder List

As the change sponsor and leader, we want to create an initial list of all individuals and groups who could be impacted by a change to Agile, to begin evangelizing the change as broadly as possible and prevent extra resistance.

The interface conflicts between organizations that I call “Scrum pox” can hinder or block an Agile adoption even if most people within the changing organization are supportive. It is crucial to your success to identify in advance everyone who could possibly resist the change, so you can ensure they are accounted for in later actions to prevent and reduce RTC. By itself this action reduces resistance caused by the process, exemplified by statements that “nobody told us about this” or that they were not consulted.

The spreadsheet entry for this story has a comprehensive list of stakeholder types. In general, to reiterate: A stakeholder is any individual or group who could possibly be impacted by the change. At this point, go crazy. Add as many names and roles as you can think of, because you can always combine or remove items later. One tip is to work from the bottom level up in your organization’s hierarchy to ensure you have thought of each subdivision.

Suggested tasks:

  1. Write out a list of stakeholders identifying them any way you wish: individual’s name, group/team/organization names, roles, etc.
  2. For each list item that is not an individual, add initial points of contact.
  3. Set a brief meeting with the change sponsor and send them the document.
  4. Hold the meeting and review the list.
  5. Update and publish the list.

User Story 5.2: Initiate Stakeholder Contacts

As the change leader, I want to contact all stakeholder groups and attempt to expand the stakeholder list through them, to ensure comprehensive communication as early in the transformation as possible.

This story uses the “friends of friends” concept to ensure completeness of the stakeholder list. (My friends and acquaintances experienced this approach when I was investigated for a government clearance!) There is a second motive, however, which is to get ahead of the rumor mill by giving initial notice of the Agile project to all possible stakeholders.

Contact each stakeholder or initial contact person, in person or by phone rather than relying on e-mail. Give an “elevator pitch” for Agile—as if you were an entrepreneur pitching your idea to a venture capitalist on an elevator ride. Emphasize, again, that no decision has been made other than to look into it. For groups, ask if the person would be willing to serve as the point of contact (POC) just for initial steps, and if not, for the name of someone else in their group who might be interested. In the latter case, repeat these steps as needed until you find a POC. Then show that person the stakeholder list and ask whether they can think of any individual or group not on the list that possibly should be.

Suggested tasks:

  1. Visit (in person or by phone) with each POC on the stakeholder list, explain Agile, identify another temporary POC if needed, and use the list to ask about other prospective stakeholders.
  2. If other stakeholders are identified, repeat Step 1 for each.
  3. Update and republish the list.

User Story 5.3: Create Change Project Site or Board

As the change leader, I want a stakeholder site or bulletin board available, to provide transformation progress on demand and accept comments.

Early as you can in the transformation project, make “public” (within the organization) the location you have used to publish Agile project information to the change agents and sponsor. In a document repository, you could create a section (folder, library, etc.) everyone in the organization can see, move as much of the previously private materials there as you feel comfortable sharing, and add a comments tool.

Assuming you choose a digital Agile tracker as mentioned at the top of this page, you can also give “read” or “viewer” rights to some guest accounts. If possible add a landing page for those accounts with stakeholder visuals like dashboards and charts for a quick overview of progress. Put the guest account log-in information on the project site, and you may cut down on progress-report queries.

Suggested tasks:

  1. Discuss with change agents (or the Change Team if already formed) the best way to publicize transformation project information.
  2. Set up and populate the project site or board.
  3. If digital, provide access to all stakeholders and ask one to test it.
  4. If you have a digital Agile tracker, provide and publicize guest accounts with read/view permissions, and test access.

User Story 5.4: Create a Push Communication Channel

As the change leader, I want to establish a “push” communication channel to provide regular updates and invite input.

Use a blog tool, e-mail group, and/or physical bulletin board to provide brief updates at least monthly. On a board, post memos and progress indicators, and hang an envelope off of it for suggestions.

Suggested tasks:

  1. Create a blog, document repository newsfeed, e-mail list, etc.
  2. Advertise it on the project site.
  3. Ask Change Team members to publicize the channel throughout the sprint.
  4. Post/send the first update.

User Story 5.5: Schedule and Hold Input Meetings

As the change leader, I want a schedule set for meetings to answer questions and take input.

Set up opportunities for people to speak directly with the change sponsor, leader, and/or coach. Choose times when these are easy to attend, such as lunchtimes, formal break times if applicable, or as agenda items in pre-scheduled organizational meetings. Make a few of these “line-only” meetings, with no managers present. (If you are the change leader and a manager, have a nonmanager change agent facilitate, and don’t attend.) Even if not well attended, having multiple opportunities demonstrates a willingness to listen, and if you accept complaints without defensiveness, they counteract claims that feedback was not welcome.

The frequency of these meetings can of course go down as the project progresses and other means of communication mature. Initially I would create opportunities monthly. Prior to adoption of an Agile system (Epic 9), I would exploit very opportunity I could find by adding appearances at existing meetings, including team meetings. As implementation begins, you could cut back again. If you eventually adopt a system based on Scrum, after Demos and Retros are being done by all teams, you could drop down to once a quarter. But I would not cancel them until no one is attending or the project is completed.

Suggested tasks:

  1. Schedule a series of feedback opportunities for all stakeholders, as a whole and with subsets/groups, at least one per month for three months.
  2. Hold the first session.
  3. Follow up with answers to questions you could not answer during the session.
  4. Put a copy of this story in the backlog marked for the next quarter (thus repeating this task until the project is over or no one is attending).

↑ A Process for Agile Transformation | ← Epic 4 | → Epic 6

Full references are in the Agile Transformation bibliography.

[1] Walker, Armenakis, & Bernerth 2007.

[2] Self & Schraeder 2009.

[3] Appelbaum, Degbe, MacDonald, & Nguyen-Quang 2015a.

[4] PMI 2017b.

[5] Stelzer & Mellis 1998.

Share this page