Retro is a meeting where I feel awkward

Retrospective is a meeting where awkwardness and powerlessness are exposed.

• A manager wants people to get together and somehow solve their problems.
• People do not remember what they were unhappy about during the week.
• The team does not have the authority to solve the problems they want to solve (e.g., cancel the retrospectives).

And even if someone does speak up, and it is supported, and there is a solution, no one will find time to implement it.

Of course I also did retro.

I wanted to give my people a space to let off steam. I wanted to know the state of our team spirit. And, of course, the main reason I did it was to make sure I was doing a good job as a team leader.

I also wanted to encourage teamwork. To find solutions together.

Sometimes it was really fun.

Once, a team member was upset because he spent a day trying to reproduce a bug reported by a stakeholder without providing proper steps to reproduce it. In the end, it turned out there was no bug at all.

My teammate was angry and asked to talk to the stakeholder for them to be more accountable. I asked him to play a dialog with me as if he were the stakeholder, just to train me a bit. I should ask him to be more precise and he should resist and find arguments not to do it.

I remember the aha moment when he said, "How can you imagine that I will control everything the way you want? I have a lot of work to do. I reported a problem because I thought it was better than ignoring it". He finally understood that stakeholders are just people.

Typically, 60-70% of the people in a meeting were active. We talked a lot, discussed solutions, argued with one another. Those who weren't interested in a particular conversation would usually sketch something on the edge of our Retro Miro board.

We would write down action items after we agreed on how to solve a problem and who would do it. We tried to do them, but usually no one had the time.

Our meetings gave people a chance to blow off steam, but there were no significant results. I don't think we produced anything good there.

The best of what we did was this drawing.

Retro feels artificial 80% of the time. The other 20% may be better, but only because the host is a good entertainer.

Where in real life outside of a corporate environment have you seen someone try to get problems out of a person like this? I bet the person will either ask you to leave them alone or make up some convincing answer to get you to leave them alone.

Do not compare this to therapy. If your therapist acts like a host in a retrospective, you just probably knocked on the wrong door.

What is natural for people is to act in small groups of those who care about the problem at the time the problem has just arisen.

But in retro

• people act at the wrong time (every other Friday) when everything has calmed down
• people create a plan that is too big
• people create action items that often only the team leader is capable to do
• and (probably) they try to push these action items into one a sprint

Retrospective is like a fake Swiss Army knife. There are many good tools inside, but they are all either dull or broken.

Retrospective has three great practices. Feedback, Brainstorming, and Action Items.

But they are all used at the wrong time, with the wrong people, or not used at all.

Feedback to the system is undoubtedly a useful thing.

But if you are asked to remember the team's problems during the last iteration, you are likely to forget everything. You can solve this by journaling throughout the week. But doing it just to avoid embarrassment in a meeting seems like overkill.

If you don't forget a problem even without journaling, that means you didn't get the problem out of your head the whole sprint before you had a place to talk about it. That does not sound good either.

Either way, if no one on the team supports you with your problem, if everyone treats it like something unimportant, the likelihood of you saying something at the next retrospective is greatly reduced.

The last thing I want in a discussion about a problem that is important to me is to have people around who don't feel the problem. They may be helpful, of course, but more likely they will give advice that is simply irrelevant.

It's great that people don't just finish the discussion with nothing. Having action items is better than not having them.

But it would be perfect if you had time to do all those plans. But when you work in sprints, usually all your time is already planned.

Of course, you can schedule these action items as regular tasks. But doing so turns a good intention into a commitment. Now you can't just let the task to be failed. Now you have to finish something to show results. No one likes that kind of pressure. It is a recipe for making people afraid to talk about problems.

Even if you can somehow avoid this feeling, I still think that a planned action item will fail either

• If it's implemented by someone other than those who felt the problem on their own skin.
• If it's not planned to start in the iteration immediately after the retro.
• If there is an estimate and expectation that the task will be completed in the iteration.

Some tasks can't be solved in a single sprint. The best improvements I made to my team's processes sometimes took months. I did them from time to time when I felt like it or had a new idea.

Despite all the criticism, I have to admit that retrospectives can be helpful if you can think of nothing better.

If you're doing retrospectives and you're sure they're working, I think your team is mature enough to solve its problems even without them.

If your team can act the moment a problem arises, any formal schedule is just a distraction.

A retrospective is better than nothing. But we can extract all the good things from retrospectives and use them in a more natural way.

1. Define the limits of influence

People should know what they can't change.

For example, this could be the technology stack.

2. Start working in pairs

To start, try it yourself. Pair up with a teammate to complete a task together.

Start by sharing your own problems as you work with that person. Over time, the person will begin to share in response. These problems are more relevant and timely than the ones you hear in retrospectives.

The point is to make a connection, to build trust. Doing this in person is more realistic than expecting it to somehow show up on its own when you gather an entire team in a zoom call.

3. Begin Supporting Initiatives

Begin by supporting a person in their pain. Discuss a solution, find a way to solve the problem through the person's hands.

Cover the person as they take small steps. This is easy to do when working in pairs.

4. Repeat in a chain

Ask the teammate you helped to support someone in a similar way when they work in another pair.

Retro is not an evil in itself. It is just a bunch of good practices applied at an inappropriate time with the wrong people.

Start discussing problems in a small group as they arise, and cover your teammate as he or she implements the solution.