A very important part of being a Scrum team and a Scrum organization is that we’re always looking at continuous improvement. The Retrospective is the key event in Scrum focused on the team’s continuous improvement of their process.

The Agile Retrospective is a great time for the team to reflect on how the team worked together to complete the Sprint. It’s not necessarily what has just happened, it’s dives into the root causes of why something may have happened. The goal of a Retrospective could be looking back on what work was completed, investigating any interrupts that came up during the Sprint, or just how the team felt on an emotional level throughout the Sprint.
The data a team collects through a Retrospective is used to inform the team of things that they may need to be addressed. This also helps the team understand how to solve future problems that could prevent them from finishing their work during a Sprint. Another benefit of a Retrospective is that the team can come up with new ideas on how to make the team better overall.
Within the Scrum guide, the Retrospective only has one deliverable and that is the Kaizen – the team’s commitment to improving during the next Sprint. How can we get better? How can we increase our velocity? How can we ensure the team is delivering value to our customers? How can we solve real human problems and make the world a better place?
The thing about the Kaizen is that it can be something as simple as “hey, we’re a group of developers, we tend to be fairly sarcastic, and it’s not the best for our communication, it’s muddying up our communication pathways. So let’s start using a little bit less sarcasm in our meetings” or it could be something along the lines of “hey, we just had a team member leave, what can we do to make our organization or team more T shaped so that we’re able to help compensate for whatever capabilities we lose with that team member leaving”. The Kaizen can be an estimated PBI, depending on whether the team thinks effort is needed to get it to done.
A good thing for us all to understand is the difference it makes when team members are T-shaped. If possible, you don’t want to leave work to just one team member, and you want to be sure that work doesn’t stop if something unplanned happens in a team member’s life. Being T-shaped makes a team better, helps the team swarm more effectively, and allows us to help each other.
One thing to remember is that no single team member is responsible for getting a task or PBI done. Life happens. And if someone’s not able to do something, the team still committed to getting that work done. The team wins and fails as a team. It’s not an individual’s fault, for not getting something done. It’s the team’s responsibility to make sure that we’re able to get the PBIs done.
Remember – how a team can get better is a fundamental part of Scrum. Individual and team improvement helps make the world a better place.
Want to hear more about the Retrospective? Check out Episode 7 of the CAVU 16th Minute podcast HERE.