Recently I was asked by a computer scientist who is new to Scrum what a retrospective is.
He has already experienced it from an outsiders perspective and watched the meeting several times at a company where he is working as a consultant.
And he said: “For me the retrospective looked like a group therapy session”.
I explained the basic concepts of a retrospective to him and responded as good as I could to the questions that popped up.
Like “And what about these games?” and “Can’t you work agile without using retrospectives?”
In this article I want to summarize our talk and explain the ideas and concepts behind agile retrospectives to people alien to agile practices with a focus on the questions mentioned above.
(To be able to stay DRY when someone like him asks me again),
What is a retrospective?
A retrospective is defined as
a ritual held at the end of a project to learn from the experience and to plan changes for the next effort.(Kerth, N. Project Retrospectives: A Handbook for Team Reviews. Dorset House, 2001)
But what does that mean for the Scrum retrospective?
Well it’s exactly that: The key inspect and adapt meeting, held after a sprint (in the Scrum perspective each single sprint is a project on its own).
The idea of the retrospective in Scrum (or any agile approach) is that the team reflects on how to become more effective: Improve the way the team members work together, identifying the actions necessary to do so, which are achievable and executing them.
A retrospective is held with the whole team and includes the following steps:
- Inspect how the sprint went (what went well, what not)
- Find out what can be adapted to improve
- Discuss and commit the actions identified for improvement
(and do the actions in the next sprint)
Using these steps the team has a chance to have short cycles for improvement.
And what about these games?
It is empirically proven that if you include the “fun factor” you can get people to act more open and more ready to take part in the actions.
It is important that everyone in the team gets a chance to be heard!
Imagine a sprint that went horribly bad. Backend and frontend developers completely ignored the interfaces specs they agreed on and in the last days of the sprint, when it was too late to change everything, they recognized nothing will be finished, because what they implemented doesn’t fit together.
Now two possible reactions to that in the retrospective meeting:
The bad Scrum Master will start the retro with yelling: “What the hell did you do this sprint? How could you not communicate with each other? Some little remarks in the daily would have been sufficient…”
How will the team members react to something like that?
Well, some will defend their position, because that’s the natural thing to do when you are “attacked” like that. Some others may feel guilty and be quiet. The Scrum Master triggered the “fight or flee reflex”.
With that mood in the team no real improvement can come out of the retrospective.
All will leave the meeting with bad feelings.
What should the Scrum Master do in such a situation, instead?
First of all no blaming should be done. You have a team of professionals. They know they screwed up.
How about starting a little game to brighten the mood? And then another one or a continuation that, “by chance”, leads to fruitful discussions and real actions (like “maybe we should have the backend guys look at the pull requests from the frontend guys and vice-versa”).
The Scrum Master facilitates the discussions but the team should do the talking
Imagine a sprint that went fine. The team finished work on every item they had in the forecast in time and even pulled some additional items from the backlog. The product owner is very happy.
The retrospective begins. The Scrum Master says: “Hey team, this was a great job. Everything done and even more… I’m impressed! Let’s skip the retrospective event and go for ice cream/beer to celebrate.”
Is that OK?
Well, of course the celebration is good and should definitely be done in such a case. But if you skip the retrospective you rip the team of a chance to improve.
Perhaps the team was just lucky? Or perhaps some members know what was different this time. In that case these people should be able to speak up, so that everyone knows and the team can continue being great!
Or maybe even in that perfect sprint, something was not good and needs to be addressed to have it “out of the way” in the upcoming sprint…
So also in this case a fun little game (with actions as an outcome) can be done, before going to that ice cream parlor or bar with the team.
Remember: The retrospective is a meeting for the team. And is a safe place for everyone in the team to have real conversations about what is going well and what can be improved.
Can you be agile without doing retrospectives?
In my opinion: No!
First of all: The retrospective is one of the key Scrum ceremonies. If you don’t do it you’re not doing Scrum!
However not doing Scrum does not equal not being agile.
Scrum and agile is not the same. Scrum is one framework for applying agile approaches, there are plenty of others.
But I can tell you something: They all are doing retrospectives in form or another.
Is there any improvement method that doesn’t involve periodic reflection and adjustment?
Not doing that basically assumes that the team and the plan is perfect.
And we all know that perfect plans don’t exist (and teams neither).
Everybody has a plan until they get punched in the mouth.Mike Tyson
So, is the retrospective a group therapy session?
A therapy is defined as a “treatment intended to relieve or heal a disorder” (in the Cambridge English Dictionary).
This is one of the ideas behind retrospectives: Finding and “treating” dysfunctions in a team.
Some basic concepts of group therapy sessions are included, as the retrospective:
- Helps team members to improve
- Facilitates giving and receiving support
- Offers a safe space to speak for everyone
- Helps to relate to others
So, I can’t deny that a retrospective in fact is kind of a group therapy session.
Knowing the ideas and concepts behind it, I can’t see anything wrong with it.