Tom's Ten Data Tips - February 2011

Retrospectives

Retrospectives are a standard ingredient of Agile software development practices. They lie at the heart of any successful Agile implementation. Retrospection means looking back; retrospectives are a more or less formal part of Agile methodologies which are meant to continuously improve the team’s effectiveness (so-called “velocity”: output per time period).

1. Begin Your Retrospectives With Appreciations

People only learn from positive feedback. Only. Of course that doesn’t mean you can reinforce stuff that was no good. But even failed projects will always have some good, useful components to them. No matter how terrible it went, you can always find something worth complimenting on.

The reason why positive feedback “works”, is that it reinforces behavior (elements) that should remain, allowing for the less successful elements to change. Criticism itself doesn’t invoke change, it extinguishes undesirable behavior. You still need something to replace it with. To ensure that desirable behavior does not get replaced, a little creativity will help you find good ingredients in even the worst of efforts. Regardless of how pitiful things have gone bad, for sure there was something worth reinforcing.

2. Take Your Time To Set The Stage

It is a good idea to take a few minutes, every retrospective, to set the stage. It provides the rules of engagement, clarifies how much everybody’s input is valued, and helps people get engaged and responsible for their mutual outcome. How often haven’t notoriously silent people provided that one nugget of wisdom that makes an entire retrospective worthwhile? Try hard to help everyone engage.

Sometimes you may be tempted to skip “setting the stage”, but rarely will this effectively save you time. It is so important to provide safety, and ensure everybody contributes, that spending five minutes to set the stage is a worthwhile “investment.” Cut corners here, and if only one person is not fully engaged, or worse, feels left out, you’re missing potentially valuable input.

3. Gather Data, Data, Data

In order to keep your retrospectives “objective” and free of chicanery as much as possible, it is absolutely crucial that all participants come prepared. Preparing data for the retrospective may or may not equate with graphs, tables or statistics. “Hard” or quantitative data are by no means superior. They can be useful though. As Einstein said: “Not everything that can be counted counts, and not everything that counts can be counted.”

It is equally valid (and useful) to gather observations, or quotes, preferably as “matter of fact” as possible. Something like: “When Cary said XYZ, this led the team down a path, neglecting the option PQR.” Try to observe and record, and detach from bias and value statements. The more factual your recording, the better it is. These data, as gathered during the previous time box are crucial to making the retrospective valuable. If you want to get more specific data, a great way is by asking: “What did you see or hear that led you to that conclusion?” (Weinberg, 1993).

4. Keep Your Retrospectives Fresh

A common problem with retrospectives is that they become routine. In fact, they can become so “routine” that eager developers can’t wait to get back to the “real” work of coding as soon as they enter the meeting. You need to combat this boredom. Bear in mind that sometimes such a ‘rut’ signifies an unwillingness or lack of safety to bring up challenging or difficult topics around team values or working agreements. Retrospectives are a recurring element at the end of every Sprint. Of course “sprints” apply specifically to Scrum shops, but all agile methodologies have some equivalent.

Your Scrum master owns the process, so it’s his responsibility to ensure all meetings are effective, including the retrospective. Don’t forget that meetings need to make up for imperfect communication during “normal” work. You can change up the exercise or activities, and you can alternate between “common” verbal exchanges and experiential exercises. When you let participants choose themselves, they become more invested in success. An experienced facilitator will have a chock full bag of exercises to choose from.

5. When You Provide Instructions, Wait For Questions

When you introduce some kind of new activity or task in your retrospective (see also tip# 4), prepare your instructions carefully. Sometimes you’ll want to memorize, or otherwise use some cue cards, just make sure you don’t garble up what participants are expected to do. Then after you have completed the instructions, ask for questions. Then wait. As in: wait for questions. Waiting always seems to take longer when you are speaking so wait a little longer. Someone will come up with a question, if you leave them long enough to voice it. And then often one question leads to more… The activity will go better for it, and participants are made to fee safer when they feel confident they understand the task.

6. Be Candid About Flukes, But Focus On Improvement

It is really important that everybody can say things the way they see them during a retrospective. If a piece of code stinks, it stinks. Too bad. Maybe delete it altogether, and start anew, whatever is most efficient. You cannot allow your ego to get involved, or soon the whole project could be coming down.

However, although it is important to vent criticism candidly, it is never OK to merely criticize. When you criticize, you must suggest solutions, or at the very least say what you want. What you would like to have happen. There’s another word for offering criticism without a recommendation, and we call it whining. It saps the energy from a team, and should not be allowed. Instead, demand from everyone who vents their discontent that they offer a suggestion or recommendation, or at the very least say what they’d like to see happening next.

7. Make Working Groups As Small As Needed

In order to give everyone a (fair) chance to speak out, you’ll sometimes need to break up into smaller groups for specific assignments (like sorting important events during the previous Sprint). It’s a trap to think this would be less “efficient” if reconvening as a group requires additional “summarizing” of sorts by sub groups. People will contribute more in smaller groups, and the additional “overhead” or regrouping and organizing items from all sub groups is easily worth the time and effort. There is just no short cut to providing safety and sufficient time for everyone to contribute.

8. The “Prime Directive” Helps To Hold The Space

The “prime directive” in Agile retrospectives was formulated by Norman Kerth (2001) as: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

In particular the phrase “did the best job they could” is often misinterpreted. It does not mean their effort was the best achievable, not even by this person (what ever that may be…). It also doesn’t mean it was good enough. It may not be good enough, and after attempted remediation, the team member may still need to be replaced. It does provide a mindset, however, that avoids casting blame, and that avoids making assumptions. It can open up your mind to inquire into someone’s motivations and reasoning when they did something you didn’t think was “optimal” (maybe terrible!), and to do so with a genuinely inquisitive attitude.

9. Make Improvement Goals Specific

One of the most common shortcomings from a retrospective is that improvement targets are too big, or too vaguely worded, to make them sufficiently useful. What’s worse, they might be interpreted differently among team members, each running off in their own direction.

If a goal comes out of the retrospective like “We need to get better at estimation” (a fair comment), you know it is too big a job to accomplish in (only) the next iteration (or Sprint, time box, or what you have). Break it up into smaller, more manageable objectives. Breaking up into subgroups, and identifying all constituent ingredients should do this within the retrospective, possibly. Then classify and cluster those, and have the team pick a chunk they feel they can handle until the next retrospective.

10. Retrospectives Need To Be Time Boxed, Too!

As part of your working agreements for the retrospective, you need to agree on a time box. Just like in other Agile practices, a time box serves multiple purposes. One of the most important is to help the team control the variable functionality that will be delivered. “Control” is the keyword here. By letting everyone involved know when the retrospective begins and ends, people share responsibility to have the most important issues brought up. Time boxing also provides “safety” in knowing the (time) boundaries of sometimes pretty confronting meetings.

If discussions haven’t ended, and the team still has energy, the facilitator’s (Scrum master) job is to confront the team with the incompatibility of extending the retrospective and proceeding with the next Sprint. Try to finish on time, and make note of points that were “left over.” You can enter these points at the next retrospective. If a pattern of overrunning emerges, you have another observation to contribute to the next retrospective.

Further reading

Some excellent books on Retrospectives:

Agile Retrospective: Making Good Teams Great.
Esther Derby & Diane Larsen (2006)
ISBN# 0977616649

Quality Software Management Vol. 2 First-Order Measurement.
Jerry Weinberg (1993)
ISBN# 0932633242

Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XP.
Ralph Hughes (2008)
ISBN# 0595471676

Project Retrospectives: A Handbook for Team Reviews.
Norman Kerth (2001)
ISBN# 0932633447