September 23, 2020 by Marco Cecconi
Good Agile teams routinely run retrospectives to identify problems and improve their process and team outcomes. It might have been an innovative idea 15 years ago. Nowadays, it is an everyday practice for teams to do so as it's an obvious and uncontroversial way of identifying and fixing issues in the way they work.
However, many companies do not apply this lesson to identify and fix the company-wide issues they invariably must have. When a customer calls us at Intelligent Hack, this is one of the first actions we take - put everyone in a room, do a retro, and listen to the employees. One would think this results in an unfocused mess, but how often are they asked to express their feelings and opinions openly?
The outcome is usually a well-defined set of issues that the company management can often quickly solve once identified or taken into account. Are salaries too low across the company? Better to know that your employees feel that way. Do your employees feel there is too much bureaucracy? Again, perhaps you can focus on that.
Retrospectives are a much superior tool to questionnaires and surveys to identify company issues. First of all, a retrospective is fundamentally an organized brainstorm. In other words, it encourages people to build upon each other ideas, which prompts people to speak up and say things in a more prominent, exact way than in a survey example. You might see a person adding "some salaries are below industry standards," but this often triggers another person to add a way more direct "salaries are meager" once they break the ice. Encouraging people to speak up is one of the well-known positive side effects of retros.
Another thing you can expect is to get a priority list out of the retro. Not only will you be able to see the problems -- and often the strengths -- of your company, but it will also be possible to take the pulse of how strongly people feel each.
Finally, it is usually a sobering eye-opener to management that has not fostered a culture of feedback. Without being explicitly prompted, most people will not provide constructive negative feedback, and often they will not do so even if you ask directly, putting them on the spot.
You need to get the right size: most companies I work for are below 100 employees, and a single retrospective is the best way to go. Over that, I would consider running multiple retros. I do not know how to scale this meeting to much larger companies - we have never done it, and I do not know if it is feasible. If you get to try it, let us know!
With numbers below 100, both online and in-person retros are possible. Still, of course, in-person retros are best -- reading body language, having many-to-many interactions, etc. are all parts of a healthy retro.
These retros are expensive, so they need to be efficient and do not happen often. I suggest using a format that is both backward-looking and forward-looking in this case. I would also stay away from the most "exotic" structures simply because with larger numbers, simplicity, and being immediate become incredibly valuable assets. The "start, do more, do less, stop" format is direct and addresses both aspects ("start" and "stop" apply to the future, "do more" and "do less" reflect on the past). You can also add a "continue" column if you prefer.
If you are running this in person, make sure there are hundreds of post-it notes and pens. Also, there must be a wall to put the post-its and the retro columns, which you can mark out with vertical masking tape strips and a sheet of paper as the column title. People should have places to sit, ideally in a semicircle around the wall, and, if possible, they should have somewhere to write. The room should not be too packed.
First of all, run an introduction -- explain what a retro is and what to expect. Tell people to focus on problems and behaviors and not on specific people. Make it clear that retrospectives are blameless and that everyone is welcome to express their opinions. Explain the format and what goes in each column. Remind people to include the column on the post-it so you won't lose the context as you move the cards around later.
In the first stage of the retrospective, have people add post-its to the columns and read them aloud, inspiring others. It's impossible to see what others have been writing in such a vast context, so verbal communication is essential. Online retros don't have this problem, but I would strongly suggest that you make cards visible from the beginning. To break the ice, I usually add one or two obvious, funny, or relatively unimportant cards at first to break the ice. Do not enforce a specific time. Encourage people to add cards continuously instead. Make sure you repeat it's OK, and all opinions are equally valid. If you identify unengaged or shy people, politely encourage them to participate.
When you see people are not writing anymore, or very little, or when you see that the "loud" part of the audience starts to take over the conversation, it is perhaps time to close the first stage and start grouping. If you have many cards, you will need some helpers here. The idea is to cluster cards into topics for discussion. Online software should have this feature, but offline, you can easily add a strip of masking tape to the wall spelling out the subject next to each cluster. Once you feel you have reduced the topics to the right amount... take pictures of the wall, so they are readable -- you will need this to write up the results!
If the now-ready clusters are too many to talk about, ask people to pick 3 to 5 topics they prefer, perhaps allowing multiple votes. Trust people to stand up and go to the wall, adding a tick or more to the subject they want to discuss -- for a total of 3 to 5 ticks, as you choose. This activity should be time-gated. If you are running this in a room, it's important to ask everyone to stand up. It's a welcome opportunity to stretch legs and give a small break before the last, most intense stage.
Finally, you should pick the topics in order of decreasing vote and let people discuss or explain them in detail for the next five to ten minutes -- typically let people raise their hands to participate. If you feel the topic is clear enough, move on to the next. It is up to you how much time to dedicate to the discussion and, more generally, to the retrospective. Still, I suggest this time structure: 5 minutes introduction, 10 minutes to write cards, 10 minutes to cluster, 5 minutes to vote, and 30 minutes for 3 to 6 topics. Going over an hour's total duration is expensive, as it's a large meeting, and has diminishing returns in terms of crowd attention.
In the last stage, it is essential to have a scribe or someone who takes notes to record the knowledge extracted while the company explores the topic.
We usually report to management with the list of problems identified, their priority, and possible solutions. Once we have the pictures and the notes, it is typically trivial to identify the most critical issues to solve. Having well-defined problems makes proposing effective solutions much more straightforward.
Hi, I'm Marco Cecconi. I am the founder of Intelligent Hack, developer, hacker, blogger, conference lecturer. Bio: ex Stack Overflow core team, ex Toptal EM.Read more
December 02, 2020 by Marco Cecconi
Some lessons learned over the past 8 years of remote work in some of the best remote companies on the planetRead more
November 25, 2020 by Marco Cecconi
Our newest open source initiative, intelligent cache, is available for useRead more
November 19, 2020 by Marco Cecconi
In this post, Salvatore Sanfilippo puts together a list of qualities that I believe make the most difference in programmers’ productivity.Read more
October 27, 2020 by Marco Cecconi
Today I want to introduce our second engineering team: Team EMEARead more
October 23, 2020 by Marco Cecconi
LEGO star-ships aren't made to collect dust on a shelf, but to explore strange new worldsRead more
We can say that Mr. Robot is having a moment. The main character was one of the top choices and thus is perhaps the most/least realistic/annoying/inspiring portrayal of what it’s like to be a computer programmer today.Read more…