While I think agile engineering practices are step 0 in building an efficient agile team, there are few of the ?soft? practices which seem like low hanging fruit for a team that wants to grow more efficient over time. In my opinion, the most bang for the buck comes from Retrospectives.
Disclaimer: I am far from an expert on retrospectives (for that, see Diana Larsen). What I know about retrospectives has been gleaned from listening to other people and trying a few things. I am writing this more to start a conversation than to preach my interpretation of what makes a good retrospective.
At Russell, for the first couple of retrospectives we did, I think it felt too ?touchy feely? for most of the group and they had trouble getting started saying what they needed to. Once they got going, it turned a little dark and we started focusing on negatives, especially unsolvable ones. By the end, we were wondering what was supposed to happen next. This wasn?t how the people at the conference I went to did it. What was going wrong?
For one thing, our teams are too small (3-5 people) to include much of the ceremony around retrospectives. Eventually, we ended up doing a simpler kind of retrospective:
- Get a room.
- We make a list, two columns, good and bad things about the iteration.
- Quickly, roughly size the things.
- Pick 3
- Figure out how we?re going to address them
We usually only end up with technical people in the retrospective. For whatever reason, what?s expected of product owners generally remains static across iterations, so there isn?t too much for them to improve on. Depends on the product owner.
Making the list takes up the biggest part of the meeting, from 10-30 minutes for us. Towards the end, it?s usually one person, reaching way deep into things that aren?t going to get addressed anyway. It?s good to cut this off, but my feeling is you need to let it go on for a little bit, so everyone feels they had a chance to say what they needed to.
As I mentioned earlier, sometimes this turns into an?umm??complaint?-fest. It?s important to cut this off. We?re listing things, not trying to solve anything or blame anyone. We just want to build a mini-backlog of potential things to address, not address them. Addressing them before we know they are the next most important things is waste.
The sizing part is quick and easy. Just Small/Medium/Large, 1/2/3, A/B/C, whatever. The main thing is to call out those big things that you probably won?t be able to address and to get an idea of your velocity in getting these things done.
Picking 3 is the magic part. The three isn?t magical, just a good starting number. Once you?ve gotten and idea of how many ?retro points? your team can handle in an iteration, you can use that instead, if you want. Here?s where we have to be honest about what we can get done, in addition to all our other work, as part of the next iteration. If we pick a hard thing, are we really going to have time to address two more little things? Are these little things over here really valuable enough to spend time on? The selection criteria is a function of value and cost, so there is no sense going into problem solving mode until you have those two pieces of information and can select the right amount of stuff to work on.
Once you?ve picked out the things you want to tackle, figuring out how to do it is usually pretty easy. Just don?t let anyone sneak their favorite unaddressed item into the problem solving phase. Focus on just the things you know you?re going to get done.
Finally, everyone agrees that we?re going to address the things we picked. At the end of the iteration, we?ll measure the teams performance against the goals they picked, so it?s important we all agree.
If this sounds a lot like the way we do features and stories in an agile process, yeah, that?s kind of how I think about this. It?s how we address things in our process that we can?t/don?t want to, for whatever reason, introduce into the main backlog for the project. Process improvement is overhead, and the things we come up with in our retrospectives are our backlog for overhead. These things don?t have first order business value, but second, or third order.
Some Lean teams have sworn off retrospectives, perceiving them as waste. Like anything else, retrospectives aren?t going to add value for every team. For my team, retrospectives are quick, easy, and valuable when we stick to the important parts.
As is the case with most practices, there are good and bad ways, short and long ways, creative and dull ways to do retrospectives. I DO NOT believe that getting rid of Retros all together is a good solution, but they do need to be relevant for the team or they will become just another practice the team is forced into, and the point is missed entirely (worse than not doing them at all).
Agile spends very little time looking back and learning from mistakes and best practices, this is the purpose of the Retro, and in my opinion is critical if you’re doing Agile ‘by the book’. Keeping the Retro agile (little a) and to the point is the key. As a ScrumMaster I have to be as creative as possible and keep the format changing on a regular basis. This helps the team think in different ways about what they’ve accomplished, what they need to continue doing, and what they need to improve on.
I do enjoy the Derby/Larsen book and use it as a reference, though I don’t always use all the steps for smaller teams. The basic concepts of Setting the Stage, Gathering data, Generating Insights, Making Decisions, and Closing are still doable and help ensure that the team comes out of the other end of the meeting with actionable items. I think the ideas mentioned by cbilson are good for keeping things simple, but they might not always start the team out with the right mindset (i.e. might make the team feel like it’s not a big deal).
As a reformed traditionalist, there are actually a lot of ideas or activities that transfer from that world that can be performed even for small teams, but it takes making time (I try to spend as much time preparing as the Retro will take) and finding both creative ways to elicit quality discussion as well as keeping measurements consistent enough between iterations to build up the knowledge base about what works and what doesn’t work for the team, what helps them and what hinders them. Sometimes you have to fight the ‘corny’ factor a little but, but that goes back to finding out what the team likes and reframing the questions and activities to be more applicable.
Regarding business value, finding a way to keep the Retro relevant and useful (i.e. so that business value can be delivered) is really key to successful Retrospectives.
BITCH SESSION!!!!! – I kid, I kid…
At Kaizen conf Mary Poppendick said it best:
1) The team picks the ONE thing they can CHANGE NOW, its really good if this happens to be the thing that is causing the most pain
2) The team is ALLOWED the TIME to fix it <- (this part is important!)
…or something to that effect.
Basically dont over complicate it. No lists of things that are never going to get done, no bitching or warm and fuzzy ‘what went well’. Just pick the thing that’s the most FU and give the team time to fix it.
(For the record, we still do the ‘What went well’, “What we could do better’ and ‘Action items for next sprint’ Probably by my tone you can tell what I think about that 🙂 )
Great post Chris!