Subscribe
Posted on July 17th, 2008
On Monday, I started my new role as a Development Manager of a team here in Tampa. I’m extremely excited to be working with them – they are a great team that has been around for a long time, and are excited about finding new ways to produce software.
Last Thursday they released a new version of their product. It was, as quoted by several members, chaos. While all of us may like some chaos from time to time, it’s not a good model for shipping software – even if that schedule is 12-18 months.
One of the first actions I took was to lead the team in a retrospective. I used several exercises out of the very excellent Agile Retrospectives book by Diana Larsen and Esther Derby. The exercises I used were:
- Check-In – each person says 1-2 words about what they think about the process. The goal is just to get everyone to same /something/ since they’ll be more likely to speak later
- Focus On/ Focus Off – What should we focus on during the retrospective, and what should we focus off of?
- Timeline – We broke the group into small teams, and each team wrote an event that happened during the iteration on an index card. This could be as simple as "Shipped the release" or "Lost team member" or something even as small as "The boss brought in donuts during testing week". We then grouped the cards on the wall based on the quarter they fell in – yes, this spanned 6 quarters of work – not a length of time you ideally want to do retrospectives for
- Color Code Dots – I chose to have everyone then come up and grab a marker which represented either a high point or a low point. Multiple dots were encouraged.
- Patterns and Shifts – I then took the cards with the most dots and started grouping them. We discussed each one and put them into categories. We came up with 6 or 7 categories that all of the cards fell into.
- Learning Matrix – This is basically a 2×2 matrix I drew on the whiteboard specifying what was good, what could be changed, new ideas, and accolades for specific actions.
- Start/Stop/Keep – Then we took all of the above insights and put them into an action plan of things we were going to start doing, stop doing, or keep doing.
At the end, we then held a retrospective of the retrospective itself. This was good to get feedback about what worked, and what could be improved.
The results of the entire exercise were awesome. The team, without any prompting from me, came up with the ideas that the way to improve was to find ways to be more agile in their approaches to estimating, developing, and releasing. In addition, they identified that they needed to involve the whole team earlier on, including QA and support. I couldn’t have been happier!
The retrospective itself was cross-functional, in that in included the entire dev and QA teams, some Business Analysts, Support and Management. The feedback I got was extremely positive, and everyone seemed to really enjoy it. In fact, we even managed to capture a couple of pictures (at least the ones I can show. ;)):
The team color coding the dots
Me leading the Patterns and Shifts section
I’d highly recommend picking up a copy of the book and trying this with your own team. You might learn some insights that make your team that much better!
Congrats Cory. A well run retrospective is a beautiful thing.