This article is part of my Agile series, where I discuss various Agile-related practices from developer’s point of view.
Background
You know, I think that Sprint Retrospective has to be the second most hated misunderstood meeting; first one being, you guessed it – a Daily meeting.
And yet, that’s a pity. It’s a pity because this is not just something that we should be doing as part of our job, but as part of life as well. We should really be, occasionally, looking back at what we achieved and what we can do better in the future. Yet, not many do. Hence it’s not strange that we don’t understand the Sprint Retro either.
What is a Retrospective?
As usual, let’s look at what Wikipedia has to say:
A retrospective (from Latin retrospectare, “look back”), generally, is a look back at events that took place, or works that were produced, in the past. As a noun, retrospective has specific meanings in medicine, software development, popular culture and the arts.
Source: Wikipedia
If you ever listened to a podcast with David Goggins (commonly known as “the strongest man in the world), he uses the term “Backsteps”. To be more specific, he talks about scheduling a regular backsteps where you define the goals, “run” towards them and then sit down and retrospect on how you did and how you could improve.
Frankly, I can’t claim for sure (mostly because I can’t remember), but I’m pretty certain that almost every self-help book surely has the same concept, probably hidden under a different name. But still, it’s the activity that matters. Sitting down and reviewing what you did and figuring out how to do better in future.
Now, one might ask, and rightfully so – but WHY would I want to constantly improve? If I’m happy with what I’m doing and how I’m doing it, why not just keep it as is? Very fair question. And please allow me to present your worst enemy – thermodynamics.
The second law of thermodynamics, paraphrased in layman’s terms pretty much states that all things trend towards disorder. And, to be more specific to this case – if you are not improving, you are actually declining. By not changing anything and remaining where you are, you are actually not preserving your value but losing it.
So, to answer the question from above – “why would I want to constantly improve?”. It’s rather simple – because, otherwise you will be losing your value. And that’s (usually) not so good.
What is a Sprint Retrospective?
Pretty much as the name implies. The idea is that you define a goal, you “run” towards it and then you pause and evaluate how’d it go. What was good and what should be improved. What should be done more often and what should be avoided. Think of it as a regular doctor check-up, of a sort.
And I’d honestly argue that Sprint Retrospective is one of the most beneficial meetings that you could be having. Seriously. It’s literally a dedicated time where you are allowed to unwind and discuss the progress. And ideally you’d come out with a few “to do” points (e.g. keep dailies more focused towards the sprint goal, etc.).
How to do it effectively?
I’m going to share some of the things that we learned over the time. Of course, having a dedicated Scrum Coach is a great benefit as well, but if you can’t afford one, at least try and stick to these principles.
Write stuff upfront
If there’s single most beneficial thing that we learned over time, it’s that writing stuff BEFORE the retrospective is the best thing you can do for you and your team.
Why? Well, it’s actually simple – because you’ll otherwise forget it. Trust me. If you’re having a digital retro board, and I’m guessing that these days most of us have, the board for next sprint retrospective should be available from the moment that last one is finished.
We used to use Parabol, but these days we switched to Reetro. Both tools are free for smaller teams and amazingly useful.
So whatever it is that you like, pisses you off or you think should generally be improved – write it down! Don’t just randomly mention it hoping that someone will do it for you. Write. It. Down!
Timebox it
I’m guilty as charged here. Given a topic, especially one that I brought up, I’m famous for being able to talk for 100 days and nights. I kid you not. And not because I like talking, but because I (usually) believe there’s a lot to say! 😀
The only solution for preventing this is actually timeboxing the discussions. Usually 5–10 minutes per topic should be enough, but the general idea is to bring up the topic, and work towards finding a solution. It’s not about just talking and talking. The idea is to get to solution ASAP and, well, assuming that solution sucked, you work towards a new one on the next retro.
The sprint retrospective itself should be timeboxed as well. I think 1 – 1.5 hours should generally suffice.
Trained Scrum Coach can help here
As I’ve already mentioned, having a trained scrum coach can provide real benefits here. The thing with sprint retrospectives is that they sound simple, but just like anything that calls for discussion, they can go horribly wrong and turn into a most hated meeting. So, really, do yourself a favor and either train one team member or get a certified coach.
And before you ask, NO, I am NOT a certified coach or master or anything! And I don’t provide such services either. I can recommend some people if needed though.
Do I have to do it after each sprint?
Absolutely not! Some teams do it on per-sprint basis (i.e. usually at the end of a sprint), while some decide to do it once a month. But I’d argue that anything more than that (i.e. less than once per month) is too much. So, my personal recommendation would be to do it at least on a monthly basis.
Do I need to be using Scrum in order to do Retros?
Absolutely not! You are more than encouraged to do a retrospective on whatever it is that you are currently engaged in. I’ll share some examples.
If you are working out – you can do a retrospective and see where you started, where you are now and how you want to proceed. Pretty much evaluate yourself.
If you are on a diet, you can do a retro and see how you’ve been feeling, what’s been good and what was not that good and how to proceed in future.
If you are running a project (of any kind), you can gather your people around and just discuss the past, present & future.
You get the gist I hope. Retro is super-useful as part of a Scrum, but most certainly not limited to it!
Conclusion
A better question than “why are you doing Sprint Retros?” would be “why are you NOT doing them?”.
Retros should be one of the most powerful tools in your toolbox. A dedicated time where you can freely sit and discuss the overall feeling of how the things are going.
In general, you should always tend towards improving yourself, because if you are not improving you are actually stagnating, and that’s bad. And the same is true for life. Hence, start doing retros and thank me later!
If you liked this article, you might also like:
- Story Points that mistook themselves for Hours
- The Product Owner’s Curse
- Scrum. From developer’s perspective.
- Here’s why I see programming as an art form
- Art of Starting Things
If you want to stay up to date about what’s happening on this blog, you may befriend me on LinkedIn, follow my posts on Instagram and Twitter, or subscribe to RSS feed.
If you prefer, you may also subscribe to my mailing list: