In the previous blog post, we saw how Target learned to embrace design when their trend manager, Robyn Waters, made them see and feel what design could do for them. This illustrated the value of helping people visualize the change and feel something, whether it is being disturbed by a problem, or hopeful at seeing a glimpse of a solution. One of the most effective times an agile team has to visualize how their work is going and talk about how they feel about it is the retrospective.
There are many ways to conduct a retrospective. Many retrospectives are conducted by asking three questions: what do we want to stop doing, what do we want to keep doing, and what do we want to start doing?
There is nothing wrong with these questions. They can be very effective at bringing about discussion that can inspire the team members to look back over the previous iteration and think about how to adjust the way the team works together to better achieve the team’s goals.
Agile Retrospectives
But let’s consider some other ways of conducting a retrospective. The book Agile Retrospectives, by Esther Derby and Diana Larsen provides both a structure in which to design your retrospective and many activities to fill in each space in that structure.
Derby/Larsen retrospectives consist of five phases:
- Set the stage
- Gather data
- Generate insights
- Decide what to do
- Close the retrospective
In the “set the stage” phase, you get people thinking about why they are there and you get people used to speaking their opinion to the group.
The “gathering data” phase is about creating a shared picture of what happened over the past iteration and allows the following steps to build on top of that shared perspective.
In the “generate insights” phase, you take the data from the previous phase and use it to think about what needs to change. This is a critical phase because it is so often skipped as our natural tendency is to jump to a solution.
In the “decide what to do” phase, we can now make a decision together on all the proposed ideas in the “gather insights” phase.
The final phase, “close the retrospective” is all about closing the retrospective decisively. The facilitator expresses appreciation for everyone’s work and asks for a quick retrospective on the retrospective itself.
How I Like To Do Retrospectives
I personally like to set the stage by asking a question that the team can answer in a word or two so that each and every person on the team gets a chance to speak. In the gather data phase, I like to get people writing about how they felt the previous iteration went. I get them to categorize their thoughts into one of four emotions in a variation of the Derby/Larsen timeline exercise.
Borrowing from the Agile Retrospectives book, I use different colored stickies to represent different emotions felt over the course of the iteration:
- Green – Satisfied, Successful, Energetic
- Yellow – Cautious, Confused
- Red – Challenged, Stalled
- Blue – Sad, Mad, Bad
Each member of the team takes what they’ve written and puts it up on a flip chart, or in the case of the below image, pins it to corkboard. You might instead use software for this if you have remote team members.
A lack of green stickies might indicate a problematic iteration since nobody is recalling events that made them feel successful. A lack of other sticky types might indicate a team that is reluctant to share problems and maybe a lack of safety in the environment.
Finding Common Themes
Next, I walk the team through the stickies to draw out ideas on common problems or lessons learned from the past iteration. We look for common themes and group the stickies that way.
In our example here, the green stickies have a common theme that pair programming has been productive for the team. The yellow stickies also have a common theme: the team is confused about story priorities. Two red stickies and a blue sticky are about blockages due to dependencies between stories. Finally, two blue stickies and a red sticky are about an outage that occurred due to missing tests.
Generating Insights
At this stage, we generate ideas about actions we could take during the next iteration to address some of the problems uncovered. In this example, this three-person team could potentially produce action items as they generate insights. So they might come up with things they’d like to start doing, keep doing, and stop doing. It might look something like this:
- Start Doing
- Prioritize the backlog more consistently
- Keep Doing
- Keep pair-programming and do it more often
- Stop Doing
- Stop creating dependent stories
- Stop pushing code to production without tests
This example team consistently made comments about not knowing the priority of stories, so maybe they want the PO to prioritize the backlog more consistently. In Is your Product Owner Lazy or Exhausted?, I wrote about ways a team can help their PO at this challenging task.
Based on the green stickies, it looks like the team would like to keep doing pair-programming and perhaps do it more often. In 2 Tips to Make Pair-Programming Less Scary, I talked about ways to encourage pair-programming.
There were also two things they would like to stop doing. One is to stop creating stories that get blocked because of dependencies on stories that are in progress. In 4 Reasons Your Stories Suck, I talked about four reasons a team might have problems writing stories that are, among other things, independent.
They would also like to stop causing outages when they push code to production and this seems to be due to inadequate testing. Perhaps some investment in a Continuous Delivery system or introducing the practice of Test-Driven Development would help here. I talked about Continuous Delivery in Inspire Your Team with a Continuous Delivery Destination and Test-Driven Development in How To Find Test-Driven Development Bright Spots.
Decide What To Do
So here they are with four potential changes to make for the next iteration. They may decide to take on all of them or perhaps pick the highest priority one for the next iteration.
Retro Benefits
Using retrospectives to visualize the impact of the way we work and express how we feel about it has led to some significant changes in how my team works together. It also became a way to get input from everybody on the team, including the quietest engineers. So if you find your retrospectives getting boring, take a look the Derby/Larsen book and see if some of their ideas can help your team to see, feel, and change.
I would love to hear what you thought of the article, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.
