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

Jeff is a proven product management leader. He has worked in both product management and business analyst roles for global providers of financial services technology, data and analytics. Currently, Jeff is the Senior Product Manager responsible for nCino’s Customer Engagement Solution. With the talent he brings to the team, he is working with the world’s leading financial institutions to change the way the financial industry connects with their customers.

Jeff Hudock

<p>Having worked on teams using agile methodologies for several years, retrospectives are a major part of my life as a product manager.  Retrospectives (retros) are held at the end of each sprint cycle, at the end of the overall release, and sometimes to review other meetings or processes. Retros are intended to review your team’s successes and failures, with the goal of continuous improvement.</p>
<p>Retros are a great way to improve communication and foster teamwork.  A team that is open and respectful of their colleagues will be much more successful than one that gossips at the water cooler because Johnny didn’t write test cases. A successfully executed retrospective would have brought to light the fact that test cases are extremely important and shouldn’t be overlooked, a conversation followed by a deliverable action to move forward with.</p>
<p>In my experience, however, more often than not retrospective meetings become just another agile ceremony.</p>
<h2>Why Retrospectives Stink</h2>
<p>At the end of each sprint, development teams around the world huddle into a room, or dial in to conference lines, to review the work accomplished in the previous sprint or release.  These meetings can go in a few different directions.</p>
<p>If your team was successful over the last sprint, retrospectives are non-productive &#8211; a meeting that could have been avoided and instead memorialized with a great “thumbs up” giphy in Slack.  Instead, you spend an hour splitting hairs in order to find <span style="font-style: italic;">something</span> to look back on.</p>
<p>Conversely, if your team did not have a successful sprint, you’ll wind up with a mile-long list of action items. A list of action items that typically don’t get executed or followed up on.  These lists are documented within some long-lost Confluence page or Box note. If your team is really on their game, these action items are reviewed at the next retro.</p>
<h2>How to fix Them</h2>
<h3>Don’t be Scared to Skip</h3>
<p>At Ncino, we found retrospectives are just another step in our development cycle.  At the end of each sprint, good or bad, we meet to discuss how it went. We’ve found that if the team unanimously felt the sprint was successful, skipping that particular retrospective proved more valuable than having it<span style="font-style: italic;">.  </span></p>
<p>If you don’t have anything major to discuss, don’t be afraid to skip, or at least shorten, your retrospective.</p>
<p>Celebrate that your team is crushing it, working together effectively, and meeting sprint commitments.</p>
<p>Instead of using an hour to talk about how great you are, give that hour back to your development team to keep crushing it!</p>
<h3>Time-box and Stick to it</h3>
<p>Time-box your retrospectives to less than one hour.  After an hour of circling around the successes or failures of a previous sprint, you’ve probably covered the main issues (and probably in all columns; Start, Stop, and Continue), or you’ve upset Dave, your lead developer, who takes things too personally. With 10 minutes left in your time-boxed retrospective, start memorializing your action items.</p>
<p>If you find you don’t need the whole hour, write down your action items, give a few of high fives, and end early.</p>
<p>One way that my team has addressed the time-box issue is to ensure we come prepared.  We use Ideaboardz.com as a simple collaboration tool to put down our retro topics.  We send it out a few days before the next retrospective, giving everyone ample time to jot down their thoughts on how the sprint went. This way we know exactly what we are to cover.  Coming prepared has allowed us to stick to the time-box and most of the time, end early.</p>
<p>Give it a shot and see how it works with your team.</p>
<h3>Take Action on Your Action Items</h3>
<p>Write them down.  Print them out and post them around the scrum team area. Share action items out to a larger audience or across departments. Stick a sticky note on your monitor. Do something to track your action items.</p>
<p>Without tracking and measuring your results, I promise they will be forgotten, brushed under the rug; when they’re inevitably rediscovered during another retro as a continual issue, you’ll find yourself saying “That was a good idea… why didn&#8217;t we do that?”.</p>
<p>After failing several times with following up on action items, we started writing them down on a common area whiteboard. This simple action helps us to keep the topics top of mind and ensures that we don’t overlook them.</p>
<h2>Conclusion</h2>
<p>To be clear, I’m not advocating that you skip retrospectives.  These sessions can be highly productive and add a ton of value if executed correctly. Continuous improvement is key for agile shops and retros provide the avenue to pause, look back, and evaluate in order to improve moving forward. However, if not executed correctly, retrospectives can lead to an unproductive time loss that does not bring value to the team. Make the most of your retrospectives (when needed) and ensure action items are actually pursued, and I think you’ll find your scrum teams operating like well-oiled machines.</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>

Broken Retrospectives and how to fix Them

Jeff Hudock

Comments

Read next