I've heard it way too many times, "Why are we doing a retrospective? What's the purpose anyway?" As the Chief Agilist / Release Train Engineer for a half billion dollar program, I have nearly 40 scrum teams that I'm working with. Many of the teams get it, but many of the teams are still becoming familiar with the Scrum practices and how these practices may benefit them. If you struggle with this, hopefully I can shed some light on it for you.
Retrospective, as defined by Google, is "looking back on or dealing with past events or situations." So, how does that apply to Scrum. A Retrospective, in the Scrum context is one of the fundamental meetings in the Scrum Framework. Its purpose is just like the definition says--an opportunity for the team to look back on and deal with the past events that occurred during the past Sprint. But "why?" you ask? It's simple--to "deal with the past events". Even if you have a "perfect" Sprint, where you completed every single story you and your team signed up for and met the expectations of the Product Owner in delivering quality value, there are always things we can do to improve; speed things up and / or improve product quality, team cohesion, individual fulfillment. Retrospectives are an opportunity to take a step back and evaluate the events over the past Sprint and identify / celebrate successes, as well as help identify those areas where we could do better.
A retrospective is only as good as you make it. Scrum Masters should take time to identify retrospective activities that will help engage the team and best bring out their honest, constructive feedback. Team members need to come in to the retrospective with the pure intention of making their team and product better. Most often, the output from a retrospective is a Kaizen Story. Kaizen is a Japanese term coined during the early Toyota lean transformation that means "Improvement". We should identify an improvement story that we, as a team, can do to improve our team and/or process. Typically, this isn't ways to improve the product, that would be a regular story. But it might be something like, "As a team, we want an automated command line executable build so that we can deliver faster". Yes, this does feed into the product, but its focus is on the process. Another example might be, "As a team, we want everyone to show up on time to Scrum, so that we can be done quickly and get back to work." It really is up to the team to figure out ways they can become better.
Often overlooked as a huge benefit to having a retrospective, is the team building aspects of it. Anytime you can openly share thoughts and feelings in a safe environment, you grow close to those you share with. The more comfortable and trusting you are with your team, the easier it is to execute as team. The more you truly execute as a team, the faster you will be able to deliver a better product!
Find ways to make your retrospectives better... sounds like a good retrospective topic?
If you need help making your retrospectives better, please feel free to reach out to me. (email@example.com)