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.