In my previous article I’ve talked about Agile and Scrum and you may have noticed the term Retrospectives. I purposely haven’t gone into detail at that point, because in my very humble opinion this topic deserves a fully dedicated post for itself in order to do it justice. Or aim to get close to.
The What
Looking at the definition of the word “retrospective”, it means nothing more and nothing less than “relating to or thinking about the past”. We can probably imagine that a retrospective is some kind of space that is being given in order to think and reflect on the past work. In general, most reflections have the aim to help us discuss, improve and prepare for what’s to come. Which in a way leads to hindsight in the best case somewhat becoming foresight — and this is a very important factor for being equipped to work efficiently and in an agile way. So I’d argue that while as per the term itself we’re going over the past, it’s a bit misleading as we’re actually at the same time starting to deal with the future (better).
And for all this, the session should cover questions along those lines:
- What went well? | What to continue? | What to celebrate?
- What did not go so well and should be improved? | What to stop/adjust?
- What to do about the points that were raised? | Next steps/actions?
The Why
Hindsight is a wonderful thing but foresight is better, especially when it comes to saving life, or some pain! — William Blake
Just like this English poet has known all along, it’s very desirable to create the necessary mindset (and actions, but more about that later) which will hopefully lead to removing potentially upcoming obstacles. And this is why learning by doing is still a really valuable approach to strive for, with the learning part being applied, and followed by continuous improvements — which brings us back to the Scrum framework once more. Only by reflecting on how things have been done, we can get as close as possible to how things should be done in order to maximise efficiency.
Anyway, now we all should have a fairly good idea about the goal of having retrospectives and some more thoughts around it. In short: Talk about the past and prepare for the future. At least that’d be my definition. Sorry, it could have been as short as that, but as we say in Germany “Good things take a while”.
The How
In the past, I’ve experienced really poorly (or not at all) prepared retrospective meetings, but also absolutely great and engaging ones. So while it doesn’t sound difficult, it’s “just talking about past work, right?”, there are a lot of Dos and Don’ts if you want to make the session meaningful with the most beneficial outcome for everyone involved (right now and in the future).
Preparations
- Make the retrospective session a fixed and regular part of your sprints/work cycles (once a sprint, or at least once a month) and allocate enough time for it (~1.5–2 hours, depending) — this is important to create the mindset of it being a valuable aspect within the overall process, rather than just another meeting.
- Invite everyone who has been working on the project(s) and not just team leads, as it’s a place for everyone to share their experiences, opinions and suggestions. In my opinion, new joiners can benefit a lot by listening into the discussions and getting a grasp of how the work (and feedback) is being done and how the team plans to go about things in future.
- Incorporate a suitable platform/tool. There’s a great article listing some really useful ones here. I am sure there are many more (you can even create your own designs, I’ve done a Locke & Key series-themed one once). In a lot of cases, it’s beneficial to share the platform in advance, so that people can make sure to have access to it and find their ways around it.
- Suggest to everyone attending that they may want to think about XYZ and prepare some discussion points in order to get as much input as possible, rather than putting people on the spot and them struggling to think about what exactly to mention.
Realisation
- Start on time (yes, that’s actually a thing to point out) and make sure that everyone is feeling comfortable enough to speak up. Meaning, set the expectations that it’s a safe space to share opinions (in a respectful manner) and that it’s important to be as open as possible. A little ice breaker might be helpful to get people talking — it’s easy to stay muted in a remote session and it might need a bit of help to get people to chat.
- Encourage everyone to contribute. You may have people in the session that are more outspoken than others, and as the person hosting the retrospective it’s your job to make sure that there’s a good balance and that everyone is being given the chance to talk. So if you notice someone being rather quiet, respectfully ask if there is anything that they’d like to share with the team towards XYZ.
- Make it nice. There’s nothing wrong with 3 columns to fill in saying “What went well”, “What went badly”, “What to do going forward”, but if it’s the same 3 column over and over, it may get a bit repetitive and less engaging over time. Mixing it up a bit with different prompts and designs/tools may help to keep attention levels at a high and creating a session that is more fun and looked forward to for the next time.
- Include celebratory moments. Don’t get me wrong, the “Good, Bad and Ugly” are key factors to discuss in a retrospective, but it’s also a great chance to give praise and credit where due. Feedback and praise will be discussed more in detail in a separate post, but for now: Just do it. If someone has been doing a great job talking to other teams and getting stuff sorted this or the other week, say it. If someone has finished the implementation of a key bit last week, praise it. If a team has launched a new project this sprint, celebrate it.
Actions
- Discuss anything that’s worth keeping, changing or implementing. It’s not always about reinventing the wheel, if something has worked really well, make it an action point to share the approach with other teams that might benefit from (hearing) it. Equally if something turned out to not having worked well at all. We don’t all have to get our feet wet in the same puddles. A fruitful session leads to some suggestions that have been made about concrete next steps to do/try out — so discuss them, write them down and convert them into concrete actions.
- Follow-up on the actions that the team has come up with and actually implement them. It’s best to allocate team members to the actions, so that not one person has to take care of everything (and in the end nothing). Now it’s up to the respective people (with the support needed) to take on the actions as some nice projects and make them into a reality. And this can be anything from creating a poll for a new team name to kicking-off the discussions for a new deployment cycle etc.
- Evaluate. This is something I’ve not seen all the time. Usually it goes like this: A new retrospective session starts, the old content gets removed or was lost in one of the chats and the hundreds of messages since then, and nobody even thinks about the actions that the team came up with in their last session anymore. So what was the point? Well, in the best case it’s been implemented, worked out well immediately and nobody even remembers that it hasn’t been like that before. Which is somewhat good (*cough* credit *cough*). In the worst case though, it got lost among the normal daily tasks and is destined to be brought in as a “new” discussion point (again). Therefore, I am (almost) begging you to save the actions somewhere and look at them in the beginning of the new session to check whether it’s been worked on and how it went. This has the advantage that it a) makes sure that actions are being followed-up, and b) gives some new input for what worked well and what didn’t.
I hope that all this was informative, however, I appreciate that it sounds fairly theoretical, so if there are any concerns or questions about more examples towards the implementation of retrospectives, feel free to reach out to me. It’s really all about regular open and honest (constructive) feedback and ideas leading to further actions and (continuous) improvements — not just for the business itself, but also for the team members and a healthy and positive work environment.
The Wow
Something that struck me since being a dev (if you haven’t read any of my other articles, here’s one that sums up my career change): I have only come across retrospectives since then. Having worked in HR, we’ve never had anything like that, and I haven’t really heard of other non-tech teams doing similar sessions. They probably/hopefully have their own techniques, but overall I feel like this is something so beneficial to do no matter what your role and department is.
Last but not least, one more point which I find important to mention is:
Don’t always wait for retrospectives to give valuable feedback!
