The 4Ls Retrospective and why you would use it
For our first retrospective I wanted something simple to explain, but also simple to take part in. The 4Ls technique leapt out at me.
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:
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:
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.
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.
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.
We’re close to a big release and things have been going well – think 200%+ increase in velocity from when we started the release (and we were good already ) – but our last couple of retrospectives felt a little flat, possibly because the big wins have already been made. I wanted a technique to really get the team involved.
“Asking Questions” is aimed at new scrum masters who have never facilitated a retrospective before, so I decided to tweak the format a little.
Rather than asking the question, I printed them out, cut them up and put them all in a pile in the middle of the table. Importantly, the questions are all folded up so you can’t tell what piece of paper held what question.
Rather than the Scrum Master asking the question, taking turns, I asked each team member to pick a question from the pile, read it out to the team and then give an answer. The rest of the team were then encouraged to discuss the response.
I’m pleased to say this lead to a lot more group involvement than the last couple of retrospectives and we managed to find a couple of tweaks as well as a bit of forward planning for the next release.
The book says this is a great technique to use if you’ve never facilitated a retrospective before. The tweaks I made may or may not help this, but it certainly got the team involved and resulted in some great actions.
So another fantastic technique that I would recommend to a newbie or expert Scrum Master, especially if they want fantastic team engagement.
I’d be really interested to hear anyone trying this technique in the comments below or catch me on twitter if you prefer.