Contents

• The Epic
• User Story 6.1: Draft a Presentation
• User Story 6.2: Approve the Presentation
• User Story 6.3: Deliver the Presentation
• User Story 6.4: Communicate Leader Commitments

---

The Epic

As the change sponsor, I want organizational leaders to understand the full implications and benefits of Agile for their functions, so they assist with instead of resist the change.

As you discussed with the sponsor in US 2.2 (I hope), they will take a more active role in this epic. In fact, they should informally start talking about Agile with their peers and bosses (the board in the case of a CEO) as soon as that story is done. See the discussion about Scrum pox for the full justification, and recall the role that top management plays in the success (or more often, failure) of organizational change projects per the Epic 2 discussion.

When stakeholder groups don’t switch to Agile themselves, they need to be willing to feed inputs or take outputs in compatible ways. Though this need not be driven from the tops of their organizations, you don’t want leaders to oppose the changes. Strong leader support will be as critical to shifting some stakeholders as having a strong sponsor for the entire project, for the same reasons. Potential sources of stakeholder resistance should become clear during the organizational readiness analysis (Epic 3).

The key deliverable of this epic is a presentation to the “leadership team.” If the sponsor is the top leader in your organization—not necessarily the enterprise, though that’s preferable—this means that person’s direct reports. Otherwise, it refers to the sponsor’s peers and supervisor. As you may expect, this is the next “make or break” epic in the process. At the very least, top leaders must agree on whether to allow the investigation to go forward, and if an Agile system is adopted, not to interfere in the project long enough for any rollback decision to be made based on the measurable objectives from Epic 4 (rather than the inevitable subjective complaints they will hear in the early stages).

User Story 6.1: Draft a Presentation

As the change leader, I want to create a draft presentation on Agile for input from the change sponsor and agents, to craft a message that will create leadership support.

For an example, and some slides applicable to any Agile system (though others aren’t), download the FuSca Proposal Slides deck if you haven’t already. However, in approaching this story, translate the term “presentation” to the training approach that fits your organizational culture and the presenter’s preferences. Though slides are the norm, that doesn’t mean they are the best format. I prefer a few diagrams to a full deck, using a white board to add action to the talk.

Discuss whether the sponsor or leader will make the presentation, and then choose the format. In my experience the change leader usually prepares the materials either way, and the sponsor may prefer that the leader deliver it. But the sponsor must be present to press the argument.

Keep the overall time to an hour, allowing for the likelihood of a late start and at least 15 minutes for Q&A. As you prepare, you can safely assume that some in the room have only heard of Agile; most don’t really understand it; and all have heard myths. Cover at minimum:

• Agile 101.
• The causes from US 1.1 and the Why Statement.
• The biggest three to five gaps from the organizational readiness and gap analysis (Epic 3).
• The project objectives (Epic 4).
• Justification of potential changes to the org chart, membership of teams, job titles and roles, and performance evaluations.
  Note: These are likely to be the biggest source of resistance, especially among managers.
• Next steps, including a brief introduction to the Agile Transformation Backlog.
• A request for their agreement to specific behaviors, including at least:
  • Making project participation a high priority for Change Team representatives and other change agents in their organizations, and protecting the time those individuals need.
  • Engaging proactively with their reps to provide input before major decisions are made by the team—rather than vetoing them afterward—and holding those reps accountable for keeping the leaders informed.
  • Working with the change leader and Change Team to implement the recommendations for the leaders’ organizations.
  • Agreeing to have an e-mail sent from the top leader on behalf of the leadership team to the entire organization approving and supporting the project.
  • Being aware that complaints they will hear are normal in any organizational change effort, and significant time is needed for benefits to outweigh disruptions.

The intention is that leaders will hold their Change Team reps responsible for communicating and consulting with the leaders about impacts to their organizations, rather than blaming the team or change leader for any surprises. The goal is to ensure the stakeholder leader will not veto a Change Team decision after implementation nor say, “I didn’t know anything about that.”

Suggested tasks:

1. Determine whether the change leader or sponsor will make the presentation.
2. Determine the format.
3. Draft the presentation notes/text and visuals, and publish them where the change sponsor and agents can see them.
4. Schedule a meeting with the sponsor and change agents, including a link to the draft presentation and requesting written feedback from those who can’t attend.

Note in the spreadsheet that the presentation draft is the deliverable for this story. You may be able to do this and the next story in the same sprint/month, but I don’t want you to feel rushed. Take your time and get it right, because the fate of the transformation may rest on these two stories.

User Story 6.2: Approve the Presentation

As the change leader, I want consensus on the presentation among the change sponsor and agents, to ensure a persuasive message is delivered to organizational leaders.

