Why you need a regular retro

A good team just fixes things with no need for a meeting right? Nyes, sort of.

Fellow reader G asks:

re Your comments on retros: what do you think about Allen Holub's views in his "death of agile" talk? He says a good team just fixes things that are broken, without the need for having a regular meeting. I tend to agree!

This was in response to my Onboarding to a New Team article where I mentioned that regular retrospectives are the best place to introduce process change. And that if you don't have those yet, you should start.

Death of Agile

First, I love how Allen Holub starts his talk and agree 100%.

Agile is the best way we know of to produce software. When I talk about the death of agile, I'm talking about the death of real agility and the replacement of real agility with a fake agility that is suitable for corporations but doesn't work in the real world.

YES! This guy gets it.

When you see me talking about agile, I'm always talking about "small a agile". The one that empowers software engineers to do their thing – focus on user value – and tells management to get out of the damn way.

Agile isn't something that you do

Lots of people think that agile is something that you do. You pick a process off the shelf, start doing your standups and sprints and retros and jira boards and point estimates and voila you're doing agile.

But agile isn't something that you do, agile is something that you are.

Look at the original agile manifesto. It's fantastic.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

When you do these things, the rituals come naturally. They follow out of your team's agility.

Yes over time we've found common patterns that agile teams fall into. When working together, it's nice to quickly sync in the morning. You can't plan more than 2 weeks ahead, if you're not sure how things evolve. You need a scheduled time to talk with stakeholders because they're busy too. ...

But agility comes first. Not the rituals.

As Allen says in his talk: The organization needs to be agile. You can't have an agile team inside an otherwise in-agile company.

Why retros are good

A retro is your team's regularly scheduled time to talk about process. What worked, what didn't, what do we want to change.

It forces the conversation.

That doesn't mean you have to wait until retro to make a change. If something's bugging you, change it. If the way a coworker writes slack messages doesn't work for you, tell them. If you're annoyed by large PRs, start making small ones and lead by example.

You don't need a whole big conversation for every little thing that's wrong. The best time to fix things is now.

The next best time is when you're all "in a room" together holding sacred time reserved for "How can we work together even better?". There is no urgent work to distract you, no last-minute meeting to pull you out, no quick thing to finish.

A retro is like date night with your spouse. You put the phones away, you stash the kids somewhere safe, and you focus on you.

It's okay to end retro with "We're perfect, nothing could be improved". But then I think you're just not complaining enough. There's always something that could be better 😉

Cheers,
~Swizec

PS: I fully support regular retros with your spouse, even yourself. It's easy to miss all the little things that grind your gears when you never stop and think back