Ask HN: Do retros that don't suck even exist?

[pypudding]

If we do retros as they are, they can be a great way to bring meaningful changes to the team - but it usually doesn't.

Usually people start with a bi-weekly retro at the end of the sprint, debriefing everything including the incidents, then slowly it becomes a monthly thing, and surely enough whoever is loudest in those meetings gets to say whatever they want. It ends up being a waste of time and a huge disappointment. Also, no one really takes on the action items coming out of those meetings.

Why is it that a supposedly meaningful 60 min retro can suck so much?

Of course there's got to be some ways to ensure retros actually work. Or, is there?

[kstenerud]

We do retros at the end of a sprint: midday Wednesday.

We use a trello board with the following headings:

- what didn't go well

- what went well

- ideas / discussion points

- show 'n tell

Everyone spends the first 5 minutes putting items for things they want to talk about. Then we go through them in order.

There's also an actions tab where we put anything important that arises during the retro. Those usually get turned into tickets or future meetings by the manager.

Usually there are 4-5 things that we discuss over 45 mins to an hour.

As far as I know everyone's happy with how they work (including me).

[al_borland]

We did something like this for a long time. We found it was helpful to change up the questions occasionally. People fell into a rhythm and didn’t have much to bring to the table. When this happened we’d throw in a retro where instead of “what didn’t go well”, we might ask, “what frustrated you”. Asking these slightly different questions brought some fire back to the retro and allowed us to surface some new issues and get them addressed.

Around the holidays we’d switch it up as well. We did a Festivus themed retro where we had the Feats of Strength, Airing of Grievances, etc. Things like that helped keep it interesting. I miss that scrum master…

[pypudding]

It's definitely great when done well. How about the tougher ones like incident retrospectives(or postmortems)? Is it also a team effort?

[kstenerud]

Yes. The premise is to sort out how human error led to the issue, and what we can do going forward to take human error out of the equation.

That can mean adding a script, modifying a program to take the human action part out, or even just a simple checklist.

Most of the time, a human mistake is a symptom of a bug in your policy & procedure.

[softwaredoug]

I know how you feel.

They’re not effective unless people actually do the follow on actions and create change. Otherwise they are just bitch sessions.

They also can suck because the fundamental problems are not solvable by the group of people in the meeting. They’re endemic to the organization and at best you can work around those issues.

People also are hesitant to discuss some elephants in the room, or have a sense of learned helplessness about certain topics.

[dave4420]

Action items should be assigned to named individuals, and should be reviewed at the start of the next retro. Hold people accountable if they ignored their action items.

[pypudding]

well yes, assignment is fine, but given eng's limited bandwidth and the product's conflicting priorities mean the action items coming out of retros are deprioritized, unless someone can really make a case for them.

[dave4420]

Product people take part in your retros, right?

[pypudding]

We had three kinds of retros - product(half an year), sprint(monthly), incident(per rotation). Yes product folks join the first one, but definitely not the more frequent engineering retros, which is also where the mentioned issues surface faster, also is taking the most time. How's it like for you?

[dave4420]

Speaking generally (as I am currently between roles) the whole team always comes to retro, including the team’s product person. Sometimes external people (e.g. from Customer Success) have been invited as well. And I’ve never seen any problem getting buy in from product.

I honestly think restricting retros to the engineers on a team is too narrow.

Most places I’ve worked this has been fortnightly.

[pypudding]

That's nice. AFAIK SRE retros are harder to get product buy ins. It could really depend on the team and the service they provide...

[Dutchie987]

Action items from the retro should be user stories for the next sprint!

[pypudding]

yes, I wish the PMs also say that. :)

[giantg2]

Our retros usually go well, even if there's nothing effective coming out of them. We have a board with things that went well, things that didn't go well, and proposed solutions. Everyone fills it in before the meeting. This helps prevent duplicates and anyone being talked over.

[PaulHoule]

I worked at a place that did retros seriously on Friday afternoons.

Usually we were knocking ourselves out to complete the sprint and just wanting to go home. Feeling exhausted the last thing you want to do is talk about the sprint more, particularly when there are the common communication pathologies which make people doubt they are really being heard.

[pypudding]

Friday retros actually drained the energy out of me. Retros need to be intentional so forcing people to be intentional at 3pm on Friday is likely doing the opposite. I wish there's an easier way to async do retros.

[justinmarsan]

I've been at a company that really decided to go all in on Agile and actually let teams change things to work more efficiently, and it's one of the best experiences I've had, it really had all the components that make things work.

One issue I've seen since then regarding retros is that they'll fall into two extremes. The rare one is that retros are just fun recess times that nobody gets anything out of besides doing doodles and ice breakers. The other one is that teams will try and be very action oriented and find concrete solutions to concrete problems, but will not have the emotional maturity to address difficult topics, so they're either avoid them or turn into screaming matches.

You need to feel somewhat close to your coworkers to be able to bring difficult topics with the certainty that others will know you do it for the right reasons and that you're all trying to work towards the same goal of making work more effective, pleasant and satisfying. Teams that never work on the closeness of their members cannot address important issues. You need the doodles, the inside jokes, the team spirit to be able to do that.

But you also need to have a mastermind to spot issues and then figure out ways to role play and brainstorm around those in a way that feels like playing, but ends up providing the team with actionnable solutions.

At the company i've worked at, I've had to sometimes do tasks that were really not my duties (data entry, QA work) because it was the most important thing that I could do for the team. I happily did it because I felt like it really was our project, that I'd be bringing value to customers and the company in doing it, and that our product would be better with that work done by me. I'd stay late if there was a problem I could possibly assist my coworkers with, even if I stayed for nothing or could only contribute through naive questions to try and get neurons firing... But we were a close team, despite having different roles and seniority levels, and we were all very happy to do what the project needed.

In my current company the sense of ownership isn't as important, people don't know each other as well (the team also is larger and with more turnover) so it's made of smaller groups of kinda close people.

In a perfect world everyone in all teams would be a trustable high performing dev and there would be no need for any lubricant to make the machine work smoother, but the reality is that the majority of us have pet peeves, quirks and shortcomings, the group can be a good way to mitigate those, as much as processes and methodologies, but having both is what will get you the best results, and I think this is something that is overlooked by many teams.

[pypudding]

Very well said. Retro is a collaborative effort, and the decision makers for the team need to participate in retro meetings to address difficult topics. Yup it's overlooked by many teams since it's hard to quantify what a good process or methodology is - for example, how often do you measure employee satisfaction and engineering quality? How do you know the retro processes positively correlate with any meaningful outcome? The industry is not there yet, so processes like retro will stay in the two extremes.