|Some Patterns for Iteration
|These patterns (or perhaps proto-patterns)
discuss how to use iteration retrospectives as a way of helping a
team reflect on and learn from the project while it's still going
Some goals of retrospectives:
- Build a safe environment
- Build trust and participation
- Appreciate successes
- Provide a framework for improvement
- Face issues
- Set team "rules": create and evolve the team's process
The organization of these patterns:
- Iteration Retrospectives (1)
- Safe Space (2)
- Bag Check (3)
- Anonymous Responses (4)
- Open Format (5)
- Safety Blanket (6)
- Reframing (7)
- Backward and Forward Look (8)
- Deeper Dig (9)
- Fish in Water (10)
- Facilitator's Toolbox (11)
- Change in Pace (12)
- Tentative Rules (13)
- SMART Goals (14)
- Smaller Bites (15)
Iteration Retrospectives (1)
Retrospectives are effective tools for helping teams learn
from experience, but after a project, it's too late (for that
project). Agile teams deliver frequently, but often can't afford to
do a full project retrospective after each delivery.
Hold short retrospectives at the end of each
They typically take 15-60 minutes; when this is
first done it will tend to take on the longer side. Invite the
whole development team. [But - there may be power issues related to
management, so be careful about these.]
Note that iteration retrospectives don't preclude project
Related Patterns: Section II. Safety discusses
ways to make people comfortable sharing their concerns. Section
III. Language considers a couple speech patterns you may
want to be aware of. Section IV. Structure looks at
different ways to organize the retrospective session. Finally,
section V. Outcomes considers how the team takes the results
of a retrospective and applies it back into the project.
* * *
It's risky to say certain truths aloud. A retrospective needs to
take that into account. These patterns talk about the need for
safety, and how to take advantage of trust as it builds up over
Safe Space (2)
Most people have thoughts and concerns they want the whole
team to know, but people won't share their inmost thoughts unless
they believe it's safe to do so. Iteration retrospectives don't
have enough time to slowly build rapport and safety.
Let repetition and familiarity build safety over time. Use
safer (more anonymous) mechanisms at first, and move to more open
ones as people become comfortable.
Related Patterns: Bag Check(3) provides a means of
getting over uncertainty about the benefits. Anonymous
Responses(4) provides a way to let people say hard truths;
Safety Blanket(6) provides another way. You can move to a
more Open Format(5) as people trust each other more.
* * *
Bag Check (3)
In extremely sensitive situations, people may have concerns
that they're not willing to ignore. But if they don't set them
aside and cooperate, the team can't do its job at all. People can't
wait a week or two to resolve this.
Each day, let people have a brief, structured chance to
express their concerns, and temporarily set them aside.
Example: Some teams use a "bag check" or "parking lot" protocol,
where they explicitly identify concerns at the start of the day,
but then set them aside to work. At the end of the day, there's
another meeting where people can "reclaim their bag" (if it's still
a concern) or "abandon their bag" (if the concern has dissipated).
This lets the team acknowledge their concerns, but still work.
Example: Scrum teams have a daily meeting where people tell what
they did yesterday, what they intend to do today, and what's in
their way. (XP teams often use a similar "stand-up" meeting.)
Example: The Core Protocols (Software for Your Head) have
explicit protocols for Check In and Check Out, so people can tell
the team when they are engaged or not.
* * *
Anonymous Responses (4)
Saying nothing feels safest, but deprives the team of a
chance to learn and improve. It's hard to be the first to
speak. It's hard to understand other people's perspectives.
Use anonymous or semi-anonymous techniques to make it safe to
communicate things it might not feel safe to say out loud.
Example: A technique for anonymous responses would be to have
each person write a topic on a card, then have the facilitator
shuffle the cards, read them, write the topic on a chart, and
destroy the cards.
Example: A technique for semi-anonymous responses would be to
have each person write a topic on a sticky note, then walk to the
chart and place the note where they think it belongs. Someone
determined to break the anonymity could watch for handwriting, or
see who put what where, but it mostly lets people act "as if" they
don't know who wrote what.
Related Patterns: Expect to be able to move to a more
Open Format(5) as people build trust over time.
* * *
Open Format (5)
Over time, the group becomes more comfortable and people feel
they can safely say what they want and what they see, but the
meeting structure has excessive concern for safety. The team wants
to review more quickly, but the safeguards slow them down.
Evolve to a more open format. Retain a way for someone to
request a safer format when they think the team needs it.
Example: Instead of placing sticky notes, let people call out
topics to a facilitator.
Example: Let others on the team facilitate the review.
* * *
The way people discuss things can reveal things about a
Safety Blanket (6)
If an issue is sensitive enough, saying, "I'm concerned about
this issue" (even anonymously) can feel risky.
Wrap the concern in a "safety blanket": instead of "What
concerns do you have?," ask "What concerns do you think people on
your team have?" or even, "What concerns do you think people on a
similar project might have?"
Note: As people learn to trust each other, this
pattern can fade away.
Related Patterns: Safe Space (2).
* * *
People omit subjects and objects in their sentences, making
hidden assumptions. People ignore their own power and wait for
others to do things. People mistake wishes for needs.
Recognize when this is a problem, deconstruct what is said,
and re-frame it into a statement that is active and under control
of the speaker.
Example: "Management ought to provide snacks." Is this because
the team wants snacks, or wants a demonstration that management
cares? If it's the former, people could start bringing snacks in
and try to create a trend.
Example: "Somebody ought to make sure it works before QA gets
it." This is much more powerful, when turned into an explicit
request, "Developers, for each story would you add an explicit task
to double-check that it works before marking the story done?"
* * *
These patterns consider the structure of the retrospective, and
ways to explore what the team thinks.
Backward and Forward Look (8)
Some things have gone well, others poorly. Some problems are
temporary, others last longer. Talk alone doesn't change
Use a framework that looks both backward (to what happened)
and forward (to what we intend to do in the future).
Example: The SAMOLE framework asks people to suggest things that
the team should keep doing the SAme, things the team should do MOre
of, and things the team should do LEss of.
Example: The PMI framework (deBono) asks people to consider what
is Plus, Minus, or Interesting.
Example: The WW/NI framework asks people to consider what Works
Well and what Needs Improvement. (This may be augmented with
explicit "Resolutions" for how to act in the future.)
Example: The WW/DD framework asks people what Worked Well and
what they would like to Do Differently. (This is sometimes known as
the Plus-Delta framework.)
Example: Appreciative Inquiry approaches focus on peak
experiences and how to recreate them, rather than on what's gone
* * *
Deeper Dig (9)
Just because an idea is on the table doesn't mean everybody
agrees with it. People may have other things to say. Other ideas or
problems may be more important.
Mine the data for areas of agreement and areas of conflict.
Compare this retrospective to previous ones.
Example: You'd like to know how important a concern is. In
anonymous forms, you may see the same topic appearing multiple
times (perhaps with similar words). In an open form, you can vote
or multi-vote on what's important.
Example: Sometimes the same topic may appear in multiple
categories, representing a conflict. One person may think the team
is refactoring too much, another that it's refactoring too little.
You may take this information and try to surface where the rest of
the group is.
Example: Sometimes the same topic may appear in multiple
categories, without being contradictory. Someone may write that
refactoring worked well this week, and the same person suggest that
refactoring needs improvement.
Example: By looking at the previous retrospective, you may see
that an issue recurs. This may help a team learn that its
interventions aren't working in this area.
* * *
Fish in Water (10)
Some problems are like water to a fish: so much part of the
environment that they're hard to notice. Other problems are
noticed, but not named.
Actively seek to find what the team is not seeing or not
saying. You may need to create extra safety to make it safe to
Example: People sometimes talk about the "elephant in the room":
a problem so big it can't be ignored, but yet it's never mentioned.
For example, hurtful behavior by a manager could be very hard to
Example: People may get used to something and forget about the
possibility it could be changed. For example, the room is always
the wrong temperature, or this tool always crashes.
* * *
Facilitation Toolbox (11)
An unexpectedly sensitive issue arises, or something comes up
that doesn't fit the team's usual framework.
Maintain a set of facilitation techniques, and use them when
Example: Break into small discussion groups
Example: Use a Structured Sharing technique (Thiagi –
Example: Use multi-voting, prioritization, polls, etc.
Related Patterns: If trust has shifted, you may need to focus
again on creating a Safe Space(2).
* * *
Change in Pace (12)
Using a different format each week adds novelty, but makes it
hard to develop a rhythm. A standard format can make it easier to
do retrospectives week after week, but it can get boring after a
Periodically (e.g., every two to three months) try a
different retrospective style. This could be a one-time event, or a
change for retrospectives going forward.
Example: Change the standard format from SAMOLE to WW/DD.
Example: Play a retrospective game (such as one based on a
classification card game).
Example: Try one of the exercises in Norm Kerth's book
* * *
Tentative Rules (13)
People need agreement on how to work together, but people
resent being told what to do.
Let people explicitly set the rules under which they'll work
together, and provide feedback mechanisms so they can adjust them
Keep rules fluid. The stance is "trying on a shirt" to see how
the shirt fits and feels, without committing to buying it
Example: Many agreements require consensus. People must agree to
live with the rule, perhaps for a fixed time. (Even someone who
completely disagrees with a strategy may be willing to give it a
fair chance, so others can come to disagree with it for
* * *
SMART Goals (14)
People suggest protocols that are too fuzzy to assess, or not
well enough understood to act as guides. People state ideals as if
they were rules.
Use the SMART acronym to guide the creation of effective
S - Specific
M - Measurable
A - Achievable
R - Relevant
T - Time-Boxed
Example: "Refactor better." It's hard to argue with, but it
doesn't actually tell anybody what to do. The team can break
this up into concrete actions, such as, "Pick a smell each week,
and spend an hour each Wednesday trying to find examples of it," or
"When you check off a task, write Yes or No beside it to indicate
if you looked for refactoring opportunities before checking
Related Patterns: If your goal isn't met, you may try a
* * *
Smaller Bites (15)
The team wanted to try something new, but they didn't get
around to it or it was too hard. This is especially a concern if an
item has been on the team's list for two or more iterations without
Try something similar, but easier.
Example: "Automate at least one customer-specified test for each
story" was the goal, but the team didn't do that. They might agree
to "Automate a customer-specified test for the next story we
This pattern helps a team converge "What we say we'll do" with
"What we really do." Once smaller bites have been mastered, the
team can move back up to the bigger goals.
* * *
Cockburn, Alistair. Agile
Software Development. Addison-Wesley, 2001. "Reflection
workshops" are a top-level practice in Crystal Clear.
Kerievsky, Joshua. "How
to Run an Iteration Retrospective." 2002. <www.industriallogic.com/papers/HowToRunAnIterationRetrospective.pdf>
Kerth, Norm. Project
Retrospectives: A Handbook for Team Reviews.
Dorset House, 2001.
McCarthy, Jim and Michele McCarthy. Software
for Your Head: Core Protocols for Creating and Maintaining Shared
Vision. Addison-Wesley, 2001.
Kaner, Sam, et al. Facilitator's
Guide to Participatory Decision-Making. New Society
– Training and games.
[Originally developed August, 2003 for an OOPSLA workshop
on retrospectives. Edited and re-organized, September, 2005. Added
references to Cockburn and Kerievsky, Sept., 2005.]