Teams run retrospectives for many different reasons. I’ve found that trying to meet too many goals in a heartbeat retrospective severely limits their effectiveness. When I prepare for retrospectives, I normally ask the sponsor (the person who asked me to facilitate) what they want to achieve. Sometimes they don’t know themselves, so it’s a useful exercise, by itself, to clarify their intended goals.
When I’ve sat in teams new to retrospectives and the goal is not made clear, people start to bring up too many different issues, and it’s difficult to resolve anything. One hour seems to be the maximum that teams are willing to set aside, and when you’re dealing with team issues, technical issues, process issues and more, all that time literally flies by. The result… nothing is improved and people get frustrated with the vehicle that brings some visibility (the retrospective).
What you can do about it
I use a rule of thumb, “One Goal Per Heartbeat Retrospective”, and make it clear at the start of the retrospective. It helps, if you’re the facilitator, to agree on what that goal is before you start, and do whatever you can beforehand to make sure everyone agrees. It helps if you’re working with a team that is already is formed (see the Tuckman Model) and you confirm this before hand.
Place the goal in front of everyone where they can see it, both as a subtle hint, and as an aid if you feel the retrospective veering off. Run retrospectives with a different goal in mind to address those that you don’t get around to talking about.
Photo of the cross signs taken from Gregkendallball’s Flickr stream under the Creative Commons licence.
Hi Pat,
Can you give some examples of retrospective goals you have found worked well? Any that have not worked well?
Ben
Hi Ben,
Some example goals of things that have worked well include: