The Extreme Retrospective



Most agile methodologies have some way of analysing past behaviour, recording it for future reference, and modifying that behaviour for the betterment of the team dynamic.  SCRUM uses something called a ‘retrospective’. This takes the form of a meeting at the end of each sprint where the team write down their thoughts on the positive and negative aspects of the previous iteration in an anonymous fashion and then the group categorizes, discusses and decides on how to act on them.


The Extreme Retrospective combines the ideals of the retrospective with the personal and repetitive nature of the stand-up.



How it works


This activity only works with team sizes of around 5 or so as the nature of the Extreme Retrospective means the time taken to complete it increases geometrically as you add more team members.


To perform an Extreme Retrospective



Get the whole team together
Take your team and find a room where you can all sit down comfortably.


Each team member contributes
Normally the dev lead would start this the first time to show how to do this, but you can – and should going forwards – start with anyone.


Only one team member talks at once
This is the most important rule; Justifications, defences, and rebuttals are not allowed.


Be Self Critical
The person who is receiving the feedback can do one of two things. Take it on board and act on it or ignore it and continue as before.  This is a personal decision.


Give a ‘Feedback Sandwich’
In turn, go around each person in the room giving them a ‘Feedback Sandwich’, one piece of positive feedback followed by a piece of constructive feedback and finishing with another piece of positive feedback.


Move to your right
Start with the person to your right and continue anti-clockwise. Once you have done this for everyone in the room the person to your right continues. They start with the person to their right and end with yourself.


Repeat till complete
Carry this on until everyone in the room has given a ‘Feedback Sandwich’ for everyone else.


Why do this?


The retrospective is all about changing behaviour for the better.  It involves identifying things that individuals, and the team, do well and emphasising them and altering or diminishing those behaviours that do not work so well or are causing conflict.  It also does this in a personal and accountable manner, the opposite of how some retrospectives may be run.  By forcing team members to think about each other and spell out positive character traits as well as their perceived flaws you can bring down the walls that separate the team. The outcome of this will be a team that functions better, is able to easily identify problems and successes and is also able to comfortably give feedback to team members at any time, not just during the retrospective. This is especially pertinent for new teams that haven’t worked together before, but don’t let the fact that you’ve been working in your team for ages and you think you all work well make you think this isn’t for you.  It is! And if you do this, your team will be even better.


Timing


The first few times this will be a very uncomfortable exercise and it will take some time, maybe up to an hour or so. Do not let this put you off! As you become more familiar and used to doing it not only will this come easy to you and your team, but it will be come a quick and painless activity that you can chew through at the end of the day. Your goal should be to spend less than 15 minutes on this each time you do it.


In terms of frequency.  Do this as often as you can, whether that be one or twice an iteration or every day or so.  You’ll quickly notice a more enjoyable working environment but more importantly a better, more efficient team dynamic.


Written by Simon Middlemiss

