Retrospective – A look back to move forward

As we wrap up another year and move forward into another, I am reminded of one of the most overlooked processes in a development cycle.

The retrospective.

As a scrum master, I am intimately familiar with sprint ceremonies.  I have found that of them all the retrospective tends to be valued the least and most easily skipped in the rush to deliver.  However, I would argue that when done well it can bring a great deal of value to a team

So, what does it look like to do a retrospective well?

First – Make time.

When beginning a project, it is key to make dedicated time for regular retrospectives.  At first it will be difficult to understand the length of time required for the retrospective, so I would suggest leaning toward longer early on and adjust as needed.  It is always easier to shorten a meeting than it is to lengthen one.

Create a safe environment.

When asking for feedback from all roles it needs to be understood that everyone’s commentary is important and valuable.  Each person will have a slightly different vantage point to the overall process and therefore has a unique perspective on areas of strength and weakness. Safe === process-specific commentary, not individual callouts. If the environment is not safe, it is natural for people to hold back. 

Encourage constructive feedback.

I have found when not given the appropriate direction on what type of feedback is expected that retrospectives can devolve into generic “love fests”.  i.e. everything is awesome, everything is cool when you’re part of a team.  While giving praise is absolutely needed and should be part of a retrospective, digging into the process gaps is where the real growth happens.  It is critical to celebrate, but also just as critical to be honest where improvement can be made.

Take Action

I have found it very easy to speed through a retrospective and completely drop the ball on the most key point.  The action items.  Many developers I have worked with hated retrospectives because they felt that nothing was ever going to change, so why have the meeting or provide feedback.  So, it is extremely important that the last step of the meeting is working as a team to properly define action items.  These should be clear, concise, timeboxed, and then assigned to a team member to execute directly or be accountable for.  Doing this not only lets the team know that they have been heard, but that as a team growth and change are important. Each subsequent retrospective should begin with action item follow-up. Again, making it clear to the team that feedback is NOT falling through the cracks.

I encourage every development team to truly take the retrospective seriously.  Make time, create a safe space, provide constructive feedback, take action, and above all grow as a team.

Happy Dev’ing!!