“What happens in Vegas, stays in Vegas” so the saying goes.
Retrospectives are a well-known, but not necessarily well understood or well executed ritual from the Scrum framework. In fact, retrospectives have been around in one form or another long before Scrum became mainstream.
This is what the Scrum Guide says about retrospectives:
“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
Over time the retrospective ritual has grown to encompass not just the previous sprint’s activities, but the well-being of the team. Esther Derby, co-author of Agile Retrospectives – Making Good Teams Great, says:
“..retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so.”
At Bright Interactive we have several teams of different sizes and with different purposes and goals. For each of them, we have regular retrospectives. If they are facilitated well, and certain constraints are put in place, they turn into valuable gatherings where real change can happen.
Retrospectives deserve and have many books written about them, so I’m not going to delve into the subject any further, but there is one thing I want to share with you: transparency.
Much is made of being transparent within agile practices. In Scrum, for example, the Scrum Board is an information radiator, allowing everyone and their dog to see the progress made by a development team; the Definition of Done is supposed to be a publicly-visible contract, open to scrutiny; and likewise, the retrospective is a time in which all team members have an opportunity to talk openly (bound by the team’s Working Agreement). However, recently at Bright Interactive we’ve been trying something different with our retrospectives: secrecy.
OK, so “secrecy” is a bit strong here. Up until recently all of our retrospectives have been published internally for the whole company to read. This in itself is not a bad thing, as openness and honesty are good things for teams to practice. But we tried an experiment with one of our teams: we said that everything said in a retrospective would stay in the retrospective. Once a retro’ exercise had finished (for example, variations on Speedboat, Starfish, Mad Sad Glad and the like) and an action or two had been agreed upon – this is important – the board would be wiped clean and all stickies consigned to the bin. We did this with agreement from the team first, naturally.
As soon as we tried this, the team was more open and explicit (in a good way) about a lot of the things they wrote up on their stickies. At first we were concerned about the items that gone thrown away, but once they had been discussed and an action settled upon (which we do for every retrospective) this didn’t seem to irk the team. Normally, many of the trashed items related to specific events from the previous week, and those items which transcended several weeks or iterations would come up again in subsequent retrospectives anyway.
That said, this is an experiment. If the team decides that documenting retrospectives bring more pros than cons, then we’ll resort to that. In the meantime, we’ll keep it in the retrospective.