So I found myself in a company where we were supposedly doing bits of Agile, but no retrospectives. For an agile developer, a retrospective may very well be the best part of the cycle. To raise concerns, and come up with solutions that make us all better. To get their frustrations out etc.
There are a few concerns with retros, for example the time it takes. How to find solutions to problems raised in a retro. Had a retro but never got to solving it due to time shortages? Here are a few things that can help.
Its worth time boxing parts of the retro so it doesn’t get derailed by ongoing discussions (format announced at the start so we can intervene later).
- Explain the retro format, lots to choose from. Here are a few:
- Impact vs Likelyhood
- Start/stop/continue
- Mad/sad/glad
- Be sure to include a hi-5s section in whichever format you choose.
- Pulse (if needed, no always useful but gives a metric of the team’s mood) – 2 minutes.
- Raising problems – 5 minutes
- Set a timer for 5 minutes
- Ask your team to write down the issues they’ve experienced (along with hi-5s for the team members).
- Stick em all on a wall to discuss.
- Sort the highest impacting/highest recurring issues.
- Solve problems – 40 minutes
- Discuss solutions to the problem in the order you’ve sorted them.
- Timebox discussion on each issue, say 10 minutes max with a buzzer at 5 minutes.
- Write 2-3 actions you can take to improve/resolve the issue. It doesn’t need to be perfect, just needs to be an iteration you can try.
- Move on once you’ve got the actions you need or you’ve hit the timebox limit, come back to it after.
- Discuss solutions to the problem in the order you’ve sorted them.
- Hi-5s!
- Praise the team members for their excellent contributions/achievements. Lifts team morale and spirit.
- Pick the ones that are realistically achievable in some capacity until the next retro (3 issues?). – 5 minutes
- Pick the highest impacting/most recurring issues.
- Its worth doing this, otherwise their may be lots of small issues that don’t really recur but all of them combined can be overwhelming.
- You can also find yourself in a situation where you deal with the lowest priority issue but not quite the high priority because it requires more effort/resource/planning. Having less actions means you can streamline your focus on to them once they are agreed by the team.
- Assign to members of the team.
- Assigning to different members of the team empowers them. They don’t have to do the task necessarily but they drive it.
- Take pictures and upload (if you fancy it! Just useful for others to look at and creating a history of retros timeline).
- Backlog remaining issues raised to assess/compare against the next retro.
- If something is re-occurring, its priority goes up. If it doesn’t show, probably a one off.
- Pick the highest impacting/most recurring issues.
We have to come out with prioritised – high impacting problems/solutions to deal with, and it be healthy to pick about 3 top issues and deal with it within the couple of weeks. If the issues are too big, we can always break them down in smaller actions and deal with them piece meal. Naturally the top 3 issues have to be impacting us, and once they are dealt with and don’t impact us any longer that could feed into the metric to measure the retros effectiveness. It is also worth having a survey afterwards to see what people think about the retro and how it may be improved. One of the questions could be “Do you want to be in the next retro?” etc. That could also feed into measuring it.
What sometimes happens is we come out with 15 actions to take from a retro, and we don’t pick the most important things to do. Then every time we just get the easy ones done but not the high impact ones. This could negatively impact us.
Its also very effective to assign these actions to different members of the team – if its something the team can do for themselves (info dissemination, empowering team members). They don’t have to execute the solution on their own, but drive it.
Lastly its a team effort. Yes there is a person leading the retros – scrum master usually. A scrum master is simply a facilitator of the procedure nothing more. Its the team that comes out with great things.
Agile manifesto principle 12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” If we get it right, I guess a metric would be the team’s efficiency now vs then. For that – we’d need a metric for right now though.
Excited for you guys! Go on!