Scrum Retrospective Meeting is Necessary and Sufficient
Scrum, and other agile methodologies, is a hodgepodge of roles, artifacts, meetings, rituals and concepts. In this post, I’ll try to convince you that there’s one concept that stands tall among the rest - the retrospective meeting. I’ll claim that it’s not only useful, it’s both necessary (you need it to do well) and sufficient (you can do well with the retrospective alone).
There’s an endless field of possible development methodologies. Even with Scrum “by the book”, there are endless parameters to tweak: iteration length, planning method (points? t-shirt sizes?), commitment models (do we go by a calculated focus factor or use our gut feelings?), team structures, etc. And if the team is “brave” there are a lot more. Maybe we don’t feel like the daily standup is beneficial, and we want a 2-per-week team meeting where we get to sit like adults?
People, and therefore teams, have their own quirks, preferences, strengths and weaknesses. One team might find that mandatory story templates with a “definition of done” section helps a great deal, because team members tend to take forever dotting the i’s and crossing the t’s. Another team might be well practiced in sharing small tasks and will do that naturally. For them, having a mandatory template feels like annoying bureaucracy; it will only cause friction, putting them off from the whole process. One team’s heaven will be another team’s hell.
That means there’s absolutely zero chance that the first set of rules a team decides on for their first iteration is the global maximum for that specific team. Iteration on the process itself is the difference between success and failure.
Iteration on the process is what the retrospective meeting is for. It is the way we move on the methodology field to get better and better results: reflecting on the past iteration, figuring out what is working and what is not. That only happens in the retrospective meeting.
If you don’t do the retrospective meeting (or don’t take it seriously), then you’re stuck with whatever system you started out with, and that system is definitely not the best for your team. That’s why the retrospective is necessary.
The rest of the Scrum meetings and artifacts (sans the retrospective) are simply a good starting point in the vast methodology field. They are the result of countless teams trying out new approaches, experimenting in how they develop software and sharing what they learned with the world. Scrum is software lore. It jump-starts your team to a reasonable position so your team can make small, incremental changes to get to an optimal place. It saves you the trouble of making monumental decisions and wild experimentation on your own.
There’s a danger in Scrum, though. It is lore, a “body of traditions and knowledge on a subject held by a particular group, typically passed from person to person by word of mouth”. That also sounds awfully like religion. The danger is that teams don’t take the retrospective meeting with the appropriate freedom it gives them. They circle themselves in the “Scrum” definition and tweak it so lightly that they effectively stay in place. They feel the need to the Scrum “by the book”, as if some Scrum god will be angry if they do their daily meeting sitting down.
Consider Gall’s Law:
All complex systems that work evolved from simpler systems that worked.
[And conversely…] A complex system designed from scratch never works and cannot be patched up to make it work.
This is true for software systems that we, as software engineers, build. But it’s also true for the system we use to build that software. And Scrum is a very complex system.
Now, you could say that Scrum is indeed a complex system, but that it was evolved from simpler systems that worked. It just that it was evolved by someone external to your team. The danger is still there, though. Sometimes you have to learn some lessons yourself.
You can try to have daily sync meetings when everyone sits down. It might work. You might also experience endless meetings where everyone is juuuuuuust comfortable enough to let that one guy talk forever while they ignore what he says. When you do switch to standing meetings, you’ll have a better sense of why you’re doing it.
Some teams will have an easy time learning and adopting using other people’s experiences. They can take the initial Scrum lore, play with it and mold it to their needs. Other teams will resist; they’ll find Scrum to be an endless well of bureaucratic busy work. The friction will be so high that it’ll just be a bad experience for everybody.
Teams which have a strong (perhaps justified) resistance to Scrum will eventually, in my experience, throw the baby out with the bathwater. They’ll resist the retrospective alongside all the other crap that’s making them miserable. They’ll usually also grasp to the idea of having a Scrum Master - one person who does All That Annoying Scrum Stuff™ while the rest just do the actual work.
But what’s the alternative?
Forget about Scrum - maybe it isn’t a good fit for your team. Set up a recurring retrospective meeting. You don’t need to do any of the other Scrum stuff; you don’t even have to call it “retrospective”, but do make sure you talk about meta stuff - your methodology, not your actual projects. Discuss your development processes. Are they working for your team? If “yes” - great! Otherwise, maybe Scrum is the solution, maybe not. Talk among yourself. Reach a consensus. Agree on the next steps. Start small. Course correct when needed (make sure this meeting is recurring; don’t skip it!). Have everyone be involved. Work together, as a team.
This is why the retrospective is sufficient. As long as you constantly move on the field of possible methodologies, as long as you actively tweak and change your process for the better, as long as you keep talking and improving, you have a chance to get to a place where things just work. But the important thing here is moving (doing the retrospective), not your starting point.
Discuss this post at the comment section below.Follow me on Twitter and Facebook
Thanks to Shachar Nudler, Ram Rachum, Yosef Twaik, Hannan Aharonov, Yonatan Nakar, Meir Cohen, Haim Daniel, Or Maman, Shachar Erez and Daniel Yosef for reading drafts of this.