👆Level up👆 your retrospectives! (and why you should run one!).

You can also view this post on: https://dev.to/wabbbit

Regardless of which Agile methodology you use to deliver your software – You are using one, right?, retrospective is one of the most important meetings you can have. Sadly, it’s one of those meetings that can turn into an unstructured nightmare, and if you aren’t getting anything out of it, what is the point? This is a quick 5-min guide of leveling up your retrospective, or convincing you if you don’t already run one.

What is the retrospective for? Why should I run one?

By definition, a retrospective is a look into the past. In this context it is a chance for the team to get together at the end of a sprint/milestone and discuss what did and didn’t go well, and more importantly what can be done to improve. It should give the entire team a chance to voice their opinions in a safe space, and provide honest feedback that can be used to improve future iterations/sprints.

TL;DR: The aim of retrospective is to identify incremental improvements to make the next iteration/sprint better than the last.

Quick fact-sheet

Who runs it?: Arguably the meeting should be ran by the Team leader/Scrum master etc. However it can be ran by anybody as it is an open discussion owned by the entire team. Ideally one person should take ownership though to ensure the meeting stays focused and to track any outcomes.

Who attends: The retrospective should be attended by the entire delivery team. Business analysts, developers, testers, project managers, product owners etc. Anybody that was directly involved in the delivery of items. This meeting is not for the wider community such as stakeholders as this often limits honesty.

When is it ran:: The retrospective should be ran at the start of the iteration – looking back at the previous iteration. Typically this would be ran after any sprint-review/show & tell meeting and the stakeholders have left the room.

How long should it be: Keep it focused! 5 minutes per attendee. In an “ideal-size” SCRUM team this shouldn’t be more than 30-45 minutes.

An effective retrospective template

We have trialed many different approaches over the years for our retrospective. The theme has always been the same with the focus being on what went well, what didn’t and what could we change.

Lately we introduced a new template as retrospectives were becoming slightly unfocused talking-shops and although solid actions were coming out of them, people seemed hesitant to self-judge unless prompted.

Before this we also used the “Traffic light method”, also known as “Start, Stop, Continue”. My issue with SSC is that it has the potential to derail quicker and doesn’t feel as focused. SSC can also sometimes become dominated by one or two people and I felt that I was excluding people at times. That is why I like the 4 question method.

The 4(ish) question method

Part 1: Questions for each team member

Go around the table, each person answering the following 4 focuses.

• What was a success for you this iteration?
  • For example: a particular piece of work they were proud of, a bug they resolved quickly, etc. This is important as it allows the team member to show-off or gloat a little. If you don’t let people discuss success, they won’t want to talk about failure!
• What was a failure for you this iteration,and why? Could it have been avoided?
  • For example: “Not completing agreed work, because of X”, or “spending more time than they thought on Y”. 
    They should know why this happened and ideally what we could do to stop it happening again.
• If you could have changed one thing about the last iteration, what would it be?
  • For example: “Break down work items sooner”, “Spend less time in meetings”
• Did you learn anything?
  • Important as you want your team members to grow. Whether that is technical knowledge or product knowledge.

The answers should be simple one liners, and may prompt discussion among the group. For example, let’s say somebody says they felt one failure of the iteration was that they couldn’t complete a piece of work as the requirements changed last minute. You could ask why that happened and what we could do it mitigate this in the future.
Keep any follow up discussions short and concise. It’s very easy for someone to “go down the rabbit hole”. Take any discussion that will take longer than a couple of minutes offline or come back to them at the end. You don’t want to chew through all your time on one person, after all!

The person running the session should capture all the failures and changes.

Example:

• What was a success for you this iteration?
  • A success for me this sprint is that we resolved a critical priority item well within the SLA and had a happy client with positive feedback.
• What was a failure for you this iteration,and why? Could it have been avoided?
  • what: A failure for me this sprint I couldn’t get my changes into the test environment quick enough due to lack of Change Control resource.
    why: Change Control staff were not available at short notice.
    action We should schedule in resource capacity at the start of a sprint.
• If you could have changed one thing about the last iteration, what would it be?
  • n/a
• Did you learn anything?
  • I learned how {{some component}} worked.

This may have prompted discussion about how we need to think about how we deploy changes via another department and an action would be that we will do some up-front scheduling.

Part 2: Take action!

This whole process is pointless if nobody is taking any actions off the back of this session!
In part 1, the person leading the session should have taken notes of all the potential actions.

The session lead should quickly iterate over the actions captured and as a team decide;

• Is this something that we should do immediately, or place in the backlog?
• Who is taking ownership for this action?

Part 3: Coffee.

You deserved it, go you!

Although, there is no such thing as a free coffee. The actual 3rd item is to follow up on actions.

Issues you may run into:

People don’t want to talk about failure: Perhaps people feel like they are being judged. To combat this, really focus on the success of the sprint as the main talking point & promote an open/safe environment. If individuals don’t want to open up, the session-lead could drive an open conversation – i.e. “Why do you think we (as a team) didn’t achieve X”

Hostility: Make sure any feedback is constructive and blame free. Never attribute failure to another team member. Always use “we” never “you”. Promote collective ownership!

Lack of interaction Some people are introverts and may not want to join open discussion. If this is an issue, suggest people write the answers on post-it notes and have the session primarily led by the team-lead (Collating and discussing). Still give them the option to share or change their answers within the session.

Turning into a moan-fest. This one is really easy to slip into. To avoid this, promote constructive discussion. Ensure actions are being followed up or people may not take the meeting seriously and just use it as an opportunity to vent.

Retrospective your retrospective

There is no “best” way to run a retrospective session. Every team is different and sometimes you may find the format doesn’t work with the people that are attending. If it isn’t working for you, don’t abandon it, adapt it! YMMV.