Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
One of the things I enjoy doing is running retrospectives. I know, Iâm a bit weird. No one likes meetings. Well, this is one important meeting in agile. Why? Because a retrospective allows your team to reflect on the last sprint and make changes. These can be any changes: process, code, metrics etc. With these changes, you can experiment and see what works and doesnât work for your team. Thatâs what being agile is aboutâââbeing able to change and cope with changes.
What is a retrospective?
A retrospective is a look back on the previous sprint(s) or piece of work that youâve done. You want to deep dive into why things happened and how you can continue (the good) behaviours and stop (the bad) behaviours. Itâs a chance for your team to regroup and connect to grow strong bonds. Retrospectives arenât just about workâââtheyâre about bonding in a team and having a great culture for everyone to speak up.
How do you run a retrospective?
The most basic retrospective is that you ask the following questions:
- What went well?
- What didnât go well?
- Why?
These three questions are a start. Youâll learn whatâs hurting the team and you can dive deeper to solve the issues. With a retrospective, you can drive changes to your agile process. Maybe someone says communication didnât go well. You need to ask why. The answer might be because Bill didnât know that Sandra had already fixed a bug, so they doubled up work. And then you ask why again. Because Sandra was sick on Tuesday, so she missed stand up and didnât give an update. So, now you know the problem. How you solve itâââis up to you.
There are so many âgamesâ you can play in retrospectives. Some of them that I know are: âMad, Glad, Sadâ, âStart, Stop, Continueâ, âLiked, Learned, Lacked, and Longed forâ, and âLoved, Liked, Hatedâ etc. These games aim to get your team talking. For example:
Mad, Glad, Sad
Youâll have three columns on a whiteboard. Use post-it notes so that thereâs no pressure on anyone to conform. Everyone has five minutes at the start of the retro to write down things that theyâre mad, glad, or sad about.
- What are you mad about?
- What are you sad about?
- What are you glad about?
Youâll find that maybe some people write personal reasons. Maybe someone will write that theyâre sad because they broke up. You know if they write that, they trust you and your team. Mostly, youâll find that people write theyâre happy that they finally got that massive feature outâââor that theyâre mad that the build server takes twenty minutes to build. These are all things you can use to improve your process and create change in your agile team.
How I run a retrospective
I tend to stick to the basic questions at the moment. What went well and what didnât go well. I also like to do a happiness chart to get a feeling of how the sprint went.
What is a happiness chart?
Itâs a chart that you can draw on your whiteboard (or A3 paper). Firstly you draw the axis. I like to do something like below. Here you can see the y-axis is the happiness and the x-axis is the time (in the sprint). Your team can mark points of importance to them to give a rough estimate of what caused them to change.
You can see that although the team is happy, the happiness over the sprint for everyone decreased. However, no one was unhappyâââwe just werenât as happy as we were when we started the sprint. With this data, you can dig into why people became happy or unhappy. I find this handy because you gauge the whole team and it can be anonymous if you want. You can compare sprints and check if you have made improvements to your teamâs wellbeing.
Retrospectives are for everyone
You should definitely make time for retrospectives. You need to be able to look back at your sprint and assess with your team what can be improved. But note: this is a team exercise. If you are a team lead or a manager you do not dictate what the team should improve or focus on. In fact, another person (from another team) should run the meeting. This, Iâve found is best to help separate the concerns because then the team leader becomes just a member of the team and does not dictate where the retro will lead. I look forward to hearing how you run your retrospectives and how you deliver change to your team.
Originally published at www.alexaitken.nz on April 9, 2018.
How to Run a Retrospective was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.