As regular readers will know I have been using the scrum-xp combo to manage a project over the last year. The project is continuing this year and is for the most part doing better than some of it's predecessors.
This week we ran a little activity called the 2009 retrospective. I headed up the meeting with a quarterly view of what we want to deliver in 2010 and then moved on to a discussion about how much we have learned from our year together in 2009.
I will share the particular technique I used below. It was interesting for a couple of reasons. But first, the background.
Throughout 2009 we ran a sprint retrospective - usually at 2.30 on a Friday at the completion of the sprint.
As is typical of these things, the early sessions were painful for both me and the team. But as the team formed and got better at communicating the value of these sessions increased (as opposed to becoming marginal as the big issues get resolved.)
After each session we (usually) transcribed the "Done well", "Not so good" and "Try this" comments to a Word doc and stored them in the project library. Sometimes we even actioned them :)
When I got back from summer holidays this year I grabbed the retrospective notes and dumped them into excel for a bit of sorting and analysis. There is some useful information here, and I'll give you a short summary of what we learned at the end. (There will be no surprises.)
What did the workshop look like?
Yesterday I printed all the "Try This" suggestions onto paper and cut them up into little cards and took them to a special team meeting. As I said i started the session with the roadmap for the year and then turned to the question of what we have learned so far.
I dumped the cards onto a table and asked the team to break up into four groups of 3-4 people and discuss which of these were "old news", "current but not so important" or "current and important."
At the end of the brainstorming session they came back together and shared their top couple of "Current and Important" items and we moved them into the continuous improvement action plan.
What did the team learn?
- The scrum framework really works, but you have to follow it.
- Pay attention to things like reviewing the forthcoming sprint's backlotg items prior to the planning session to help identify risks and issues.
- The product owner needs to be clear about the PBI before walking into a sprint plan, and ready to negotiate in the plan.
- People on the team have to champion what they have committed to. The scrum teams still need leaders internally.
- Focus on one job at a time. Finish things before you start new things.
- Attention to quality practices and standards is critically important. Don't take shortcuts. Ever. Even when Craig says so.
- The end of sprint deadline is hard. Don't be trying to cram in one last build while the sprint demo is going on. If it doesn't get done this week, we'll catch get it done next sprint. Our management support a sustainable pace.
- Be on time to meetings. And turn up prepared.
What did you guys learn from 2009?