Agile Retrospectives Keep Failing. Here’s Why
Are your sprint retrospectives a nightmare of silence? Mine sure are, as nobody gives seems to have any enthusiasm for doing a good job and pushing features out to customers.
I think the constant refrain at work is why bother!
In this article, I’d like to explore what is going wrong, and how that might be solved in both my and your organizations.
Trustworthiness
I’ve noticed that many scrum masters have learned the term psychological safety but have failed to learn how to put any guardrails into their processes. Our “agile practitioners” say we have to build psychological safety in an organization where developers never seem to use their webcams.
Does the term webcams even still exist?
Here are some methods that can be used to promote team spirit within retrospectives and perhaps tease out learning from what happened. Here are some ways of achieving that loft goal:
Modeling
If the “bosses” in a video call don’t bother to turn their cameras on why would they rank and file? If you want people to show vulnerability and capacity to learn you can model that from the top.
Constructive feedback
A difficult one, this. Criticism can come in negative poor resolution pessimistic ideas like The Secret Developer might say:
This blog post is poorly written and full of mistakes. It’s not funny and perhaps the writer doesn’t understand sarcasm so might like to stop wasting my time.
Yet constructive criticism (from the heart) can help people to get better and to improve. There are courses to help people give feedback (particularly at management level) but a constructive feedback culture means that everyone should take a look at how they are giving criticism and turn it into constructive feedback.
Follow through
I hope my audience recognizes that creating a JIRA ticket and leaving it to The Infinite Power of Tomorrow does not suffice. Taking action and having difficult conversations can resolve problems before they are even considered real issues.
Identify an issue and then work to solve it. How difficult is it?
It is nearly impossible at my workplace.
Admitting mistakes
There are some developers who never say “I’m wrong”.
Look I would say that, but I’ve never been wrong.
A healthy team admits things could be better and works towards the solutions.
We implemented an API that didn’t work as expected at our place. The developer said he worked on the output “as agreed”. The FE team (the clients of the API) were not in the meeting when the format of the dates from the BE was agreed.
Boring Retrospectives
Themes
At our place, they seem to think that setting up retrospectives with a Star Wars theme (or similar) makes it fun. Unfortunately, they have also failed to work out how to have music playing during the session.
If you’re going to have a theme (and it isn’t necessarily a poor idea) you could have it for an entire sprint. Implement a fun-themed quiz in a fun meetup. Get people to quote their favorite Wookie in ceremonies.
Java Dave might find it a bore, but even he might go along with it after some time.
Or perhaps just drop the theme idea.
Retrospectives that don’t meet the needs of the participants
The way retrospectives are run typically does not meet the needs of distributed (or *shudder at the term* hybrid) teams.
Oftentimes retros are not as long as they need to be. Like any agile ceremonies, these can be cut short, or (gasp) the format can be combined with more asynchronous working methods.
If you want people to engage in agile ceremonies, listen.
Oh yes. This ☝️☝️
Conclusion
Retros may well work for you and in your working context. They’re not working in mine. The post above provides some suggestions on how to have valuable retros.
My real advice? It’s right at the end of the article. Listen
In tech that just never seems to happen.