My First Agile Project Part 12: The Good, The Bad and The Ugly – Our Retrospectives
Originally published on AgileSoftwareDevelopment.com
Welcome to Part 12 of My First Agile Project. Inspired by Peter’s recent 5 minute retrospective article, this time I’ll be talking about our retrospectives, which we termed our GBU or Good, Bad, and Ugly meetings. Our vendor brought these GBU meetings to us, along with the Scrum methodology, and while we weren’t doing everything by the book (not a surprise if you’ve read any of the other parts of this series) I think they were very valuable and still light-weight and easy enough to be adapted for other teams looking for retrospectives.
Read on for more on how we ran these meetings, what we got out of them, and what we’ll be doing differently in our next meetings.
Our Process
A good retrospective has to have some kind of structure to it, to keep from just becoming a complaint session or everybody sitting around silently. Our structure was to put everything into buckets of Good, Bad, and Ugly. Good was obvious; the stuff we thought went well during that sprint. Bad was things that could have gone better but weren’t terrible. And Ugly was things that were plain horrible, could have derailed the project, etc. Usually our Sprint Demo lasted a few hours in the morning, then after lunch we’d come back and do the GBU.
We started out the first few sprints coming in and just doing the three buckets in order; Good, Bad, then Ugly. Everybody would write down their list of things and we’d write them on a larger piece of paper and discuss. For Bad and Ugly, we’d also discuss things we could do to fix or make the things better.
After a few sprints, we started the meetings by going over the previous sprint’s lists of Bad and Ugly to see if we were actually taking care of those things or if they were just as bad. This is immensely helpful. It helps people speak up if they know their complaint isn’t going to be forgotten or blown off. This also acts as a retrospective on the retrospective, to make sure you’re getting benefit out of them instead of just wasting an afternoon. We also started doing the buckets in reverse order as well – Ugly, then Bad, then Good. We started this partially as a joke, because we didn’t want to end the meeting on a downer, but it was a helpful change as well. The Ugly and Bad lists always take more time to talk about than the Good list so it helps to give those the most time for discussion. And it does help to leave the meeting on a good note. Scrum is as much about how people feel than anything else so don’t ignore these kinds of benefits.
The biggest thing about retrospectives is to make sure everybody knows they can speak their mind. It’s not going to help anybody if people keep things inside and those things are just going to fester for that person if not resolved. We didn’t have any of our direct supervisors in our meetings, which let us speak to management issues at will. We also naturally kept things civil when it came to issues like work not getting completed, a benefit of us all being friends. I think my tendency to speak my mind, even on issues of upper management or other sensitive areas, helped as well. People saw that if I could run my mouth and be honest, they could as well. I didn’t set out to do that but I think it ended up helping.
Changes
When we started our retrospectives, none of us knew anything about them save what we remembered from reading Ken Schwaber’s Agile Software Development With Scrum and from our vendor told us. Now that I’ve read the excellent book on Agile Retrospectives by Esther Derby and Diana Larsen as well as what others have written about on this site and others, we’ll be trying some changes to our GBU meetings in the future. First, we’ll probably rethink the use of Bad and Ugly. It’s too hard to think of what makes something bad enough to be Ugly rather than Bad. Some teams just use a ‘What I liked’ and ‘What could have gone better’ approach and I think we’ll try something like that. Second, I like the idea of a timeline of events where people put things that happened on stickies where they happened in the sprint. This is part of Setting The Stage that Diana Larsen recommended to me at the Agile 2008 conference. This gets everybody on the same page before you start drilling down into details later. Other than that, a lot of the things recommended in the Retrospectives book and elsewhere seems like it would be important for teams that don’t get along but we don’t have that problem, which is one area in which we’re extremely lucky.
Overall, I’m absolutely sure our retrospectives helped our team and our project. Even for things like upper management not being involved, which I listed as an Ugly very early in our project and ended up being a continual problem, just talking about it with the team is useful. If people have these kinds of issues in mind, it can influence how you do things even if it’s not a problem that can be “solved.” I would really recommend all Agile teams do some kind of retrospective, even if it’s just a basic Good/Bad list of things on the minds of the team members.
Please share your retrospective tips in the comments below, it’s an important topic and one that everybody can learn something from. Thanks for reading.
You should follow me on Twitter here!
|
|
