A colleague of mine has been commenting on the “cost” of some of the meetings we have each sprint. To be fair, a whole team sat in a room for an hour is expensive so it got me thinking. Lean, highly influential on Agile, has the concept of cutting away everything that isn’t need, so I wondered if our meetings were value for money and if not, what could be cut away.
I obviously didn’t want to dictate my thoughts to the team, so I tried to come to up with a retrospective technique to get the teams thoughts. As usual, it followed the 5 steps:
Question All Meetings Retrospective
Set the Stage
I set the stage as the team investigating “do we get value for money from our regular events”? I introduced the GIFTS acronym with respect to the daily stand-up. If you’re not familiar with this, I first read about it from Martin Fowler in his post It’s Not Just Standing Up. In short, it stands for:
- Good start – to the day
- Improvement – chance for the team to highlight possible improvements
- Focus – for the team for the day ahead
- Team – as in building
- Status – so everyone knows what everyone else is doing
Before getting into it, to warm us up, I asked everyone to predict which meeting was going to be the worst and made a note of the results. This was mainly to get everyone to speak at least once.
As I’m in a big team, I split them into 3s and asked them to pick two of our regular meetings and come up with a similar acronym of what we should be getting from them and an opinion of whether we are.
Each team presented their acronym and opinion of whether we get them. The whole team were then encouraged to discuss whether that was accurate.
Decide What To Do
If there are any perceived problems with the meetings, i.e. we’re not getting the values identified in the previous stages, talk about them and decide what we can do to change it.
Close the retrospective
I closed the retrospective by thanking everyone for their time and asking them all to provide me with some feedback on how they would rate the retrospective.
The retrospective went “Okay” as it didn’t flow particularly well or feel like there was enough material for a whole retrospective. Saying that, we did get some useful ideas and have drastically changed some meetings, so it couldn’t have been totally bad.
To be honest though, that was probably due to my team being very good and effectively rescuing me from a bad retrospective, rather than my skills, but I’m happy!
Overall, I wouldn’t recommend this technique as is to a new Scrum Master or a new team, but I think there’s a good retrospective technique in here somewhere waiting to come out.
I don’t think you should consider drastically changing or completely dropping one of the regular scrum events. Also, please be very careful to monitor the reaction and changes in the team if you make any.
Basically, not all ideas are good ones, but have the courage to try something “out there” if the team reach a consensus on trying it.
What went well
- We got some good ideas on how to tweak a couple of the regular events and these changes have improved the teams opinion of them.
What could I have done better?
- Asking people to make up acronyms in a short space of time didn’t work out particularly well. Maybe just the core values would be better.
- Asking the teams to pick two meetings was a chance for them to all pick the same things. Assigning them felt wrong, so I need to think of a better way.
What should I not do again?
- Expect all of my ideas to be amazing first time.
- Asking the team to warm up with a prediction for the worst meeting was a bit naff