11 Proven Stakeholder Communication Tactics during an Agile Transition

TL; DR: 11 Proven Stakeholder Communication Tactics

Stakeholder communication: It is simply not enough for an agile product development organization to create great code and ship the resulting product like a clockwork. It would help if you also talked about it, particularly at the beginning of your endeavor to becoming a learning organization. Marketing your journey to the rest of the organization—and thus securing their support, collaboration, and buy-in—is a critical success factor to step up the transformation game: You want to become agile, not “do agile.”

Learn more about eleven proven stakeholder communications tactics that contribute to making this happen.

🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.

Stakeholder Communication Channels During an Agile Transition

Do good and talk about it—a simple necessity, mainly if your agile transition is supposed to be embraced by the whole organization over time. Deciding early on how to communicate with internal stakeholders and win their proverbial hearts & minds often makes the difference between “doing agile” and “becoming agile” in the end.

Keep in mind that many stakeholder egos, their statuses within the organization, their remuneration, and personal agendas are tied one way or another to executing “a plan.” And now you’re trying to sell them that quitting this plan will turn out to be mutually beneficial—if they trust the product development entity’s ambition to develop into an agile, learning, customer-centric organization.

Run a quick mental exercise: Try walking in your stakeholders’ shoes, and ask yourself: Would you entrust your career a bunch of hoodie-wearing nerds, promising a big reward because they are practicing XP and Scrum?

Developing empathy for stakeholders is particularly relevant, when Engineering and Product don’t have the best standing within the organization at the beginning of an agile transition. The good news is, that no matter whether both are perceived as a black hole by others, a well-orchestrated communication strategy has a good chance to win over the rest of the organization.

Cannot see the subscription form?
Please click here

Proven Stakeholder Communication Tactics

Judging by my experience, the following stakeholder communication tactics have proven useful, if actively pursued from the beginning. They all share a similar approach: provide complete transparency to allow for inspection and adaptation by your stakeholders, thus fostering inclusion and giving everyone a voice:

I. Scrum Events

There are plenty of opportunities for stakeholders to interact responsibly with a Scrum Team. The two formal Scrum events that come to mind are:

Sprint Reviews

The Sprint Review is Empiricism at work: inspect the Product Increment and adapt the Product Backlog. The Development Team, the Product Owner, and the stakeholders need to figure out whether they are still on track delivering value to customers. It is the best moment to create or reaffirm the shared understanding among all participants whether the Product Backlog is still reflecting the best use of the Scrum Team’s resources, thus maximizing the value delivered to customers. It is also because of this context that calling the Sprint Review a “sprint demo” does not match its importance for the effectiveness of the Scrum Team.

The cadence of this event depends on the Sprint length of your Scrum Teams, which is influenced, for example, by your product, your market, governance requirements, if the Scrum Teams’ Sprints are aligned, or whether they are practicing continuous delivery anyway.

A too frequent Sprint Review, for example, every week, tends to wear off quickly, as not much novelty can be provided. (Except you’ve just started building something from scratch, then a weekly Sprint Review is great for team-building and alignment across the organization, thus creating a common spirit. It would help if you celebrated every victory.)

The basic rules of stakeholder communication with Sprint Reviews are simple:

• Educate the stakeholder on the importance of their collaboration.
• Lead by example: The engineering and product team should be present. Why would stakeholders invest their time, if your buddies don’t consider the Sprint Review a worthwhile investment of their own time?
• Show, don’t tell. Sprint Reviews are a zone free from death by PowerPoint.
• Invite stakeholders to take the helm.
• Keep it short and exciting. Using Liberating Structures to design a Sprint Reviews have proven time and again very helpful in including all and giving everyone a voice.
• Initially, it might be required to lure stakeholders to the Sprint Review if they do not yet fully understand the importance of the event. Bribe them, if you have to: Giving a few stories points away during the Review to those who attend and can present a convincing issue works well. (But don’t make this hack a habit.)
• Of course, Sprint Reviews also work well with distributed teams in a virtual setting.
• Avoid typical Sprint Review anti-patterns.

Daily Scrums

Invite stakeholders to the Daily Scrums, once the Development Teams feel comfortable with the idea, to passively participate. Be warned, though, that you need to be firm in dealing with assertive stakeholders, who otherwise might try to take over the Daily Scrum and turn it into a reporting session. If a Development Team does not warm up to the idea, restrain yourself from ignoring their decision. After all, a Daily Scrum belongs to the Development Team.

Stakeholder Retrospectives

In a regular cadence—probably once a quarter—offer a joined meta-level Retrospective that includes the stakeholders.

A meta-retrospective is an excellent exercise to foster collaboration within the extended team, create a shared understanding of the big picture, and immediately create valuable action-items. It comprises of the team members of one or several product teams—or representatives from those—and the stakeholders. Participants from the stakeholder side are people from the business as well as customers.

Learn more: The Meta-Retrospective — How To Get Customers and Stakeholders Onboard.

II. Stakeholder Communication by Educational Initiatives

Aggregate Information in Dashboards

“When you put problem in a computer, box hide answer. Problem must be visible!” (Hideshi Yokoi, former President of the Toyota Production System Support Center in Erlanger, Kentucky, USA.)

In that spirit, be transparent with all information, but visualize it in a way that stakeholders can actually make sense of it. (Often referred to in an agile context as “information radiators.”)

Usually, it is more helpful to aggregate information across teams in a sort of stakeholder dashboard than having a board for each team. (Tracking the movement of sub-tasks, for example, normally proves to be too granular for stakeholders.)

