I recently read Mike Cohn’s article on whether a “[…]Scrum Team need a Retrospective every Sprint” where he discusses if teams practicing Scrum, and regardless of their maturity – self perceived or real – should hold such a meeting every sprint. I wanted to give my opinion on this subject, but refrained to leave a comment on Mike’s article, as I think there is another take on retros which is worth elaborating separately.
Here is my attempt to do just that.
It’s all about building
Scrum teams spend a lot of time looking at the Product as THE thing they build, and so around it they ceremoniously meet to refine, prioritise, plan, build, test, re-plan and adjust, build and test some more, validate with users, show it to the world, gather feedback in order to re-plan, then rinse and repeat.
And once a Sprint, they stop and ask themselves if they could improve how they build the PRODUCT.
We call it “having a retrospective meeting” and sometimes we question the value of having such a meeting at all.
My take on this is quite simple : your objective as a Scrum team is not only to deliver the best PRODUCT, but in doing so to also build the best TEAM on which the former objective depends (yes, we still uncover better ways of delivering solutions by doing it and helping others do it, it is not just true for the 17 people who offered is the Manifesto in 2001). This tells us that we therefore have 2 things to build : a PRODUCT, and a TEAM. Yet we spend only one dedicated meeting to building the team, the rest being devoted to good old product planning activities. There are so many difficulties in building the best teams (and then to keep it that way when you – hypothetically – get there) that I can’t see a team not benefiting from having one retrospective meeting, ever. You could have one such session every day and still find something to try as well as improvement hypotheses to discuss.
At the end of the day, people make decisions. Having a “retro today” is seen as an option: it has value, it has a cost, it expires. If you chose not to call the option, you probably put too much importance on building the Product, and not enough on building a better team.
When to stop?
But after all, what if the team is good enough? Who cares if it could get better?
Well, if you think that, ask yourself if you are not starting to see the team as a collection of set and standardised behaviours, a bit like well oiled and documented “processes and tools”. It is just that they are instantiated by people. Do you think you are still very much evangelising the “people and interactions” if you have moved passed the people part of the team?
I am not judging, I am just voicing an opinion, and a preference. I like retrospective meetings you see.
It is people in a room discussing people stuff
This is your Vegas, what happens there and then stays there.
When properly done, this is where our humanity comes out, where celebration happens over the simplest improvement increment, where distress and discomfort are best noticed, where the riskiest decisions can be taken, where everyone leads at one point, where human chaos can happen and be left to happen safely, on purpose.
It is the after match changing room of the team: you enter in there tired, sometimes battered and bruised. You come out cleaned up and with an attitude and your next game plan to go with it. No sprint should leave no emotion, so go in the changing room and discuss that, at least…
Yes, at the very least.