Variety in retrospective activities are definitely necessary. The more retrospectives I do, the more I’m getting tired of using the same method over and over again. And hey, this will most probably bore the teams I work with as well. Therefore it’s good to challenge the team AND you with new retrospective techniques. In the last weeks I tried out Starfish and Team Radar in retrospectives.
Starfish
Starfish is a fantastic activity to get your team to re-think the basic questions:
What went well in the last iteration? How can we do better?
Starfish refines those two questions and gets more detailed information from the participant instead of just a binary view. If you know retrospectives the different categories of the Starfish are self-explanatory, for everyone else I recommend the post from Pat Kua from 2006.
You can either let the team write post-its for every category one after the other or let the team handle all categories at once.
After the team has gathered the data you can start right away with some clustering or go straight to agreed, detailed improvements for the next wees by exploiting categories: stop, start or less.
Team Radar
Team Radar is powerful if you have a communicative team. It’s not so good if team members prefer writing post-its to talking (if you know hwat I mean… 😉 ).
You can pick 4 to 5 subjects that either you or the team think are worth discussing in detail. Those subjects can be team values like Respect, Feedback or Communication. Alternatively you can also choose reoccuring subjects from former retrospectives like quality of code skills, effectivity of the team etc. If you are not 100% sure what subjects to choose, only suggest subjects and then let the team decide.
This is how you can work with Team Radar:
- Explain to the team what you think that every subject means and then let the team discuss/agree on that
- For every subject let everyone dot/rate on a scale from 0 to 10 where she/he thinks the team stands concerning this subject
- Discuss each subject in detail and agree on concrete improvements:
- Be aware if dots are far away from each other on one subject. This is most probably because of misunderstandings within the team.
- As I mentioned before: This activity is for communicative teams. Take care that everyone gets the same time limit for their opinion.
Team Radar is described in detail in still the best book on Agile Retrospective Activities: Esther Derby and Diana Larsen “Agile Retrospectives: Making Good Teams Great”.
Nevertheless, with a new team, it is important to start and train the basic chain of a retrospective before starting with alternative activities and risking to overburden the team:
1) Warm-Up: What happened in the last iteration?
2) Prime Directive and basic group rules: Explain why those are important.
3) What went well in the last iteration?
4) How can we do better, how can we improve our process?
5) Is there anything we CAN’T change by ourselves?
6) What in detail will we change until the next retrospective?
Related Post:
3 retrospectives in 2 Days