The advantages are plenty: Stakeholders rarely read reports, but they are willing to have a look at dashboards, and they appreciate a chat with Product Owners, Scrum Masters, and the engineers. On the plus side: It is a controlled and safe environment. And you can choose the venue, too: Put the dashboards where stakeholders can see them.

Be careful with simple burndown charts, though. Those easily get torn out of context and might cause a Pavlovian reflex with some stakeholders, triggering urges to micromanage teams. Further reading on this matter: Scrum: The Obsession with Commitment Matching Velocity.

Write Release Notes:

The writing of release notes is really helpful in stakeholder communication, but remember: Bait the hook and feed the fish; stakeholders barely click on Jira links to learn about recent successes.

You need to tell a story. And a story has a hero (your product, team, organization…), a villain, an obstacle, and how the hero overcame the obstacle—in short: a story arc.

Invest some time to get the release notes right and they will positively influence the standing of Product and Engineering within the organization. (Rumor has it, they can be even fun to read.) Further reading: 5 excellent product release note examples and how to write your own.

Institute Ambassadors:

Start training interested individuals from the other departments’ operative trenches—identified in a collaborative initiative with the respective department heads—to act as liaison officers to Product and Engineering. Ambassadors collect feedback, track feature requests, and check bugs prior to reporting.

Meet with them on a regular schedule, perhaps even weekly. They’re excellent sparring partners, often act as your proxies within their own departments, and are well-liked participants in user-tests.

A note of caution: Don’t bypass reluctant heads, though. That hack might back-trigger and result in the opposite effect of the whole idea.

Organize Training Classes:

Invite other colleagues to regular training classes, and let them experience hands-on how a product is built nowadays: Lean startup, user story mapping, versioning, prototyping—you name it. Apparently, this kind of classes does not include coding. Prototypes are built with paper, crayons, pencils, and a prototyping app, for example from InVision.

Find a post on lessons learned when working with marketing people, sales and customer care agents here: App Prototyping with Absolute Beginners.

III. Stakeholder Communication by Regular Meetings:

Offer Ask-Me-Anything Sessions in the Form of a Lean Coffee:

Organize regular ask-me-anything session about agile practices, that is addressed to your colleagues outside the product development organization. A Lean Coffee “…is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.”

It is the ideal format to not just communicate your message, but also to identify those interested in the approach in general. They will probably become valuable allies at a later stage.

Working Operationally in Stakeholder Departments:

Everyone–developers, product managers, Product Owners, and Scrum Masters, to mention the obvious–should regularly work, for example, in customer care. Nothing can create rapport more effectively than joining your customers in their operative work while having your dog-food.

In a brief period, your Product Backlog, user story or work-item creation, and Product Backlog ordering process will become more aligned with solving real customer problems. Moreover, the whole product development organization will start rising from an anonymous group to valued colleagues.

Why? Because you serve in their trenches, too. A user story or a bug report is now no longer a ticket with a number in Jira, but it is associated with a name, and a face, and a story. Stakeholders will also learn more about your background, and why solving something that looks trivial to them might cause a major engineering headache.

Note: I am not referring to other regular meetings at the stakeholder level here, for example, such as portfolio management, product roadmap planning, or user story mappings, as those would exceed the scope of the post.

IV. Media Channels:

Daily Newsletter:

Create a daily newsletter of 5 to 6 of the most important news related to your company, and your industry. Throw in some startup & technology related posts—Elon Musk’s part 2 of his manifesto would qualify for that—, for example, as well as an occasional post from product or engineering. Or the company blog.

Treat it as a real newsletter and use perhaps the free plan of Mailchimp or basic plans of other email service providers for that purpose. You will need its analytic capabilities to optimize the newsletter over time. (You can do so by checking click-rates of popular links or run different headlines.) In other words: Be useful to your colleagues.

Opening rates tend to be above 40% and can go higher if word gets around that the CxO level is actively reading the newsletter. Encourage people to provide you with interesting links, and point out to those contributors within the newsletter editions. Sometimes, you might be lucky and even start a friendly battle between individuals to provide useful links. To my experience, this exercise will not require more than 30 min per day.

Side-effect: The PR department might be confused. Depending on your organization’s culture, you might even experience push-back.

Product & Engineering Blog:

Start blogging about your daily work to improve stakeholder communication: Technologies, processes, methodologies, frameworks, in other words: How you manage to ship a high-quality product, day after day. It greatly contributes to other components of the communication strategy sketched above if you can link to a detailed blog-post.

A great example from Berlin is Zalando’s tech blog. A product & engineering blog is also a cornerstone of a great recruiting strategy, going hand-in-hand with regular events, thus crossing the chasm from online to face-to-face communication with like-minded people you would like to hire.

Stakeholder Communication — Conclusion:

If you fail at communicating your agile transition in the right way to internal stakeholders, “Agile” might suffer the fate of being regarded as a mere local process, probably a fad, while the rest of the organization stays entrenched in silos and command & control structures.

Once that state is reached, resisting any future agile improvement attempts—waving the banner of “we tried in the past, and it isn’t working in our organization”—often become the prevailing attitude for those, who are not supportive of agile and lean practices. (Read more in: Why Agile Turns into Micromanagement.)

This is the reason, why considering the right stakeholder communication should be addressed on day #1 of your agile transition journey.

How are you winning the support of your internal stakeholders? Please share with us in the comments…

✋ Do Not Miss Out: Join the 8,250-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

📖 Related Posts

Agile Failure Patterns In Organizations

Why Engineers Despise Agile

How to Kick-off Your Agile Transition (Part 1)

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.