A Retrospective (aka Retrospect Sprint Meeting according to SBOK™ guide 2016) is one of the most important ceremonies that you can implement in your SDLC if you’re going Agile.
One of the main ideas behind Agile is being able to respond to changes. And for doing that the only way you can do it right is by constantly analyzing the way you’re doing things and the outcome you’re getting.
That’s one of the main reasons why Scrum encourages iterative short cycles. But you always must keep an eye on the expected results. Are things going as expected? Is there something we could do differently?
Agile in general (and Scrum in particular) is very related to the Lean concept of Kaizen (aka Continuous Improvement) and the Deming cycle.
Just in case you aren't familiar with it, the Deming cycle is an iterative process based on four phases: Plan-Do-Check-Act.
So, you plan something (Sprint Planning). Then you do something (Sprint). And here’s where one of the most important phases appears: you check what you did (Retrospective), and, finally, you act according to your previous analysis.
If you’re new to Scrum stick to the basics. Once again let’s check what SBOK™ guide tells us:
All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master.
It is recommended, but not required for the Product Owner to attend.
It is essential to hold this meeting in an open and relaxed environment to encourage full participation by all team members.
Discussions in the Retrospect Sprint Meeting encompass both what went wrong and what went right.
Primary objectives of the meeting are to identify three specific items:
Things the team needs to keep doing: best practices.
Things the team needs to begin doing: process improvements.
- Things the team needs to stop doing: process problems and bottlenecks.
These areas are discussed and a list of Agreed Actionable Improvements is created.
From my experience, one of the most important aspects is that everybody should be able to speak their minds. Agile is about team and communication. If someone on the team is not confident enough in your plan, then there’s something in your Scrum implementation that ‘smells bad.’ In fact, you should be discussing this openly with tour teammates. There’re no bosses around. The Scrum Master is not a Project Manager. And if he/she is, you’re certainly not doing Scrum!
And last but not least, you always should come up with a list of agreed upon, actionable items to address problems and improve processes in order to enhance their performance in future Sprints. Each action on the list should have an owner and its accomplishment should be reviewed during the next Retrospective.
So, if you still think that a Retrospective isn't worth it, rethink it twice and give it a try!