On team retrospectives this point seems to be the hardest one – deciding upon specific action points. Gathering data and discussion are much easier parts 😉
Try an idea for a week and see if it works. Put a clear timeframe after which an experiment is collectively evaluated by the team.
During company retrospective at SoftwareMill we had a discussion on improving our (remote) communication and we were considering using Mumble. Not everyone (including myself) was sold to this idea, but we decided to install it anyway and asked everyone to give it a try.
What brought me round to do the experiment was Tomek Szymański‘s reply to my concerns:
“How can you say you do not like it if you have not tried it?”
Within two or three weeks of experiments we ended up with a different tool (TeamSpeak gave us better quality). For some of teams it turned out bo be their favorite communication channel, other teams decided not to use it, but at least they made a decision based on their experience instead of speculations.
How does it make a difference?
This approach is especially useful if the proposal for an action point breaks the current habit or is somehow unusual, which makes some of the retrospective participants concerned about it. An experiment is a better idea for such a case than trying to enforce a solution.
For a team making the commitment for just a week or so is much easier. And maybe at the point of evaluation (which may happen on the next retrospective) those who were concerned will change their mind.
Give it a try!
So, next time you are stuck on a retrospective try conducting an experiment 🙂 Let me know how it worked for you.