post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Ben Staples has over 7 years of Product Management and Product Marketing eCommerce experience.  He is currently employed at Nordstrom as a Senior Product Manager responsible for the product pages on Nordstrom.com.  Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps.  Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences.  Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members.
I do product management consulting!  Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how?  Want even more book recommendations?! <a href="http://www.ben-staples.com/contact">Let me know!</a>

Ben Staples

<p><span style="text-decoration: underline;"><a href="https://www.scrum.org/resources/what-is-a-sprint-retrospective">Scrum.org</a></span> defines a sprint retrospective as a time at the end of each sprint where the team discusses what went well, what could be improved, and aligns on specific actions the group can commit to improving for the next sprint.</p>
<p>Retrospectives are an essential part of any organization running agile software development. I don’t care if you’re running scrum, kanban, scrumban, it doesn’t matter. Reflecting on how you are doing and working to get better is essential to team success throughout and morale. And when teams don’t run retrospectives, the reason is rarely about tools, or workflow or anything like that. It’s time.</p>
<h2>Time is the biggest problem teams face when thinking about retrospectives</h2>
<p>There are instances where teams don’t retrospect at all because they believe it takes too much time away from feature work.  And when teams do hold retrospectives, they often don’t allocate enough time to be effective, rushing through the meeting because of other priorities.  When your team rushes through, conversations don’t get to the necessary deeper level that enables true progress or learnings.</p>
<p><span style="font-style: italic;">If you don’t take a step back and think about how things are going and what can be improved, how will you, your team, or your organization ever grow?</span></p>
<p>When thinking about the next sprint, teams often lump retrospective and planning together when they should be run as two separate meetings.  Retro, where you review what happened, and planning, where you take your learnings from retro and immediately put them into action.</p>
<h3>The cost of skipping retrospectives</h3>
<p>The problems come when you compare planning and retrospectives according to their short-term impact, rather than the less visible long-term implications.</p>
<p>Planning is essential. If you don’t plan at the start of a sprint, the short-term implications are <span style="font-style: italic;">bad</span>: your scrum team runs out of work to do. Morale drops. Direction starts to fragment. Stakeholders start asking questions. The repercussions are incredibly visible.</p>
<p>Retrospectives <span style="font-style: italic;">feel</span> like they’re easily skippable, because the short-term implications of skipping a retrospective are not especially visible. But I would argue that your retros <span style="font-style: italic;">are </span>essential, and here’s why.</p>
<p>You skip a retrospective and things appear fine &#8211; the team still has work to do, stakeholders are happy. But you didn’t learn anything as a team from your last sprint (and you can be sure that there were things to be learned). So now you’re heading into your next sprint without a clear idea of where someone on the team might have made trade-offs, or without addressing the things that you all know didn’t go well previously.</p>
<p>In short, you’re all set to make the same mistakes again, or to stumble into a world of pain and edge-cases that you could easily have avoided.</p>
<p>My favourite analogy is that retrospectives are like eating your vegetables. Sure you don’t need them every meal, but skip them regularly and your health will inevitably suffer. By regularly incorporating retrospectives into your lifestyle, your team can grow big and strong (&amp; smart).</p>
<h2>How to get team buy-in for retrospectives</h2>
<p>We understand retrospectives are the vegetables that can fuel your team to strength and good health, but how do we start actually doing them if you are not already?</p>
<h3>Just ask</h3>
<p>Oftentimes, engineers will be totally open to having retrospectives!  Many have worked at other companies or on other scrum teams and ideally have seen the benefits of moving from teams that don’t regularly retrospect to those that do.  Many engineers will want to actually champion the idea themselves.</p>
<h3>Get buy in at a 1:1 level</h3>
<p>Maybe you asked the team and got pushback, or your sixth scrum sense tells you it will not go over well.  Being a good Product Manager means knowing your team well including having an understanding of who influences who on the team, and who can be an ally.  Don’t just ask anyone, but think about who might be able to help you get buy in on the engineering team.  Many people will be significantly more open to new ideas in a 1:1 setting rather than a group discussion.  If regular 1:1s are abnormal with your engineering team, make it casual.  Go for a walk or get a coffee together.</p>
<h3>Pull in an expert</h3>
<p>Often organizations will have access to agile coaches.  Certain scrum masters can also do the trick.  These individuals have been trained in the magic that is scrum, are firm believers in the benefits of retrospectives, and have practiced retorts to all of the common concerns non believers bring up in terms of retrospectives.  If agile coaches or scrum masters are not available, experienced engineers on adjacent teams can often also be relied upon to get buy in for the team.</p>
<p>Once the team buys into the idea of retrospecting and has started to develop the habit, small problems can come up that can completely throw off how effective this practice can be.</p>
<h2>The human problems that can ruin a retrospective</h2>
<p>Once you’ve got your team running retrospectives, and you’ve overcome the common “not enough time” arguments, you’ll have a different set of issues to contend with. It’s still not about tools or process &#8211; now the biggest challenges you need to be aware of are <span style="font-style: italic;">social and psychological</span>.</p>
<h3>1. The lure of group-think</h3>
<p>This one is easy to spot &#8211; everyone is too busy looking at what others are contributing, rather than thinking independently about what went well for them over the last sprint. As humans, we strive to a certain degree of conformity and group identity, so it’s only natural that we each try and align ourselves with what our peers think went well, or could have gone better.</p>
<p>There are countless retrospective formats out there. As a quick, easy, and free solution, I’ve seen teams use Google Docs or Dropbox Paper documents for retrospectives where you can see what everyone is writing in real time.  These are great for aligned collaboration, but not for a retrospective. To start with, you actually need a certain amount of hidden information.</p>
<p><span style="font-weight: bold;">How to solve it: </span> When thinking about what tool to use for your retrospective, look for one that has a feature that obscures what people are writing until it is time to share.</p>
<h3>2. The backfiring bystander effect</h3>
<p>In a similar vein from the group-think issue, you might find that people aren’t raising issues because they know (or believe) someone has already brought it up. They might think they’re helping by pre-de-duplicating talking points, but by stepping aside “because someone else will talk about this”, they’re actually missing the point.</p>
<p>Duplicates are probably the most valuable part of a retrospective, because they highlight what is truly top-of-mind for the team. You want to see those duplications coming out, because they’ll help you all focus your attention on the issues that are affecting large parts of the team.</p>
<p><span style="font-weight: bold;">How to solve it</span>: Use a tool that allows duplicates on the same topic to be grouped or stacked (the joy of post-it notes!) Once everyone has entered their retrospective discussion topics and you are reviewing, grouping common thoughts is an effective way of showing what the group is collectively thinking about.</p>
<h3>3. Fragmentation rather than focus</h3>
<p>The team can’t clearly come to a consensus on what is the most interesting to talk about in our limited time. This <span style="font-style: italic;">might</span> be happening because the team has unintentionally fallen victim to some version of groupthink or the bystander effect, but it might just be that there are a lot of issues that need discussion, it’s hard to know where to start, and you’re burning valuable time trying to decide.</p>
<p>Of course, while some teams review every item, ideally you would:</p>
<ol>
<li>Have too many retrospective points from the team (<span style="font-style: italic;">suggesting that the team is really investing in the process</span>)</li>
<li>Have a team that would rather go deep on a few topics rather than shallow on a broad amount (<span style="font-style: italic;">suggesting that your team is really committed to meaningful growth, rather than just paying lip-service to the process</span>)</li>
</ol>
<p><span style="font-weight: bold;">How to solve it:</span> Voting functionality is a great feature to look for when evaluating retrospective tools. Alongside clustering of duplicate points, it’s a great way to show where the team’s attention is focused. And <span style="font-style: italic;">especially </span>now that so many teams are working remotely, voting is essential to understand where to go deep in retrospective conversations.</p>
<h2>A closing note on tools</h2>
<p>While there are tons of tools out there, my favorite to date has been <span style="text-decoration: underline;"><a href="https://www.retrium.com/">Retrium</a></span>.  It is a great tool and, although I am not sponsored by them yet (hint hint, in case anyone from Retrium is reading 😉), it offers a few different retrospective formats and really hits the mark.</p>
<p>Ultimately, no matter what tools you’re using (and I’m including post-it notes in that definition), it’s crucial that you support these three key experiences:</p>
<ul>
<li>Let your team generate ideas as individuals</li>
<li>Encourage your team to list <span style="font-style: italic;">everything</span>, and then form clusters of shared interest</li>
<li>Enable your team to silently vote on the issues they really want to focus on, so that you’re spending time having valuable conversations, not deciding <span style="font-style: italic;">which</span> conversations are the most valuable.</li>
</ul>
<p>No matter what your format is, make sure you retrospect. It’s a crucial practice as our teams become more distributed, and essential for any effective agile development team!</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

Three Hidden Problems That can Ruin Your Agile Retrospectives

Ben Staples

Comments

Read next