Here’s a technique I currently use when facilitating a basic retrospective.
Depending on the situation, I might use some way to dig out specific, relevant topics first. That could be just a simple me-we-us exercise. But this technique can also be used as the only thing in the whole retro.
If there are six people or more, I’ll go with small groups of 3-5 people, where each group will do their own version. If we have predefined topics, both/all groups get their own topic. Groups assemble in front of flip charts, armed with post-it notes and proper pens.
Group fills in what bugs/annoys them the most in general, or about the given topic. What is most harmful for getting stuff done?
Group then chooses most relevant problems to tackle right now, and discusses how things should actually be. My experience is that discussion starts to go towards that direction quite naturally at some point, even after just few minutes.
When we have an idea how things should be, i.e. the goal, group discusses what we could actually do to move towards that goal. What kind of steps to take, when and how? Who needs to be persuaded/contacted, what needs to happen?
Now we should have some concrete ideas how to improve things. If there were several groups, I typically bring them together at this point to present the ideas. The last phase will be done together: what will be actually really done, and by whom?
I want to do the last part together, because these are ultimately impacting the whole team. So everybody needs to get a say, and to discuss the ideas. I try to make sure there is enough time for this phase, at least 10 minutes per group.
End result could look something like this.
Idea behind naming the responsible person is that nothing gets done unless someone really promises to take care of it. In case you have a scrummaster, avoid the trap that the scrummaster gets most or all of the tasks! It’s not how it should work :).