More on Retrospectives

On Tuesday last week, I attended Rachel Davies’ course on Retrospectives. My overall impression of the course was good, and I came back with lots of new ideas to try. I’d definitely recommend it.

Along with the practical learnings, the key takeaway for me was that it’s not as easy as you think to facilitate a retrospective. You have to get the true picture from different perspectives and guide a conversation towards a meaningful end – while staying neutral (never easy) This is why activities are important, to uncover the things that won’t ever get mentioned in conversation.

My highlights:

  • Lots of relevant information and references for further reading.
  • Seeing the timeline activity in action – using coloured post-its for good / bad / neutral makes it work a lot better than all one colour. Rachel also takes it one step further and uses funky shaped neon post-its for the team to highlight areas of fun and stress. Although this seemed like overkill at first, it does illustrate trends.
  • Emotional timeline – it was great to actually see this work, again it’s something I hadn’t used and wasn’t sure on, but it really did show up the patterns well, even in the example one we used.
  • Watching other people, as always, makes me see things that I’m doing that don’t work so well – for example, how important it is to write down what people are saying and not what I think they are.

Not so great:

  • Powerpoint overkill, especially at the beginning – I found it a bit difficult to stay tuned for the first part of the session, and would probably have preferred handouts (paper or electronic).
  • Difficult to really demonstrate retrospective activities with a group of people who’ve only just met – more simulated situations or role-plays might have been better.

Before I went, one day seemed like enough to become an expert on retrospectives. As always, the more you know … the more you realise there is to know!

Agile Retrospectives – trying the techniques

This was previously posted on my old blog, Spike the Poodle. 

After reading my new (autographed!) copy of Esther Derby and Diana Larson’s book on Agile Retrospectives, this week I tried some of the ideas out in our team retrospective. I really recommend reading the book and trying the techniques, I’d be interested to hear about other people’s experiences with them. Ade Miller also highlighted some ideas this week, including an article from Industrial Logic.

Firstly, we had a clear goal for the retrospective rather than just continuous process improvement, which was starting to get stale. I started the retrospective by asking the team to sum up the Sprint in one word, which actually gave me a great insight (especially since I’d been away for most of the Sprint!) The team had come really close to completing all of the work they’d committed to, closer than in any previous sprints, and everybody felt that they’d nearly made it but not quite. The team seemed to like the exercise, and they’ve suggested using song titles or animals next time. I’m particularly intrigued by the song titles suggestion :)

We used a timeline to gather data. I drew the team’s burndown chart on the white board and asked them to record events that had happened on post-it notes and stick them against the relevant part of the chart. What worked well was asking them to think back through the Sprint about what had happened, but since the burndown chart was fairly flat it didn’t really generate a great discussion in itself. I think this activity would work particularly well with a spiky burndown graph.

I asked the team to stick red and green dots on the positive and negative events. The good thing about this activity is that you actually get some surprising results – some of the things that I thought were really bad, and might have devoted more time to discussing, didn’t actually have any sticky dots on. It really did make it clear what the significant events were, however there were a lot!

We spent quite a bit of time talking about what was causing the main issues, and eventually we agreed on two areas we wanted to address: how we manage bugs during the Sprint, including bugs that relate to the current stories as well as new bugs that don’t, and how we can do better at getting things done. We spent too long discussing the issues, but this was partly because we weren’t really sure before the retrospective what our main issues were – next time, I think we will have a clearer goal which will make the meeting more focussed. I also need to get better at timeboxing! We identified a list of solutions for managing bugs better, and then used voting to decide which ones we should use.

I asked the team to choose up to two solutions to try for the next Sprint, so that we weren’t making too many changes all at once. Interestingly, most people didn’t want to be limited to only trying two things and wanted to do them all at once. We compromised and identified three things to try over the next two weeks.

Next time, I plan to focus on what we can do to get better at getting things completed within the Sprint. This has been a key issue for us, and I’ve also spoken to people on other Scrum teams who have the same problem, so I do plan on posting updates on what we come up with! In the meantime I will also be attending Rachel Davies’ workshop on retrospectives, so hopefully our next one will go even more smoothly.

Agile 2006 – my highlights

Over the last couple of days, I’ve spent some time collecting my ideas and thoughts following Agile 2006. Spending the time to reflect has really helped to tie up the loose ends that were hanging around in my head, at least the ones from last week. I’m glad I took the good advice to stay away from email, well as much as possible, because for the first time in a while I’ve really got into “the zone” and it’s been incredibly productive. So here’s a brief summary of my highlights, and for a summary of all of the sessions I went to, check out the Agile 2006 page.

I went to so many worthwhile sessions, it’s hard to pick my favourite, but three in particular really stand out:

Ron Jeffries and Chet Henderson’s Planning Game – this session is great for two reasons: firstly, it’s fun and entertaining, and secondly, the lessons just reveal themselves through the game: to the most value from an agile project , you need to have clear estimates for the stories, you need to know your velocity, and the business needs to assign a clear value to the stories. Armed with this information, you can get almost all of the project value in the early iterations. Combine this with small, frequent releases, and then you start to see the real value of being agile and iterative. Ron and Chet have performed this session a lot, and it shows. It really is a performance, the banter and role playing were fantastic, especially in the Management role. If you haven’t done this, and you get a chance to, do it.

Programmers are from Mars, Customers are from Venus – Angela Martin and Robert Biddle – this was a highlight for me because it had some really practical, relevant guidance on splitting up the role of the customer into nine separate roles with specific different responsibilities – including acceptance tester, UI designer, negotiator, diplomat, and technical writer. They also suggested techniques such as having programmers play customer apprentice to improve interaction, and having a customer counselor for those times when you just need to vent. The powerpoint is really simple and clear, and it was good to attend a session that really focussed on and sympathised with the customer, rather than the team. I don’t play the role of customer, but it did give me a much deeper understanding of why it isn’t always as easy as you think.

The Test-Driven Development Pairing Game – Peter Provost, Mitch Lacey, Brad Wilson – this was the one session I refused to miss, and I’m glad I went, even though I had to leave Diana Larson and Esther Derby’s session on retrospectives, which I was also really enjoying. Brad and Peter have a great energy and humour, and they’ve created their own way to productively get the better of each other. Anything that makes writing unit tests fun for developers is pretty impressive, and their solution to write a single test and then pass the keyboard so that the other person makes it pass seems to go some way towards doing that. They somehow demonstrated something that combines two fairly complex practices in a really simple, easy to understand way, and entertained a group of people while simultaneously writing clean code. That’s pretty impressive. I’m just hoping that when I demonstrate it back home, it will seem as easy.

The biggest highlight of all was just meeting and talking to so many people who were doing agile – people who were still experimenting, who were learning from the same mistakes I am, and people who’d done it over and over and could share their experiences, or had the patience to listen to mine and offer advice. Over the next few weeks I hope I can share some more of my own experiences as I try and put some of these things into action!