Josh Evnin writes in Agile anti-pattern: Developer-focused retrospectives:
In a retrospective, however, it is important that no one group of team members is favored over others. This is harder than it may seem, especially when the developers make up more than half of the team.
The way most retrospectives I’ve been a part of have worked is some variation of the following:
- Individuals think of a few things that have gone well, and a few things that have gone less well over the past set time period
- These thoughts are put on post-it notes, then placed on a wall
- Individuals read all the thoughts and vote for the ones that they agree with (each person has a limited set of votes)
- The retrospective facilitator tallies the votes and discusses the highest vote-getters with the team, and discusses ways to fix problems and continue successes
Now, as you can tell this is a quite democratic process. The problem is, when the ratio of developers to business analysts is 4:1, you start to see the topics discussed err towards the technical.
I wonder whether concentrating on one role’s issues is also a symptom of not having retrospectives often enough.
Of course there’s a place for project or release retrospectives, but I tend to find more frequent iteration/sprint retrospectives more useful, as they give you a shorter feedback loop. As a side-effect, there are usually fewer things to add to the list after only one or two weeks, so we have time to discuss anything that gets raised, rather than having to pick the most important.