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