It’s about time for a new list. Today, I decided to write a list on how to mess up your retrospective. There are a lot of possibilities to do this and the following tips will help you doing so 😉
1 – don’t prepare anything
As the retrospective is the simplest and least important meeting of all Scrum meetings, it doesn’t need any preparation. Just come together and start. Wait, where are the pens and the post-its? Forget about it! Just sit together and chat a bit.
2 – Start immediately
As there is no need to set the stage, start immediately with gathering data. Immediately start the retrospective with asking the two questions: „What went wrong?“ and „What went well“. That should be sufficient to get great results.
3 – Don’t check if the tasks of the last Retro were done
We don’t care about the old crap from the last retrospective. If it was important enough, it will make it again to our retrospective results. And again, and again, and again, and again….
4 – don’t use post its
Post Its are evil! Endless trees have to die to create this evildoing. You have silent and introvert people in your team? Then maybe it is time for them to learn to speak up. It also helps to reduce all of this retrospective waste, with all of these things that can’t be solved anyway.
5 – Forget about the Insight
Insight? Isn’t it clear why you failed in your last sprint? Maybe you should also skip the „Gather data“ step and instantly start to „Decide what to do“.
6 – No DUE date
Due dates are for waterfallers. As we’re working in an agile environment, we don’t need any due dates.
7 – no responsible
Repeat after me: „We’re no waterfallers“. A responsible person is a concept from the stone age. We as a team will make sure that the task will be done.
8 – No time box
This whole concept of a time box is exhausting, isn’t it? Can’t we just skip it for the retrospective? Just sit together and talk and for sure we will have something valuable in the ehh, when it is over, eventually…
9 – try to solve everything
You collected a big list of issues? Then you should try to solve all of them. It can’t be that you ignore some of the problems of the last sprint. Define a task for each identified impediment or problem and solve it in the next sprint.
10 – Always use the same scheme
Always ask the same questions and do the same exercises in all of your retrospectives. This will create a comfy environment for your team and you ensure that you’ll always have a energized and creative team. Your retrospective results will be awesome. Ignore all of this fancy new methods to facilitate a retrospective. This is all new age shit.
I’m looking forward to your experiences, when trying these things out. Please leave a comment 🙂
Great post! As usual, the devil is in the details. Manu of your ten points look like small things, be they can make the difference between an effective agile retrospective, or just another (wasted) meeting.
I’ve written a short article on my bloag about how to get more business value out of Agile Retrospectives. It’s about things like empowering the teams to take action, using Root Cause Analysis to understand problems at hand, and several techniques to do a retrospective.
Thanks for your comment and the link to your article.
Great viewpoint, thanks for sharing. But I disagree with the Post Its usage. To be honest I love Post Its (we use recycle paper 🙂 ), its another way to keep those intro people share their thoughts, if round table discussion is bit hold them for their ideas. We used to gather all those post-it, after the retro and document them, stick on the wall for team to refer to / move forward from the retro meeting. Just my thinking. Happy for discussion and debate 😛
Maybe, I don’t get your question. I totally agree that Post-Its are a good thing, that’s why my article is named „10 things to MESS UP your retrospective“.
Didn’t care for your format, too much sarcasm. I think you had good points – but it wasn’t clear what you actually expect. I’ve been doing scrum for 3 years and I don’t know what you expect for some of these. Tough luck to anybody new to scrum.
Nice post, thanks for sharing these points. I’ll have to re-check our retrospectives with your list.
What would be a helpful extension, if you could describe your flow of the retrospective – showing how long and at which point you embedd e.g. the check for the last retro results, how do you administer the tasks found including responsibilities (who can be responsible?).
Maybe in one of your next posts 😉