The person delivering the final presentation will practice their delivery before the group. Then the change leader facilitates a discussion on desired changes. This is an opportunity to make mistakes, identify weaknesses, and adjust the materials and delivery for maximum impact with the help of multiple perspectives. Encourage people to play “devil’s advocate” and think like someone resistant to Agile. Even better, invite someone who is!

Suggested tasks:

1. At the meeting, deliver the presentation, read out any written comments, and facilitate consensus on changes required to the materials or delivery.
2. Update and republish the materials.

User Story 6.3: Deliver the Presentation

As the change sponsor and leader, we want to deliver the presentation on Agile to the top organizational leaders so we can address their concerns and solicit support for required changes.

It will likely be easier to get on the agenda for a regular leadership team meeting than to get everyone in the room for a special meeting. You will likely get better attendance, too, which is very valuable. Having as many of the leaders as possible hear the same information at the same time, participate in the discussion, and vitally, hear expressions of support from peers and the boss, goes a long way toward reducing rumors and resistance. In fact, you are better off delaying the presentation by a few weeks if that translates to better attendance.

Even if the sponsor gives the presentation, the change leader should attend to answer questions. Obviously in most cases the leader has deeper knowledge of Agile at this point. In my experience, much of the initial resistance comes from ignorance or misconceptions. Having ready answers and reassurances can make the difference.

The reason leadership approval is important now is that significantly more resources are about to be invested in the project, in the form of time and possibly training/coaching dollars. In the ideal case, every executive will have people in their organization taking some time away from normal work to participate on the Change Team; you need executive sponsorship to prevent lower managers from interfering in those commitments.

Make clear the leaders are not endorsing an immediate overhaul of the organization, but instead backing the switch to Agile in general. More specifically, they are approving the transformation project—like any other organization-wide change effort. The goal is not enthusiastic support (though that can happen), just leeway to prove the benefits through early wins. If the team overrides the “go” decision made in US 3.9, aim for a delay. A veto at this point kills the effort.

Sometimes leadership teams want time to think about the decision, in which case the sponsor must get further discussion and approval on the agenda for a later meeting.

Suggested tasks:

1. Have the sponsor get the presentation onto the agenda for a regular meeting of the leadership team, or schedule a separate session, with the change leader invited for that portion of the meeting.
2. During the meeting, deliver the presentation.
3. Facilitate consensus to support moving forward with the transformation, including explicit commitments from the leaders to let their people participate.
4. If objections are strong enough, agree to delay the effort indefinitely while addressing concerns.
5. After the meeting, if meeting notes are published, ensure the agreements are in them.
6. Add stories to the appropriate epic(s) to address any concerns raised.
7. If the answer was “no” or to delay, repeat the tasks from US 3.11 to communicate the decision to stakeholders, for the reasons explained in that section.

User Story 6.4: Communicate Leader Commitments

As the change sponsor, I want a public commitment from the leadership team to support the change, so all employees feel some motivation to change their behaviors.

All too often, people will agree to something during a meeting—especially in the presence of a boss or peers—only to quietly sabotage the effort by refusing to change their behaviors as required. At one client, I made the mistake of not nailing down commitments of specific behaviors from all the leaders in writing. One of them claimed he “would do what my boss tells me to do,” and then didn’t. He made a show of his team being Agile, such as putting a copy of the Agile Manifesto on his wall, yet it remained a traditional leader-directed workgroup. For reasons I still don’t understand, I couldn’t get his boss to force a change. I think the guy had something on him. (That’s a joke… mostly.)

Beyond that, well-intended people can easily misremember earlier decisions or have differing perspectives on what was decided—hence the creation and approval of meeting minutes or notes in well-facilitated meetings. (In Scrum meetings these are primarily captured within user stories.)

In this case, you are going to put into writing the agreements made by the leaders, in a public way, to make it easier for the sponsor to apply pressure if anyone begins to stray. Per the related agreements in US 6.1, you will draft an e-mail or memo (if some workers don’t have e-mail) with all of the agreements in that story, plus the Why Statement and project objectives. As described under that story, the top leader will send it out on behalf of the leadership team. Hopefully the executive will choose to run it by the other leaders before sending. Regardless, the sponsor needs to apply as much pressure on the top leader as the sponsor can get away with until the message goes out.

Suggested steps:

1. Craft an e-mail or memo specifying the decision and including specific agreements.
2. Send the draft to the top leader, requesting that their version of it be sent out by the end of the current sprint.
3. Address any concerns raised, repeating relevant parts of US 6.3 and the previous tasks in this story if necessary.
4. After the messages goes out, publish a copy.

↑ A Process for Agile Transformation | ← Epic 5 | → Epic 7