I’m gearing up to put together a retrospective for my team at my current client site, and I’ve been both thinking about and reading over notes from previous retrospectives I’ve either sat in or facilitated. Looking over a lot of these notes, especially from the worst ones, I’ve noticed an emerging pattern of behavior that can either make or break a retrospective. Here’s a few that I think are the most important.
- Retrospective Belongs to the Team
This is possibly the most important observance I’ve noticed… retrospectives are only effective if they truely belong to the team. This means that it should only be attended by the team and only the team can pick a goal and how they’re going to follow up on them. Management shouldn’t attend the retrospective imho as they can cause interference, step in, or require metrics to be collected. Several retrospectives I participated in at my previous client had the manager constantly cut people off or tell them that the goal they’re proposing won’t work and refuse to let it be considered. These retrospectives were the most useless in my opinion and we never accomplished anything.
- Don’t Let It Become a Whine-fest
Retrospecting is about inspect and adapt… about looking at our experiences over the past and using root cause analysis to find causes and how we can improve in the future. However, if there is plenty of negativity in the past, it can be easy to succumb to “crying over spilt milk” without coming up with any real solutions. And nothing is worse for a team then to spend an hour in a room listening to each other bicker without any from of constructive activity… it will leave the team feeling down rather than up. Therefore aim to keep the retrospective on track to discuss the facts and observances and put emphasis that the past is only for concrete experience to draw ideas from. Problem solving activiities should be given more focus than pouring over historical data.
Activities Are Better
I’ve sat in on hundreds of retrospectives, both with activities and without. On the outset, the no-nonsense, just talk about “what worked, what didn’t, what to improve” sounds good, simple, and to the point. However, my experience indicates these were amongst the lowest in terms of effectiveness. For starters I think it keeps people locked into a “this is a meeting” mentality and prevents thoughtful activity. Hell, one place I was at just put a word document up with headings titled “What Worked, What Didn’t Work, Action Items” in which Action Items were items the manager would enter into Rally Project Management and assign to people to work on.
I’ve found that activities often keep people engaged. In a meeting someone can get by by sitting in front of their laptop staring at the projector, with activities they’re constantly involved and not given time to disconnect. Additionally, I find the care freeness (or even fun) of activities helps break down some subtle communication barriers and makes people feel more free to speak their minds.
Pick Only One Goal
In theory picking multiple goals sounds great right? We’ve identified all these impedments and road blocks in our team,process, or environment that really need to be addressed. Why don’t we just tackle ALL of them rather than ignore them so we can work on removing all of them? This is long the same lines of the theory that maximizing Work-in-Progress maximizes effeciency and we all know that this often fails. LIkewise, by maximizing the number of goals that you have for an iteration you run the risk of context switching too much (not to mention all the focus you’ll already have towards the work you’re doing during the iteration) that the team will lose track and quite possibly not make any headway towards any of the goals listed.
Therefore, limit your Work-in-Progress as a team by selecting one (and only one) goal for the team to work towards during the next iteration. Maybe you’ll complete it in one day. Maybe you’ll complete it by the end of the iteration. Maybe you’ll make progress on it and discover in the next iteration that you uncovered deeper issues that need to be addressed.
One of my biggest mistakes I ever made as a facilitator was failing to help the team follow up on goals… I assumed you could just let the team form a goal, work out how they would accomplish it, then just let them leave the room with it to schedule into their iteration and complete. Boy was I wrong. Working towards that goal can possibly even grow future retrospective topics, or like I mentioned previously uncover more serious or deeper issues the team needs to address. Failing to follow up can leave the team with a slew of goals they never complete or superficial goals that only kick some dirt over the issue. So it’s good to recap on the goal that was formed as part of establishing historical data near the beginning of the retrospective and let it help drive new ideas or delve deeper if it wasn’t completed. Often times you can find incomplete goals correlate to the iteration… for example if it wasn’t reached because there wasn’t enough time to work on it, maybe there’s not enough slack in the iteration?
Again, out of all these, I’d have to say the most important is number one: the retrospective belongs to the team. This is an activity for the team by the team to help them inspect and adapt their process and shouldn’t be something enforced upon them or led by their manager. I ask all ScrumMasters out there to take special care if you facilitate the retrospective… in my opinion you really shouldn’t, but if there’s an absence of facilitation skills you might need to. If this is the case, remember your position… you are not a manager and therefore should not use this to dictate goals to the team. Stay as neutral as possible and at all costs do not allow yourself to become the owner of a solution, it needs to belong to the team and the team needs to make whatever needs to happen happen. If they need to schedule a task into the iteration, let them do it rather than do it for them.
Likewise, as a facilitator it is of utmost importance to remain neutral. When I facilitate teams I am on I try to refrain altogether from involvment. Also remember as facilitator it’s your job to facilitate the discussion, not drive it or offer solutions. I’ve facilitated a retrospective once where someone called on my expertese with fitnesse to help them solve a recurring fitnesse problem they were having. Sadly, I offered solutions. Looking back, I should have suggested that they come up with a goal, and if they needed help they could come seek me out when I had my developer hat on out on the floor. Further, I often find that when a facilitator from the team participates, they often drive the entire retrospective. Either their ideas lead for the rest to follow (even if they participate last) or the teams participation might fall on deaf ears. I once watched a friend of mine facilitate a retro for our team and draw out a huge value map… at each time two or three pople would say what they thought the cause was, then he’d say “well, I think it’s really this…” and write out his own idea in the map without taking into account what the team said. When I called him out on this he couldn’t believe he did that.
Overall, keep in mind the retrrospective is for finding solutions, not problems. Keep it on track, listen, and help guide the teams to introspect within themselves and find the solutions they need. Most importantly let them do the decision making and above all use the retrospective as their own activity to get better.