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 (item) 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.
The post 👆Level up👆 your retrospectives! (and why you should run one!). appeared first on yer.ac | Adventures of a developer, and other things..
Top comments (3)
Good read, thanks!
On the topic of encouraging the introverted folks to participate more, I've used an anonymous messaging web app with my team. It's effectively no different than postit notes and, between the small group size and context clues, it's not all that anonymous, but it did increase participation. My guess is people tend to feel more anonymous and safe typing on a web site, even if they know otherwise.
You mentioned people feeling like the retro is worth their time, I've found that's the biggest factor in participation. To that end, I'm iterating on methods of highlighting results to the team. Results themselves are often too subtle for a person to associate the benefit with the retrospective process. Saying directly, "Remember how you said in retrospective that you have too many meetings? Have you noticed you have fewer now? EH?" isn't subtle enough. Could I pick your brain for suggestions?
Good idea Rieko! Inclusion can always be hard as some simply don't want to take part. I think you are definitely on the right track with the anonymous messaging if people don't want to openly discuss something. In this scenario I would still make sure I played back their message to the group, to give the author (or group) chance to correct it (Things may get lost in translation!)
You are right on the results. If people can't see things changing why would they come out their shells to suggest change?! It's something we have always struggled with, as it's hard to get buy-in.
This is what we (try) to do: At the end of each retrospective, agree which items should be focussed on. Be practical about the volume of items. We then assign a task or action into the upcoming sprint, so that way it technically becomes a "deliverable" (Easier for tangible items like "We need to increase test coverage" vs "We need less time in meetings".)
For items in the latter category, I would make a point of any time somebody took an action which had a positive result towards the goal. (I.e. Your team get a blanket invite to a meeting, you push back and ask if it's really a requirement the whole team goes, as they feel they spend too much time in meetings currently). Hell, even if the change isn't positive, I would still make a point of demonstrating an attempt!!
As well as the above, we also (try to) make a point to review any retrospective items added into the sprint, attributing each item to the person that raised it for a sense of ownership.
Please feel free to tell me why I am wrong, what you would do, and success/horror stories! Always interested in knowing how others tackle this.