Ready! Set! Retrospect! Breaking the ice on Agile Retrospectives

“Ahh, the reward for a year’s worth of toil and sacrifice.
Retrospecticus!”
(Lisa Simpson)

Para leer este post en español, clickea aquí.

It goes back to the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”. We’ve all heard about this gathering where we review all that happened the previous sprint (some of it, actually) and learn from the experience. It’s like we are pieces of an intrincated puzzle pushed together at the end of the iteration, hoping to form at least 80% of the whole landscape. It’s a time to look for lessons learnt and methods of improvement, with the goal of constant revising, inspecting and adapting. With this in mind, everything always goes smoothly and the team is never ever reluctant to join and participate on these meetings, giving their all, sharing their experiences and concerns openly and without any shame.
Well, not quite.
There are a lot of glitches or complications that might arise when facing this kind of meetings in which a team should come clean on opinions and experiences, about themselves or about each other. Although they are relatively short in length, there might be time issues when not preparing everything beforehand or wasting minutes while getting the room ready or scouting for team members around the office. There might be connection mishaps or any of the usual setbacks that pop up when dealing with distributed teams.
But don’t worry, where there’s a will, there’s a way.
Let’s dig out and analyze some of the problems we could be facing and, hopefully, sweep them off the board.

Cold feet, anyone?

I was just starting on a project when I had my first Retrospective. Supposedly they’d trained me beforehand. I had been participating on retrospectives in the warmth of my apprentice team, dealing with people I had lunch with everyday, discussing insights on my work, issues that surfaced on this little project we were into. Nevertheless, whenever I talked about these meetings with other co-workers in the office, calling them retrospectives, they usually frowned a little and said, “Well, we call them retros but they’re not actually retrospectives”. Little did I know what I was doing was just a hint of what was to come working on a full enterprise project.
The morning before my first real retrospective, I was looking for things to say, on coffee breaks and water dispenser trips, and I was confident I had a nice 2 or 3 minutes of speech prepared. When the time came there I was, facing four people who had been in the project for years, who started talking about experiences I had never had, or problems I had never faced, and I got blocked, gasping for words, my brains got stuck, my tongue swelled up. The whole meeting went through and I couldn’t say a thing. Couldn’t even present myself properly when asked to. All my fears came to life, my self esteem dropped dead, and I think I even felt cramps coming up my left arm. Well, it might not have been that hard, but, what happened? And most importantly, what to do so it doesn’t happen again?

Notepads to the rescue!

First of all, when facing people in a meeting, don’t ever imagine them naked. Take my word on it, it would only make things worse. Instead of just thinking what you would say a few hours before, write things down along the sprint. Did you notice velocity goes up when pairing? Write it down. Have you got longer dead times because of lack of tickets? Write it down. A team member came back after a long vacation? Write it down! Did you find a lot of duplicated code while working on a God forgotten part of the project? Write it down! The light went off on your refrigerator? Well, mmm, you better keep that off. And I know you’ve heard thousands of times that everything could be solved making a list, from relationship issues to grocery store doodling. But on this case it actually works!. Anyway, I would call it “developing a list” instead of “making a list”. On your daily work, have a notepad at hand (I rather have real paper than files) and whenever you consider something worth of mentioning to the team, write it down. Even if it’s a minimal issue. Do it right then and there, just as musicians write down their ideas for a song so they don’t forget it after inspiration strikes. Then, a couple of hours before the meeting, read them and edit. You’d be surprised how brief ideas or concerns come to life when you put them in context, and you’ll also get a sense of repetition, like you’ve talked about them before. Mind you, this works. Get your hands on it, it will only take seconds and you’ll be good to go. So when you’ve got to explain what you’ve written down on the trello or whatever tool you’re using, you’ve got a little blueprint you’ll go along smoothly.

A whole team and the dog under the wagon (or not)

