Team retrospectives to keep people engaged

Working in a multi-disciplined team of developers, content authors, testers and researchers has many benefits — but retrospectives can become boring for some if the topics in discussion aren’t of interest to the whole group — for example a content author might not be interested in developers talking about how to fix bugs more quickly.

The best retrospectives I’ve been involved with:

• Allow everyone in the team a chance to participate
• Keep the attendees interested
• Have actionable outcomes that can be tried, and tested to see if they fix problems

With this in mind I’ve come up with an idea of how to run a retrospective which allows lots of mini retrospectives to take place…

1. Each person in the team writes post it notes for things in the last sprint that went well, which they want the team to encourage and continue with
2. If a team member has encountered a problem in the last sprint they note it on a post it. If it needs a whole team discussion they put it in one list, if it just needs a smaller discussion, then they can put it on a separate list.
3. The facilitator / scrummaster of the meeting will go through the items for #1, and allow for any discussion that is needed.
4. The scrummaster will then go through the problems for smaller discussion, encouraging those with problems to quickly ‘pitch’ their discussion point to the team.
5. Once all the problems have been explained — the team will go to the board and write their initials on the problem they are most interested in talking about.
6. The team now splits into small groups of those who want to talk about an idea — if an idea has no-one’s initials — then the author of that card can find another topic they like and join their group.
7. The small groups have a time limit (say 10 minutes) to discuss their topic and come up with a proposed change or changes.
8. The groups will reassemble into the whole team again, and a person from each team (not necessarily the author of the problem post it) will explain the change they have agreed, and what they hope the benefit will be.
9. The scrummaster will now facilitate a discussion of the problems the whole group wanted to discuss, and come up with changes as necessary.

This retrospective method should allow individual skill-sets to have discussions and make changes, and still allow everyone to participate where they want to in smaller and group wide discussions. It will focus people’s minds on what problems they face, and what may interest the whole group — or just some of the team.

Hopefully in the longer term this will lead to mini retrospectives happening whenever a problem arises, rather than the team waiting for the end of a sprint — and then maybe a retrospective being shorter or not needed as the team in constantly inspecting and changing.