Lessons from Ben Williams and Tom Roden’s “50 Quick Ideas To Improve Your Retrospectives”

Today, I’d like to share some insights I took note of while reading Ben Williams and Tom Roden’s 50 Quick Ideas To Improve Your Retrospectives“, which is the last of the 50 Quick Ideas series of books. Before, they talked about how to improve user stories and tests. Now, they want us to think more deeply about our retrospectives.

  • Plans are of little importance but planning is essential.
  • Constraints have inspired people to do their best work. They give us important puzzles to solve, and we learn to work around our limitations.
  • The value of releasing new products or features early can sometimes outweigh the cost of design shortcuts, so incurring technical debt is justifiable in the short term. But eventually the aggregated effect of technical debt can significantly impact team productivity and long-term product support effort, so there should be regular repayment plans.
  • Technical debt is most commonly associated with software design, but it can also include deviations from sound engineering practices that may produce future risks.
  • Like user stories, we should measure the impact of retrospective improvement ideas that we decide to implement. In order to do that, we need to know what to measure, how to measure it, what the baseline is now, what the target for success is, and at what point in the future the measurement is to be taken.
  • If you find yourselves saying ‘we’ve always done it this way’, remember why that is. Check if the reasons are still valid.
  • For a team to truly improve, they need to show vulnerability, and to do this, they need to feel safe. If there’s no privacy, they won’t feel that way. If the members of the team feel that they are being judged, they won’t feel secure, and retrospectives under these circumstances will most likely be superficial.
  • Be disciplined over work-in-progress limits. Finish the ongoing tasks first before taking on new items.
  • Giving personal feedback is often overlooked during retrospectives. Teams tend to focus on process or technical issues while ignoring human ones.
  • As scrum masters, what we do for the team should reduce their reliance on us and make our role a little more redundant. It is our job to help teams decide for themselves, to provide them with opportunities to develop their skills to solve problems on their own in the long term, to self-organise.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.