10 Proven Stakeholder Communication Tactics During an Agile Transition

So, learn more about ten proven stakeholder communications tactics that contribute to making this happen.

Stakeholder Communication Channels During an Agile Transition

Do good and talk about it—a simple necessity, particularly if your agile transition is supposed to be embraced by the whole organization over time. Deciding early in the process how to communicate with internal stakeholders usually makes the difference between “doing agile” and “becoming agile” in the end.

Keep in mind that a lot of stakeholder ego, as well as personal agendas, is tied one way or another to executing “the plan”. And you’re trying to sell them that quitting this plan will turn out to be mutually beneficial. 

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?

Developing empathy for stakeholders is particularly relevant when engineering and product don’t have the best standing within the company at the beginning of the 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.

Image from wikimedia.org. Picture courtesy of Wikipedia, licensed under the Creative Commons Attribution-Share Alike 2.5 Generic license.

Judging by my experience, the following stakeholder communication tactics have proven useful, if actively pursued from the beginning:

I. Agile Ceremonies

Sprint Reviews

A great opportunity to show to the whole organization what value has been delivered during recent sprint(s) and align the stakeholders with the upcoming sprint(s). 

The cadence of this event depends on the size of your engineering organization, if the teams’ sprints are aligned, or whether you’re releasing several times a day anyway. 

A weekly sprint review tends to wear off quickly, as not much novelty can be provided. (Except you’ve just started building something from scratch, then a weekly demo is great for team-building in general and creating a common spirit. You need to celebrate every victory.) 

The basic rules are simple: 

• Lead by example: The engineering and product team should be present. Why would a stakeholder invest her 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
• 5 minutes per team are usually sufficient
• Initially, it might be required to lure stakeholders to the sprint review. 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…)

Further reading: Stop Calling Your Sprint Review a Demo—Words Matter!

Daily Scrums

Invite stakeholders to the daily Scrums, once the 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 stand-up and turn it into a reporting session. If a team does not warm up to the idea, restrain yourself from making the invitation.

II. 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 a bit 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 and 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 burn down 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: 

Really helpful, but remember: Bait the hook and feed the fish. And the fish usually doesn’t 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: Slack: A little thing about release notes. 

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 Workshops: 

Invite other colleagues to a training workshop, and teach them hands-on how a product is built nowadays: Lean startup, user story mapping, versioning, prototyping—you name it. Apparently, this kind of workshop 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, and other bloody beginners here: App Prototyping with Absolute Beginners.

III. Regular Meetings:

Offer AMA 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, QA engineers, product managers 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 own dogfood. 

In a very short period of time, your product backlog, your user story creation and prioritization process will become more aligned with solving real, and quite often trivial, problems. 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 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 and 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 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 irritated (in the beginning). Just ignore them…

Product & Engineering Blog: 

Start blogging about your daily work: 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: “Visit our tech blog to learn more about the engineering and ideas driving Zalando’s exciting work. Here’s where we post technical talks and tips, news about our open source projects, event photos, and much more.” 

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.

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, while the rest of your 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…