We had a meeting last night at the Lamb and Flag to discuss Agile Retrospectives by Esther Derby and Diana Larsen. I was joined by Miquel, Steven, Mick, David and newcomer Graham.
Half of us had not read the book, so I explained the structure of it: The first three chapters explain what retrospectives are, how to structure and run them. The next five chapters are essentially a set of patterns. Each chapter contains a series of activities that can be carried out at each of the stages of the retrospective. The book ends with a chapter on larger scale release and project retrospectives and a closing one on supporting the changes that come out of the process.
Miquel commented that the book seems to expect you to be able to get through quite a few activities in quite a short time. Graham agreed and pointed out that many of the activities seemed too long to fit into a one or two hour iteration retrospective. I thought that this was because the emphasis is on the longer activities in the middle of the session, while the beginning and end are quite quick.
Overall Miquel thought it was a well-structured book. Graham liked the way that it gave examples so that you didn’t spend too long just thinking about theory and principles. He also thought that most of the text could apply to situations outside of agile software development. Everyone seemed to agree on this. From my perspective, the main thing to come out of the book was the five stages that a retrospective is comprised of: Setting the Stage, Gathering Data, Generating Insights, Deciding what to do and finally Closing the Retrospective. When I saw Diana Larsen talking about this at JAOO she mentioned something which isn’t in the book. That is that you need to ensure that people do the “Gather Data” stage. Technical people tend to jump to the “Generate Insights” stage and business people tend to jump to “Decide what to do”.
I thought that something that was missing was some sort of diagram to show the connection between activities. Appendix C shows which ones you can use at which stage, but it doesn’t show which ones should follow other ones. It would be helpful to had something as simple as a list, giving a one line description and which other activities it is associated with.
Mick said that when he first heard about Retrospectives he was confused about how you could solve all of your problems in half an hour. It was only later that he realised that you don’t solve all of your problems, you work out what they are and how you can start moving in the right direction. The next retrospective allows you to see how you are doing and possibly change course.
Miquel pointed out that it is suggested that the retrospective facilitator role should rotate through a development group. Having read the book though, he thought that it seemed to be quite a skilled job, so maybe this would be difficult.
Graham asked about the minimum size of team where these techniques would be useful. I suggested that even on a team of only two people it would be useful having time out from the day-to-day work to think about things. David said that going to the pub with the team could also serve the same purpose. Graham was uncertain if this would just be forum for moaning in the absence of the formal process. I agreed and said that it is fine saying at the pub “We need more tests”, but it is much better to say “We will achieve 90% test coverage in these packages within the next month”. David suggested that Big Visible Charts showing progress would be a good way to keep these targets in people’s minds.
We then drifted off into more general topics. I liked David’s story about his boss showing up around noon declaring “We need to make sure people come in earlier!”.
Interesting note: if you look carefully at the cover of the book you’ll see that the compass has the letters N,S,W and O on it. So I think it is a German compass. Strange!
The Oxtremists 