Following on from my ‘How to be a good stakeholder’ post, here are a few ideas and suggestions designed to help you help your colleagues to be good Stakeholders and so you can work in harmony together.
Write a Wiki
Wikis are a great way to share important information with Stakeholders so they have everything they need to know about your product at their fingertips (keypad?) — knowledge and insight gained, design thinking, decisions made, the way you work, service and journey maps, technical diagrams, team bios, and the story of your product or service. For extra bonus points, add a glossary for capturing any technical and business jargon you use so you speak a common language.
Think of nudges as little prompts to help Stakeholders to do the right thing. We can nudge with language, like the power of ‘We’, not ‘They’. They can be reminders, such as ‘you’re not the user’. Those tiny pushes to attend workshops and demos or facilitatory questions (see below) we use to enable counterpoints. Think of what your Stakeholders need to help themselves and start experimenting AKA release the Trojan Mice (see below).
Have roles & responsibilities
Work with your Stakeholders to identify the rich tapestry of skills and knowledge at your disposal. Workshop Tactics has several activities to help you here. Taking the Stakeholder Mapping as read, I’d start with a Skills Market session so you can understand every stakeholders’ skills and abilities. Our findings feed into a session on Stakeholder roles and responsibilities. This will help everyone see the value each stakeholder brings to our extended team. Make sure this work is displayed somewhere prominent — did I say wiki (see above)? Alternatively, the outcome of this work could form part of a Charter of Commitment (see below).
If you want to jazz things up, create Stakeholder personas — using the prototype persona template — and have these in view when you’re working so you can ask ‘What would this stakeholder say?’ when considering complex issues. I guess this would help all of us empathise better with Stakeholders.
Sign up to a Charter
Write a Charter of Commitment for you and your Stakeholders. This should set out our expectations for all parties involved — perhaps building off your roles and responsibilities workshop? It might be an idea to reference psychological safety, too. Here’s one I wrote a while ago now, but it should give you a flavour of what’s needed.
NB: maybe rewrite the Retrospective Prime Directive in future tense and have everyone sign up for this as a simple alternative.
Set Confidence levels
Another way to set expectations with stakeholders is to ask ‘What do we have to do for you to feel confident about our work and its progress?’. It’s direct, yes, but the answers you get mean you’re confident you’re delivering what is required and they’ll be confident you’re working on the right things in the right order. I have two approaches here:
1) write down the confidence levels as outcomes e.g. I can answer questions about our progress at senior leadership meetings. These outcomes guide the team in its work and are on your mind when you talk with your Stakeholders.
2) create a very simple Stakeholder happiness survey with a max of 3 statements around a) whether a Stakeholder would promote our work, b). whether we’re delivering value and c) the likelihood of product success. Make sure this is completed regularly - perhaps as the last agenda item in any Stakeholder catch-up meeting? Here’s an old example from my Agency days, but you get the drift.
Use Trojan Mice to introduce the mindset of running multiple small safe-to-fail experiments over testing — and investing in — one good idea to your Stakeholders. RATs allow you to show Stakeholders how to learn about and validate your product before committing to a product or feature that may not be worthwhile.
Attack the problem, not the person
We win if we cooperate and use our skills and knowledge to tackle a shared problem — FACT. Run a workshop about defining mutual outcomes together with Stakeholders and use an independent facilitator (see below) — this can be a Product or Delivery Manager from another team. The key to success here is all parties being honest about what they need and then adopting flexibility and creativity when needs are opposed. I’ve found the 5 Whys technique can also help Stakeholders and the team here by focusing on the root cause.
NB ‘Attack the problem, not the person’ could be part of your charter, confidence levels doc/measures, or an extended team value.
Sometimes it pays to turn things on their head. Invite stakeholders to help you shape the perfect working relationship (or working day as the example used in this article) by first imagining the worst it could be before working on ways to avoid it together. Also see Reverse Brainstorming for a similar approach for tactics to keep your product on track.
Elicit knowledge and input
The Skills Market exercise should give you a head start here, supplemented by Stakeholder interviews. I’d suggest building on these by asking Stakeholders to draw the system you work within, what the goal(s) of the system are, where the boundaries are, and what rules and policies you need to know and understand. This will give you valuable insight into the system and your Stakeholder’s worldview and the leverage points for change/influence.
Finally, when you do encounter resistance to your work or approach from a Stakeholder ask yourself this question — what do they know that we don’t know? Then work through the layers of resistance or buy-in (below) lifted from the wonderful Behaviour-Driven Development with Cucumber. A veritable goldmine of insight and opportunity awaits you.
Develop and maintain empathy
Run an empathy mapping workshop with different stakeholders as the audience and see what assumptions you’ve made. Validated them. Run a hopes and fears session with your stakeholders to find out their secret goals and what keeps them awake at night. Good, old-fashioned Stakeholder interviews can also help build empathy. See if you can shadow a Stakeholder or invite them to try a variation of the Gemba Mat and watch the team working in situ (or spend a day attending your ceremonies and meetings). Finally, invite them to lunch with you (when it’s safe). A team that eats together succeeds together :)
Consequence Scanning provides an opportunity for the team and Stakeholders to focus on the positive aspects of a product while mitigating or addressing potential harm or disaster before it happens. You can gain an alternative perspective by running a premortem session with Stakeholders. This will help everyone consider what could go wrong so we can work as a group to stop it from happening. Together, these will give you the steps you need to take to mitigate risk, avoid the asteroids, and deliver business benefits.
Limit communication in progress
Be strategic about how and what you communicate with Stakeholders. Share only what’s important, at set intervals, providing space for deep thinking time. This will reduce the cognitive overload for them — and for you — by making things predictable. We developed a whole approach around this on my previous team.
Work in the open
Host all ceremonies and workshops on public Slack channels (where possible). Open invites all round. Use your public channels to share your progress, notes, and actions. Open your kanban boards to one and all. If you have a wiki, use this to share what you’re doing with the wider world. Publish your lead, wait, and cycle times so that Stakeholders can see the flow of work, the time it takes to put features in customer’s hands, and any waste. If you’ve set confidence levels and measures, share these too.
NB: think about creating an Obeya Room or Virtual Office wall in Miro. We did it at my last place and it worked well.
Facilitation enables great Stakeholder collaboration so brush up on your facilitation skills — this book is awesome and here’s a handy free guide. A simple start would be getting an independent person to host your key Stakeholder workshops or meetings where you have a stake in the outcome. Just doing this will make a massive difference. Assign roles to people at meetings, such as note-taking and recording actions, so key folks can focus on the meeting outcomes. Seek ‘balancing’ views — ‘Are there other ways of looking at this issue? Encourage others — ‘We’ve heard from Finance, what do our friends in Retail think?’. Help people take turns speaking — ‘raise your hand if you want to talk. Andy, you’re first. Dennis, you’re second. Mel, you’re third. Paraphrase to validate views — ‘…it sounds like you’re saying..’. Just read the book/guide already, it will supercharge your team’s collaboration skills.
For the important decisions, present clear options linked to long-term consequences including trade-offs that can be made — could these be linked to Consequence Scanning outcomes? Think of it as a menu. You want Stakeholders to be ‘present in the moment’ when they make important decisions. For more complex decisions, consider using a technique called ‘elimination by aspects’ with Stakeholders. This is where you approach decision-making in the same way you’d buy a car or choose a holiday. What’s the most important attribute? Price. Set criteria — £5000-£7000. Any cars outside the price range are eliminated. Next important, mileage. Set criteria — 35–45 miles to the gallon. Eliminate those outside the range. And repeat. Eventually, you’ll have just one option left, the best.
NB Record and share your decisions, and the context, somewhere public — did I say wiki?
Use the equivalent bet test game to help Stakeholders understand the perils of over and under-confidence with estimation. Essentially, we ask ‘If your own money was at stake, which bet would you take: my estimate that has a 90% chance of being right, or take a spin on a wheel in which there’s a 90% chance of winning”. The aim of the game is to help Stakeholders understand the limits of estimation and the role of probability in delivering products. No more big bets, and it’s fun, too.
For capturing what our priorities should be with Stakeholders try a KJ Method workshop. If it’s more about prioritising known requirements with Stakeholders — maybe in a stalemate scenario — try this game. Each Stakeholder is shown two requirements, picked at random, and must choose which one is most important. This is repeated until you have a ranked list in order of votes/importance.
Remember that being ‘agile’ is ‘the capability to respond to challenges quickly’ and not enforcing ‘agile’ thinking and doing on Stakeholders, often against their will. If we focus on the former, we can deliver value to our customers together at a gallop.
Have a brew together
The last and sometimes most effective technique is getting together with a Stakeholder for a brew and chat, always with cake, the currency of delivery. If it can’t be in person, then Zoom will do. And take the time to get to know your Stakeholder and the cake they like. They are human, too.
What do you do to help Stakeholders do a good job? What have I missed? I’d love to hear your suggestions.
Now go experiment!