Of course you’ll feel insecure. They, at least in your mind, are the masters of the codeverse, the lords of the project, creatures of infinite wisdom and complete awareness of the system. They don’t even never ever use double quotes instead of single ones. Their code and their technique are flawless. They don’t even use rubocop. How could a simple newbie like you, who has pushed duplicated commits and messed up the whole branch history (TWICE!), live up to their expectations and be at the same level.
Well, it’s not like that at all.
I found my fears had no reason quite down the road. Building up my self confidence took some time, even when my whole team was very supportive and helpful. Now, here’s a gift from the vaults of Agile Wisdom to shorten your road to courage: “Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.” Pretty neat, isn’t it? That is the Prime Directive (Yeah, capital letters, that’s how meaningful it is) introduced by Norman Kerth back in 2001, just as the agile manifesto was THIS little (Imagine my thumb and index finger separated by 1 inch). It has such an importance it should be read before each retrospective, in Latin, preferably.
Although it’s self explained and easy to understand it’s essential to become more secure about the role we play on the team, and what can we bring to the table when dealing with some problems. I found out some of my teammates (I’m not throwing anyone under the bus, but it was…) to make the same mistakes I did, and sometimes, I’ve done progress on things that had been on the icebox for ages. Keep the Prime Directive in mind and know that grown ups make mistakes, even the most trained and intelligent grown up you can think of. Ken Blanchard’s quote: “None of us is as smart as all of us” is key. No matter your level of experience or seniority, they know and you must know yourself that you are as important as everyone else on the team. As a matter of fact, the point of view of a newcomer is usually less polluted by preconceptions and subjectiveness. And quite well received too. Use your naivety to your benefit. It’ll pay off.

Lost in translation

What? In English? How many? Not only I hadn’t met any of those people before but on top of it, I had to speak in English. I have to admit, I had spoken English many times before, both abroad and with some friends visiting, but never on a work environment, never with client’s representatives, and never ever on a project I was just starting.
Once the meeting started, and even with some academic language background, I couldn’t understand most of what they said, and couldn’t develop single sentences, let alone complex blocks of speech. As a matter of fact, after all that struggle, my nerves were unjustified.
There are a couple of bullet points when dealing with a meeting on a foreign language. First of all, cool down. Accept you’re not a native speaker, don’t force an English accent. Know your audience. Most of the time project owners or team developers are used to work with people around the world. In fact, if the client is based in Europe, some of the team members working at the same office might as well be from different countries around the continent. Remember the Prime Directive, it doesn’t just apply on a work related matter. They know you’re doing the best you can, and they are putting the same effort on understanding you that the effort you put in talking their language. At first don’t experiment nor try complicated sentences. Keep it simple until you’re confident enough. They’re not looking for deep eloquence and you might get your tongue struggling for the right words.
Remember most of your work is done in english, so when trying to explain issues found since the last iteration, or feelings among the group, use the tools you know, the slang you write down every single day. You couldn’t do it if you were talking with your mom, but we’re among developers here. Everybody knows what you’re talking about. Remember the notes I told you should take before? Take them in english and imagine how to describe them. Those are the perfect spoilers for next retrospective. When someone else’s talking, look at the way they speak, gestures they make, what words they strain the most, get the core meaning. We all lose some words, it’s almost impossible to get everything, but if you get the key subjects, you’ll be ok.

Faraway, so close!

It’s quite tricky to run a retrospective when people are not really there. But nonetheless, they are the cornerstone of any highly functional distributed team. Spoiler alert! You’ll be working with people from around the world. So post-its on the whiteboard won’t do it. Or at least won’t do it as well as when you’re having jolly cute meetings (chips and beer included) with your office teammates. Get familiar with online tools. You have to master Google meet, trello and whatever soft you’re using as soon as possible. Try them beforehand to make sure you don’t start with the wrong foot.
The process for hosting a remote retrospective is similar to a meeting in person with the whole group, but being in the same room with people is more powerful because of the high-bandwidth communication you get. You could see if someone is getting tired or frustrated. On a remote retrospective, the team usually starts with a silent brainstorm to collect topics, following a variation of the “What did we do well?”, “What did we do less well?”, “What still puzzles us?” questions. Topics are then categorized, voted on, discussed one by one until the team runs out of topics or time.
Some tips to ease the experience. Avoid all cellphone peaking and keyboard hitting. If you want to be taken as a whole member of the team, and want to get all your experience taken in account, then you have to be there as a whole. Pay attention. You can leave the rest of your work for later. Isn’t it nerve wracking when you’re talking with your heart wide opened and your coworker is looking at the phone? Leave the phone down! Keep your hands off the keyboard when someone’s talking.

In retrospect

Once you’ve become familiar with retrospectives, you get more confident inside your team, and close to both colleagues on your own office or remote coworkers, you’ll get the most out of them. Remember some of the key points I’ve talked about. Apply them if you feel comfortable or keep looking for tips and hints online.
The basics of retrospectives can be explained by elaborating the key questions I’ve mentioned before. We ask “What went well?” to explore and celebrate the good practices the team is doing. This brings energy to the team, and pushes them to experiment further. When we ask “What went less well?” we explore the background of problems that have arisen, developing a shared understanding of the issues at hand. We ask “What still puzzles us?” to help team members have a chance to ask about issues that might have gotten caught on the speed of the iteration.
All in all, hopefully this post will help you break the ice on the retrospective experience and enable your team to go from strength to strength for years to come.