Retrospective Rules

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Follow Up

    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. :)

  • http://www.AgileLearningLabs.com Chris Sims

    This inspired me to write about it for InfoQ. Check it out here:
    http://www.infoq.com/news/2010/03/Rules-for-Better-Retrospective

    Cheers,

    Chris

  • http://www.iljapreuss.de/ Ilja Preuß

    Nice tips! Your second tip, “Don’t Let It Become a Whine-fest”, sounds very much like what I called the “Living in the bad past” anti-pattern: http://iljapreuss.blogspot.com/2009/03/retrospective-antipatterns.html

    I don’t fully agree with your first point, though. True, management shouldn’t dominate the meeting, let alone tell people what to do. On the other hand, mutual understanding of the points of view and needs of management and the development team is crucial for the effectiveness of the process and success of the project. And the retrospective is the perfect place to create that mutual understanding if you can get managers to attend as partners and servant leaders.

    Just today we had a developer comment that retrospectives are much more productive since our project manager attends. Before, it was just too easy to make it a complain session about management.

  • http://blog.james-carr.org James Carr

    Hi Ilja,

    Thanks for the comments! I agree my first point is perhaps a bit obscured… I think having management involved is really great, but special care has to be taken to ensure they don’t dominate/control the meeting.

    Perhaps having a working agreement for the manger while they attend to leave their manager hat at the door? :)

  • http://www.westborosystems.com Dave Rooney

    I’m going to go all consultant on you and say, “It depends.” :)

    With respect to excluding management from the Retrospective, I’ve coached a group where the Program Manager mandated that he attend, and as a result the people had to resort to submitting their comments to the coaches via e-mail because they feared the reaction from this person. In that particular case, the PERSON was the problem, not the fact that he was from management.

    I all other teams I’ve coached, at least the direct manager actively participated. I had no issues with that because I had seen how the team and manager interacted during the iteration.

    As with pretty well everything in the Agile world, there is no one simple “rule”. There are rules that apply in a certain context, and in this case your rule applies very well when there is no trust between management and the development team.

  • Jean-Charles Meyrignac

    I mostly agree with your conclusions.
    However, I’d like to add the following points:

    Retrospective Belongs to the Team
    This is true, but it’s interesting for a manager to participate, at least as a spectator.
    In general, our retrospectives are held in 2 parts: the first part is about gathering data (it’s about the past), and the second part is about analyzing the data (it’s about the future).
    Don’t let the manager come while gathering data !!!
    Also, try to keep him passive, or he’ll influence the decisions.
    If you set the rules at the beginning as:
    – respect
    – listen
    – don’t monopolize the floor
    you won’t have to spend efforts on keeping him quiet.

    When your manager wants to control everything, it’s important to use hidden voting. Try to avoid private emailing, because it can be monitored.

    Don’t Let It Become a Whine-fest
    Totally agree.
    Whining means that there is a problem. Your role is to locate the problem.

    Activities Are Better
    It’s important to force people to physically move.
    Force them to stand up (for a short amount of time) then to sit down.
    Before analyzing the data, I propose a puzzle that has to be solved by small groups (2 people). I started with a sudoku, and try to find a new puzzle every time to avoid people to get accustomed, also try new puzzles so that they won’t know how to solve them before.
    Finally, I try to pair them so that they are with someone new every time.
    I emphasize on the fact that the puzzle has to be solved by communicating with each other.
    It’s fun and a good appetizer for the second part of the retrospective.
    It’s also important to vary your exercizes from one retrospective to another.
    This afternoon, I’ll try a little exercize of “devil’s advocate”, where people have to defend why the product will be released in time.
    I tried also a variant of the congratulations, where people had to thank the other people in their team.

    Pick Only One Goal
    Sorry, but I disagree on this one.
    It’s important to find several ideas, and to rank them so that the most important ones are done.
    The low-priority ideas can be reused or discarded in the next iteration.

    Follow up.
    It’s very important !
    Once every 2 daily standup meetings, we read the table of our goals and try to check if we progressed on them.

    Neutrality
    It’s very important to remain neutral, while trying to get the participating people engaged.

  • Pingback: My daily readings 03/04/2010 « Strange Kite