Stakeholder Management

Road to Mastery — Season 2 — Episode 7

Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review. — Scrum.org Scrum Glossary

You know, all that rabble generating all that inconsistent noise, tirelessly changing opinions and needs through endless conclaves, only to never reach consensus about what value actually means to them.

But you gotta love ‘m. This insatiable lot is la raison d’être for the Scrum Team. Appeasing them can be a Herculean task.

The network of stakeholders can be complex. There can be employees, customers, users, external subject matter experts, investors, management, and their proxy representatives. This pool often consists of a dynamic group of individuals living and working in fast-changing environments. In Scrum it pays to have ‘Value Consumers’ collaborate with ‘Value Creators’ as a team. So Scrum Team members are stakeholders too. The Value Creators have a big stake in the product as it also returns value to them. Naturally the closer the relationship with stakeholders, the better equipped the team will be to determine what would be most valuable to them… And this is why Stakeholder Management is paramount when Maximizing Value.

Stakeholder Mapping

Don’t assume, but research who your stakeholders are. Maximizing Value is not unlike solving murder mysteries or treasure hunting. Like true detectives or a criminal investigation department, map them out!

Group them, draw connections, explore the nature of relationships, and build files on what they value, how they interact, with whom and why. And the same goes for how and why they interact with the product. A Stakeholder Map helps the team navigate the ecosystem of value.

A simple way to categorize stakeholders is using a Stakeholder Matrix:

Decide per stakeholder where they are in this matrix, but also consider where they ideally should be.

Coaching Stakeholders

The matrix can help the Scrum Team determine the game plan on how to interact and engage with stakeholders. Which stakeholders are key? When should who be invited during Sprint Reviews?

Ironically, sometimes stakeholders themselves can become impediments to value delivery. Therefore one of the responsibilities of the Scrum Master is to be

…“helping employees and stakeholders understand and enact Scrum and empirical product development;” — The Scrum Guide

One of the ways the Scrum Master does this is by helping them

…“understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.” — The Scrum Guide

The Development Team and Stakeholders

Sometimes it helps to have stakeholders interact with the Development Team directly without the Product Owner and Scrum Master acting as proxies. But at times the Development Teams needs to be protected from direct stakeholder influence in order to remain focussed on achieving the Sprint Goal.

A persistent myth is that the Development Team should not interact with stakeholder at all during a Sprint. This often leads to the Product Owner and Scrum Master to become mere proxies between them. Being a proxy can be one of the worst ways to manage communication between stakeholders and Development Team members. Interactions between them can easily be mapped by whether they are distracting or enabling the team towards its goals. Interacting with certain stakeholders can be essential to getting feedback fast. In any case:

“The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.” — The Scrum Guide

But even valuable input given by stakeholders to a Development Team can be disruptive when not properly managed. The Scrum Team determines together how these interactions can best be managed during a Sprint, so they don’t become needless distractions.

Unknown Stakeholders

It is (unfortunately) too often the case that Development Team members never truly interact with end-users of the product. The users, target audience, consumers are often abstract numbers and database entities. Some less unfortunate developers might have been briefed through visual and descriptive ‘assumption based’ Marketing Persona’s. You know those picture-perfect, stock-photo, “this is what our dream audience looks like” type of profiles.

The disconnect between Development Team members and end-users leads to a “Scrum in the Cave effect”. Development Team members end up serving Product Owners instead of the product and its users.

But what to do about it?!

I have some very positive experience with (Service) Design Thinking and Lean UX and how its methods can help Scrum Teams move out of their caves. They can help teams build evidence into each iteration. They provide numerous co-creative activities that can be performed with users, other stakeholders and Scrum Team members together.

Customer/user interviews, recordings on interactions and walkthroughs, customer journey’s, co-writing user stories, going on service safari’s and rehearsing digital services all contribute towards Scrum Team members becoming more empathized, committed and confident towards the Product Vision.

This should not be done ‘up-front’ or in ‘pre-phased’ discovery stages, but ideally every Sprint. The Development Team should be inspecting and adapting empirically. Meaning: based on what is actually experienced.

The Sprint Review

Scrum provides at least one opportunity for the Scrum Team to collaborate with stakeholders:

“During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.” — The Scrum Guide

The Sprint Review is the most important opportunity for stakeholders to keep informed and influence Product Development.

I’ve witnessed numerous Sprint Reviews where the Scrum Team shared progress only to a proxy Product Owner who, afterwards, distributes the information shared to stakeholders. This is highly inefficient. Feedback drips in later at unpredictable moments disrupting the team’s flow, often with conflicting requirements. I’m often experiencing stakeholders who argue they rarely ‘have the time’ to attend reviews. When they finally get round to reviewing it personally, at their own leisure weeks later, they demand that their feedback be processed urgently, preferably yesterday.

Scrum Teams, if this is happening to you too, demonstrate some courage, and demand some respect. You are providing them with opportunities at regular intervals. If they miss out on that opportunity, it is their lost opportunity. Don’t jump through hoops to appease them. If they really value their stakes, they can join the damn review.

Here are two great articles by Scrum Trainers published through Scrum.org on Stakeholder Management if you’re interested in Stakeholder Management and would like to learn more:

Thank you for staying tuned and joining me on this road to mastery.

Join the New Road to Mastery! Part I: Down the Rabbit Hole is now available.