Running your own Retrospective
I’m running a training course for TDD and OO design at one of our clients.
Normally when I teach this, it’s to Thoughtworkers or client staff working with Thoughtworkers. This time, I’m teaching fairly experienced clients who have some idea of OO already. I’ve been trying to teach more advanced techniques – communication with customers and how it drives design; starting with the UI and a good concept of ‘done’, etc.
I could see that occasionally, some of the participants looked uncomfortable. Whenever I asked them for feedback, they told me that they were having fun and learning a lot! Yet I could see that they were still uncomfortable – they just couldn’t tell me why.
So, at the end of the second day, we ran a small retrospective. Normally, I would ask a facilitator to run the retrospective for me, but we didn’t have one. Here are some things I did that seemed to work, and help the retrospective to run smoothly.
Make them feel safe with you
It’s awkward running a retrospective when you’re the one who’s likely responsible for the things that aren’t working quite as well as they could. It’s especially true if you’re a stranger to the group, or the group isn’t used to giving and receiving feedback, or both. I wanted to introduce to the participants the idea that they should feel safe giving me feedback; that I would react to that feedback positively and wouldn’t criticise them for giving it. I also wanted to give them an idea of how they might run retrospectives for themselves.
So this is what I told my participants:
I’d like to use a retrospective format to get an idea of how best I can tailor this course for you.
In a retrospective, we start with the Prime Directive: that no matter what we find out, we know that everyone is a good person and has done the best job they can in the situation. I believe you’re all good people. I hope I’m a good person. I think that the job I’m doing here is a good one, but I’d like to make it better. There are ways in which you could phrase feedback positively. That would be nice! But even if you can’t find a way to express things positively – I still want the feedback. I have a lot of confidence in myself and my abilities. I can take it!
Then, I ran the safety check. The participants felt safe enough (mostly 4s on a 1-5 scale) so I went ahead.
Make them feel safe with each other
I asked all the participants to draw a picture to represent how they felt about the course so far.
I could see their eyes light up as everyone put the pictures on the board. Eight faces with question marks, puzzled expressions and light-bulbs. Everyone felt slightly puzzled, slightly confused yet enlightened! I think this helped them realise that their confusion wasn’t unique.
Make them feel safe with themselves
People are usually happier giving feedback if they can find a way to phrase it positively. Fortunately, this is easy! For every “less of” there’s usually a “more of”; for every “stop doing” there’s often a “start doing”; for every “fear” there’s a “hope”.
Often in retrospectives we insist that people put one thing in each category. I didn’t want to do that this time, because I felt that people would be uncomfortable with the idea of giving me lots of “less of”. Instead, I left them free to think of more positive ways of expressing what they wanted.
I encouraged them to think of ways of changing things by adding three categories:
- More of / hope
- Less of / fear
- Puzzles
I explained what the categories were for, and asked them to come up with about five things that they wanted to put in these categories. To show them what I meant, I drew a pint of beer and put it in the “hope” category, then told them that I hoped that we could all go out one evening for something less formal.
Then I let the participants loose on the board!
Proof that it works
The participants wrote things like “Hope for more time to come up with a solution!”,”Hope not to be so confused by other people’s designs”, “Hope for more tea breaks”, “Hope for better understanding”, “Hope we get to learn more about Agile”, etc. There were very few fears – “Afraid I’ll fall behind” – and a couple of puzzles that were either easy to answer or I promised would be answered as part of the course.
I asked them to talk in more detail and give examples of times when they’d been confused, etc. We came up with a lot of action items as a result of the things they put on the board:
- Break down exercises into smaller chunks
- Baseline code bases (move to one common solution for the exercise) frequently, to allow people to swap pairs and stop them being overwhelmed by the differences when they do
- Allow more time for analysis of the solution and for questions
- Participants to tell me when they want a tea break
- Pub next Thursday
I also found some things which they wanted me to teach which weren’t really part of the course, so I made a mental note to slip the easy things in when the time came, or provide them with links to resources where they could learn themselves.
I checked that they thought the action items would meet their hopes. That feedback was very valuable, and far more useful than “Oh, we’re having fun and learning a lot!”
The safety check is the most important thing
It was very important to me that the feedback I got was honest and accurate. For that reason, I was extremely careful with the safety check. I made sure that it was visibly anonymous – I got one of the participants to gather up the pieces of paper, and made sure that they used identical paper and pens so that no one could be identified.
If they hadn’t felt safe, it would have given me feedback about my approachability, and how well I had expressed my desire to get feedback. It might also have indicated that people didn’t feel safe with each other. I guess if that had happened I would have run more icebreakers, more fun exercises that let people relax, and I’d have looked carefully to see if there was any personal feedback that I needed to take on board or give to individual participants. I’d also have tried hard to find an independent facilitator to run the retrospective – but I wouldn’t run it with a low safety check. I also let the participants know this, and reassured them that I’d do some different things to try and make the environment better if the safety check was low.
Thanks Pat!
Pat Kua loves retrospectives, and has taught me their importance and a number of techniques for running them. They’re my second-favourite practice. My favourite is Small Releases – actually delivering the things you promised to deliver – and I use retrospectives to work out why I can’t deliver, or how we can deliver better, or sooner. This can apply just as well to training courses as to code.
I was quite surprised by how well the retrospective worked. Talking about it with my co-trainer Arvind afterwards helped me realise how the things I had done instinctively added to the environment of safety and helped the participants give me the feedback I needed. I hope it’s helpful for you too.
Agile Mumbai slides are up
Naresh Jain has very kindly put up the slides from my BDD presentation at Agile Mumbai.
I deviated quite heavily from previous presentations I’ve done and talked about the history of BDD, how it evolved and the people and events that made it happen. You can find links on the last page to some of the more influential sites, groups and people – all good places / entities to hang around for innovative thought and challenging questions.
Many thanks again, and particularly to Dan for being unavailable, Naresh and Agile India for inviting me instead and Thoughtworks for letting me go.
BDD for TDDers
Anthony Bailey and I had a conversation over email about what good, experienced TDDers might get out of BDD.
If you’ve been wondering what all the fuss is about, maybe this will help! Thanks, Anthony, for tidying the conversation up so nicely.
Peter Bell and I had a great conversation over Skype yesterday, which he’s kindly blogged. We covered test names, and also talked about how to develop libraries using BDD. Again, this is how I do things; it’s not necessarily the only way.
Peter’s mentioned JBehave 2, so the secret’s out now – yes, it’s in progress. It’s not publically available because it’s just a spike at the moment. We’re starting afresh, learning some of the lessons that made JBehave 1.0 hard to use, taking advantage of JUnit 4’s features, and drawing heavily on the success of RSpec.
Our goals for JBehave 2 include:
- no internal support for mocking – should be able to use any of the libraries
- extends JUnit – right-click and run both behaviours and scenarios
- uses Hamcrest’s matchers
- uses plain-text scenarios à la RSpec
Here’s a sneak preview of the spike so far.
We have a scenario file, i_can_toggle_a_cell:
Given a 5 by 5 game When I toggle the cell at (2, 3) Then the grid should look like ..... ..... ..... ..X.. ..... When I toggle the cell at (2, 4) Then the grid should look like ..... ..... ..... ..X.. ..X.. When I toggle the cell at (2, 3) Then the grid should look like ..... ..... ..... ..... ..X..
We have a small class in the same package to run this, called ICanToggleACell.java (the Scenario class is a JUnit test):
package com.lunivore.gameoflife;
import org.jbehave.scenario.Scenario;
import com.lunivore.gameoflife.steps.GridSteps;
public class ICanToggleACell extends Scenario {
@SuppressWarnings("unchecked")
public ICanToggleACell() {
super(new GridSteps());
}
}
And we have steps defined thus:
package com.lunivore.gameoflife.steps;
import static org.hamcrest.CoreMatchers.equalTo;
import static org.jbehave.Ensure.ensureThat;
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
import org.jbehave.scenario.steps.Steps;
import com.lunivore.gameoflife.domain.Game;
import com.lunivore.gameoflife.view.string.StringRenderer;
public class GridSteps extends Steps {
private Game game;
private StringRenderer renderer;
@Given("a $width by $height game")
public void theGameIsRunning(int width, int height) {
game = new Game(width, height);
renderer = new StringRenderer();
game.setObserver(renderer);
}
@When("I toggle the cell at ($column, $row)")
public void iToggleTheCellAt(int column, int row) {
game.toggleCellAt(column, row);
}
@Then("the grid should look like $grid")
public void theGridShouldLookLike(String grid) {
ensureThat(renderer.asString(), equalTo(grid));
}
}
I’m excited that this actually works. The next step is to get appropriate error messages when the scenario fails! We’re working hard to get this out to you as soon as we can; watch this space.
Your horoscope for April
How people
You’ve spent years making yourself invaluable to your friends, family and colleagues. Your confidence is at an all-time high – how many people in the world can do what you do? Watch out, though; pride cometh before a fall. You’re a deep roller. Let’s hope one of your parents was not.
Your tool of the month is Mingle Proj-o-matic.
Why people
Yesterday the room was crowded. The smell of pressure hung heavy in the air. The quiet tap of fingers on keyboards, the whispered conversations, the passionate arguments, the occasional round of applause as a story reaches completion – these were the sounds that punctuated your life. So how come it’s suddenly so quiet?
Your word of the month is anachronism.
Who people
They promised a future in which robots clean the house, food is manufactured by holes in the wall, money is irrelevant, war is history and learning is taken in pill form. It hasn’t happened yet. There’ll always be work for people people – shelve any plans you had for holiday this month; you’re needed right where you are!
Your pub of the month is Leela Palace, Bangalore.
When people
A blank page can stifle the most imaginative mind – sometimes creativity requires a place to start. Still, if mistakes are cheap then there’s room to play. Imagine a world in which you could write things down in English, and just have it work. Imagine what would happen if you didn’t even need to write it down. The brain is the most amazing computer in the world… so far.
Your quote of the month is:
Any sufficiently advanced technology is indistinguishable from magic.
Comments