Reflecting on your problems at the Sprint Retrospective is too late
The Sprint Review is an under-utilized opportunity to ask influential stakeholders for help
Dealing with demanding, powerful stakeholders can be difficult and exhausting. Sometimes it feels like no matter what you do, you will never be able to please them.
Did you deliver it differently than expected? Oh, boy! You will definitely get questions. Did you deliver it exactly as expected? Great, here is a list of ten more things your stakeholders would like to have. What are you looking at, please get going!
Engaging with difficult stakeholders can feel like going to the dentist: no matter how well you brush your teeth, or the fact you haven’t had a single cavity in your entire adult life, they will still find the chance to tell you everything you can do better.
But dealing with powerful, insistent stakeholders, can also have its perks: the same properties that make them hard to ignore can be leveraged to get what you need to succeed.
Asking for help at the Sprint Review
Stakeholders are often demanding because they care deeply about what you are building. When the things they want get delivered later than planned, they instantly jump from their seat and pay attention.
Many teams just start talking about the challenges faced during the Sprint at the Sprint Retrospective. This is too late, as some issues should already be dealt with during the Sprint. On top of this you should already talk about the problems you’ve encountered during the Sprint Review. Here’s the relevant snippet from the Scrum Guide from the Sprint Review:
“The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.” — Scrum Guide Nov 2017 version
Sometimes there are pervasive, longstanding issues in your process, team, and organization that can be easily solved, but nobody in the Scrum Team has the clout to get them fixed. Allow me to give you an example.
Imagine your team is working on a feature stakeholders want to get out the door as soon as possible. The design has already been delivered to your Scrum Team. During the Sprint, it turns out some changes need to be made to the design. However, because designers are not part of the Scrum Team and busy with a different project, the design cannot be adjusted on such short notice. The feature, now impeded by stale design, won’t get delivered.
This is your perfect opportunity to escalate this long-standing issue! During the Sprint Review, you tell the feature was not delivered. You explain the problems you ran into, and how you tried to solve them to no avail. Your stakeholders are unhappy and start asking questions about how we can prevent this from happening in the future.
This is your cue to let your stakeholders know, this is not the first time this has happened. You give a list of features that were delayed due to designers not being part of the Scrum Team. You connect your failure to deliver to a concrete problem they can help solve.
In order to deliver on time, please help us to convince the Head of Design to allow designers to be part of Scrum Teams. There is no risk, we can just try it out by assigning a single designer to a Scrum Team. If it doesn’t work out, we can revert it without any harm being done.
After the Sprint Review, your stakeholders immediately reach out to the Head of Design to convince her to allow your Scrum Team to experiment by having a single designer as part of the team for a few months. Now it’s finally happening! Your Scrum Teams are performing far better, and more valuable products are being delivered with design now finally part of the team.
Form a tag team with your stakeholders to fix problems
“Those who overcome great challenges will be changed, and often in unexpected ways. For our struggles enter our lives as unwelcome guests, but they bring valuable gifts. And once the pain subsides, the gifts remain. These gifts are life’s true treasures, bought at great price, but cannot be acquired in any other way.” — Steve Goodier
An essential concept in wrestling is ‘Kayfabe’. Kayfabe is the bubble within which professional wrestlers act, to convince the audience of staged events as being true. It’s what kept the crazy rivalry of Hulk Hogan with Andre the Giant believable for all those years. Without the suspension of disbelief through kayfabe, professional wrestling would be impossible.
When you do Scrum, kayfabe is bad. You should not hide your problems or act as things are different than they really are. Do not keep your problems hidden until the Sprint Retrospective. Doing so reduces transparency, inspection, and adaptation. You will just miss the opportunity to include your stakeholders and form a tag team together to fix these problems.
Despite organizational politics, we should always aim for being on the same team. Especially when you have strong stakeholders with a lot of clout. Otherwise, we will only pull each other in the wrong direction, and who exactly is served by that?