The Sprint Retrospective is probably the least valued of the 5 events in Scrum. Like the stereotyped middle child, the Sprint Retrospective is often forgotten or skipped in return for precious time that could be used writing code. But the fact that it is one of the few carefully chosen events in Scrum and endorsed and taught by Scrum coaches and practitioners, should perk our ears and motivate us to pay attention to and perfect the art of the retrospective.

So let’s discuss why this Scrumderdog deserves to be put back into the limelight.

___________
Like a middle child, the Sprint Retrospective is often forgotten or skipped

Sprint Retrospective Goal

The purpose of the retrospective is, as its name implies, to look back or reflect on the last Sprint. It’s an opportunity for teams to brainstorm and discuss events and processes that are working well and those that are not, for the purpose of improving the efficiency and effectiveness of the team.

Discuss the likes and dislikes of the team. What works and what doesn’t. Cover as much ground as you can, including the Scrum process, stories, the definition of done, deadlines, culture, people, communication and whatever else that’s on their mind. The Scrum Master’s responsibility is to tactfully manage, guide and participate in these discussions such that everyone’s feedback is taken into consideration and resolutions are worked out.

Sprint Retrospective Rules

Timing

The event takes place after the Sprint Review session and before the next Sprint Planning session. It’s a 3 hour time-boxed event for a 1 month Sprint. Most our projects run on weekly or fortnightly Sprints. In my experience, retrospectives take anywhere from 15 to 30 minutes depending on the size of the team

Attendees

The Scrum Team should attend. Namely the Product Owner (PO), Development Team (anyone involved in the product delivery) and Scrum Master.

Often the PO is the client and it can be difficult to persuade them to sit in these sessions. Continue to try. Coach them on the benefits. Foster a culture of “we’re all in this together”. Remind them that you’re all part of the same team. Treat them as partners not clients.

Open Conversation

Everyone should be given the opportunity to speak if they wish. There is no such thing as right or wrong feedback. To all you Scrum Masters who are reading, cultivate a culture where everyone’s feedback is valuable and encouraged.

___________
Cultivate a culture where everyone’s feedback is valuable and encouraged.

Real Life Examples

So we got past the boring stuff. Here are a few real examples of changes made to our projects as a result of feedback during our Sprint Retrospectives.

Speed Up, Slow Down

We have a velocity expectation of each developer. Every Sprint we applaud those who hit and exceed this KPI and for those who didn’t, discuss the reasons for it, be it impediments faced, mistakes made, or whatever else.

Sprint 3 into the project (week 6) the team as a whole were not meeting the expected velocity. We had been trying to catch up several weeks in a row, and working overtime to do so.

The feedback received during this Sprint Retrospective was that the velocity expectation for this project was too high. Given the circumstances, the team that we had, the nature of the client, the complexity of the project, the changing requirements, we decided collectively to lower the velocity expectation.

The decision was not made on a whim, but had been the topic of discussion the last few Sprints and with an earnest effort made to keep up. Thanks to these retrospectives, the team has the freedom to voice out this concern. With regards to being Agile, any Scrum Master would know, having assessed the situation, that the team was working at an unsustainable pace and that it would only be a matter of time before they burned out.

Therefore, I changed our internal KPI. We lowered the velocity expectation and from then on we were consistently hitting our targets and the team’s energy and morale came back up.

Hello? Anybody there?

Part of the challenge of working remotely for clients across the globe is that public holidays are different. It was brought to my attention during a Sprint Retrospective that our client personally messaged one of our developers for something and thought we were unresponsive because they were not aware it was a Malaysian public holiday.

From then on, I sent out a list of public holidays that fell in the period of the project and reminder emails a week before to ensure that everyone was aware of when the team would be in/out of office.

The client was very happy about that and we never received another complaint that we were unresponsive again.

Pull it Together

We have coding conventions that all our developers adhere to when it comes to pull requests (PRs):

• Keep them small
• Squash commits before making a PR
• Tests need to be written and passed
• PRs need to be reviewed before merged

Over several Sprint Retrospectives, we discovered that the team had some PR frustrations. So we discussed these and formulated solutions during the session.

Problem 1: Large PRs with multiple commits
This makes it difficult and time-consuming for the reviewer.
Solution 1: Keep PRs as small as possible.
5 small PRs are easier and faster to review than 1 large one. This saves time, effort and frustration.

Problem 2: PRs outstanding for several days.
By the time PRs were reviewed, the requestor would need time to familiarise themselves with what they coded a few days ago.
Solution 2: PRs reviewed in the morning
As a brain warm up exercise, PR review is the first thing on the agenda every morning. There should be no PRs left unreviewed by 11am every day. This meant that any changes that needed to be made would still be fresh in the requestor’s mind.

Problem 3: PRs required multiple reviews
Not all comments were attended to and so needed to be returned for an additional round of fixing. Each turnover takes time to read, familiarise and optimise.
Solution 3: Self-review before submission
Developers are expected to self-review before submitting PRs to minimise the number of turnovers.

Problem 4: PRs reviewed by a select few developers
This meant the load of reviewing was not properly distributed.
Solution 4: Everyone to do code review
Every developer is expected to do code review and shoulder the load.

With the team on the same page with our PR expectations, developer happiness went up and time waste down.

Draw It

We’ve had 3 examples of negative things that needed to be changed. Here’s an example of positive feedback we received during a Sprint Retrospective and how we improved from it.

In one of our Sprint Reviews our developer had to present a complex back end feature he had done. Instead of running the client through the code, he drew out a diagram beforehand and skilfully presented the concepts in layman’s terms making it simple and easy for the client to understand.

During the retrospective, we applauded our team member for his creativity and we saw others follow suit in the Sprint Reviews following.

Team recognition, check. Client happiness, check. Skill level up, check.

What’s the big deal?

As you can see, every project team will have feedback, both positive and negative, at the end of every iteration. If there was a perfect process that could not be improved on, everyone would be using it and every Scrum Master would be out of a job.

___________
If there was a perfect process that could not be improved on, everyone would be using it and every Scrum Master would be out of a job.

No team, no client, no Sprint and no methodology is perfect, which is why Sprint Retrospectives are important. The time taken to check and adapt could potentially save you and your team from missing deadlines, harbouring frustrations, miscommunication, low levels of morale, having misaligned goals, expectations and more.

Like an F1 driver who never goes into the pit stop, exchanging retrospectives for development time is short term thinking in a long term game.