post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Building for change: When transformation and product management meet

Product Development

What are product features? Definition, examples, and 5 types

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! 🎉

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Lessons from my first year as a Prod Ops Manager

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Sr. Product Manager

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>

core/freeform

Agile Product Development

Better value sooner, safer, and happier by Jonathan Smart

Building Successful Product Development Teams, by Simon Colmer

How to be a Successful Product Owner, by Ninon Laforce

Out of the Fog by Holly Donohue

How Design Thinking, Lean, and Agile Work Together by Jonny Schneider

Lean, Agile, & Design Thinking by Jeff Gothelf

Tales of two Continuous Loops by Tim Beattie

Agile With a Capital A Might not be Best by Morag McLaren

How to Apply Lateral Leadership in Agile Environments by Tim Herbig

Owning Agile by Jeff Patton

Broken Retrospectives and how to fix Them

ProductTank Madrid

ProductTank Montevideo

ProductTank Montréal

ProductTank Boston

ProductTank Ahmedabad

ProductTank Bangalore

ProductTank Berlin

ProductTank Oslo

ProductTank Des Moines

ProductTank Bangkok

ProductTank Abu Dhabi

ProductTank Helsinki

ProductTank Pune

ProductTank Kraków

ProductTank Cardiff

ProductTank Mumbai

ProductTank Johannesburg

ProductTank Tauranga

ProductTank Bielefeld

ProductTank Vilnius

ProductTank Timisoara

ProductTank Stockholm

ProductTank München

ProductTank Düsseldorf

ProductTank Birmingham

ProductTank Norwich

ProductTank Heidelberg

ProductTank Malmö

ProductTank Barcelona

ProductTank Newcastle Upon Tyne

ProductTank London

ProductTank Perth

ProductTank Málaga

ProductTank Tokyo

ProductTank Braunschweig

ProductTank Edinburgh

ProductTank Pittsburgh

ProductTank Vienna

ProductTank Bristol

ProductTank Washington

ProductTank Raleigh

ProductTank Brno

ProductTank Paris

ProductTank Orlando

ProductTank Hong Kong

ProductTank Charlotte

ProductTank Exeter

ProductTank Manchester

Broken Retrospectives and how to fix Them

Jeff Hudock

Read more

Comments