Comments (6)

  1. Adam Gilmore says:

    Good post!!

    Did you set any ground rules for what sort of things could and couldn’t be said (I’m thinking things that could be taken as "personal") or did you just let it flow?

  2. SimonMiddlemiss says:

    The idea is to keep it project related, but since the Extreme Retrospective is all about changing behaviour some elements of personal introspection is inevitable.

    If there is the level of trust in the team to keep things professional then there should be no problems.

  3. Diana Larsen says:

    Simon,

    I’m a big fan of both agile retrospectives (as a co-author of the book) and peer feedback among team members. I perceive a couple of issues with your characterization of both.

    First, well-crafted, well-conducted, effective retrospectives are much more than writing down positive and negative aspects of the iteration. They set a time for the team to focus on one aspect of the work then learn, think, and make decisions as a group in the spirit of continuous improvement. They are more than a collection of +/-‘s. They are certainly open interactions and exchanges. Team members don’t contribute anonymously unless things have gotten so bad (usually through lack of peer feedback) that team members  physically or emotionally risk damage to one another.  For more on how to run effective retrospectives, please see _Agile Retrospectives: Making Good Teams Great!_ at the Pragmatic Bookshelf or on amazon.com. For other retrospective resources, discussion groups, etc., contact me.  

    Second, why advocate giving feedback publicly? Begin fostering a culture of giving feedback with the dev lead (or any person team members respect) giving (and seeking) feedback 1-1, frequently, as soon after the behavior as possible, and in good form. "Saving up" feedback until a special meeting only allows undesirable behavior to go on longer than necessary and makes the feedback a bigger deal.

    To serve the team well, the flow of feedback among team members should be expected, continuous and in real-time. Just like we get a flow of feedback from the code base through continuous integration.

    As a template, the "Feedback Sandwich"(FS) sends confusing messages. I encourage team members to give one kind of feedback at a time – feedback to change or stop behavior or feedback to encourage behavior. Mixing them in the same message diminishes the recognition of benefit and the desire for behavior change. Feedback receivers don’t know which is more important to pay attention to, so they often focus only on the part they like. The purpose of FS is make it easier for the giver (delivering the criticism seems easier when I get to say something nice too), when IMHO the whole purpose of a feedback session should be to enable the receiver to hear the message.

  4. I’m with Diana on the sandwich being a suspect method of giving feedback. The only person empowered to change one’s behavior is that person himself and for that to happen, he must be aware of his behavior and the impacts of his behavior. That awareness is not amplified by throwing in some good stuff, too. When we receive feedback we enter a state of cognitive dissonance, a gap between our self-image and an incoming message that contradicts that self-image. Facing such cognitive dissonance, we are hard-wired to do whatever we can to reduce that dissonance. In a feedback sandwich, it’s easy to downplay the sour middle in favor of the sweet surroundings. The only up-side with the sandwich is, like Diana suggests, that it’s easier to give such feedback.

  5. SimonMiddlemiss says:

    Diana, Lasse,

    First off, thanks for your comments.  One of the key goals of this blog was to start conversations, so it looks like we have succeeded in that!

    I agree that I’ve been overly brief in the description of what a retrospective entails, I wanted to concentrate on the dynamics of how we ran these feedback sessions, so my apologies for that, I’d also agree that your book is a good place to go to find out more on the subject of retrospectives, nice product placement by the way!  

    I think it is important to note that these sessions are in no way a replacement for the retrospective, I’ll also concede that, because of that, perhaps ‘Extreme Retrospective’ isn’t the most accurate of terms?  The name was coined and it stuck!

    I do however believe they form an important and constructive role.  Agile is all about changing behaviour through repetitive action.  One could say that "saving up" blockers until the beginning of the next standup promotes exactly the same undesirable behaviour that you bring up about these feedback sessions.  This isn’t the case though, as the repetitive nature of the standup means that the reluctance of team members to raise problems with their work is minimized.  These feedback sessions do exactly the same thing, by setting aside a regular timeslot for team feedback, the barriers to giving accurate timely feedback on behaviour are broken and you start to see the team giving feedback consistently throughout the day.

    That’s not to say that regular 1:1 feedback sessions with the dev lead are not important, they most certainly are.

    With regard to the ‘Feedback Sandwich’; this is a technique which is used in many arenas.  It is used frequently in sports and also by organisations like ‘Toastmasters’ to ensure that participants are not solely receiving negative feedback, giving bad and good together is fine as people understand they need to act on both.  The other advantage of surrounding negative feedback with positive feedback is that people actually learn to give positive feedback.  It is all too often the case that what people are doing right is overlooked.

    The most important thing though is that it worked for us, any maybe it might work for you too…

  6. Benjy says:

    I think the “sandwich” becomes important when the time ‘slice’ between feedback sessions is big. If the retrospectives are occurring at the frequency Diana talks about then perhaps the sandwich isnt needed because by then people will focus on the core issue and the behavioral change needed, otherwise, it becomes very demoralizing for the person to hear only negative things. This becomes counter-productive in the long run. It’s a bit like the standup. It takes a few meetings for some folk to talk about their blockers especially if they are the type who pride themselves on ‘getting things done’ (maybe the Lone Ranger factor comes in here) or if they come from an atmosphere where stating a blocker may be considered whingeing. IMO, being pragmatic means we adopt these things to team culture, maturity, exposure (to these practices) and so on.