Early last week my wife and I had an exchange that went something like this:

Esther: Did you know that AgileIndy is meeting on Tuesday evening?
Me: [blank stare]
Me: [silence]
Me: I didn’t know there was an AgileIndy!

Naturally I was a bit surprised (and proud) that she knew about a local software development group that I’d never heard of so i asked how she found out about it.  It turns out that she had been looking for some local events on Meetup and AgileIndy was one of the featured groups.

This “discovery” was very timely since I’m transitioning to a new team that’s going to be more agile than our teams have traditionally been.  Despite having read a few books and attending a few events like Cincinnati Day of Agile I’m still very new to it so I hopped onto the site, found their page and after reading a bit about it I decided I should go.

This month’s speaker, Eric Willeke (an Agile Coach from Rally Software) was discussing effective retrospectives.  Retrospectives are one of those areas that I very little exposure to beyond some textbook definition so I was pretty interested in what he had to say.

The Five Stages

Eric walked us through a five stage progression for retrospectives.  The idea behind the progression is to get people thinking about and discussing what is and is not working for the team. To illustrate how the progression actually works he led the group through an exercise that involved practicing each phase.

We used a retrospective starfish to facilitate idea generation.  The starfish is divided into five sections that help identify the things individual contributors think are or could be helping or harming the team.  These sections help focus thoughts and act as a catalyst for stage 1.

It is important to note that in the process there is a “curtain of silence” over the team for the first three stages.  This practice is intended to not only prevent individual members from monopolizing the conversation but to also encourage everyone to participate without the fear of not being heard.

Stage 1 – Brainstorm

The brainstorming stage is about getting ideas heard and each team member should have an equal voice. Ideas expressed during the brainstorming stage should not be critiqued.

Each team member writes ideas on sticky notes and places them in one of the sections.  Eric recommended imposing a one card in hand rule to prevent individual members from monopolizing the board and ensuring that everyone gets ideas in the mix.

Stage 2 – Cluster

The clustering stage involves taking the ideas from the brainstorming stage and grouping them into categories. Grouping each idea into categories helps the team focus on some key points.

Rather than discussing how to categorize each idea we collectively moved the sticky notes from their sections on the diagram into related clusters.  The one card in hand rule can also be useful here to prevent individual members from dominating the process.

After a few minutes no one was moving the notes around anymore so we hung up a different color sticky note for each cluster, named them, and moved on to the next stage.

Stage 3 – Prioritize

After categorizing the ideas the team should collectively decide which of the categories are the most important.  Prioritizing the categories helps further refine what the team hopes to address.

To prioritize our categories each person is given “votes” to split across one or more of the category notes.  Voting is simply a matter of writing a dot on the corresponding card.  After everyone has “voted” the categories with the most votes are identified and we move on to the next stage.

Stage 4 – Action

The curtain of silence is lifted at the beginning of stage 4.  The categories selected during the prioritization stage are then discussed (in priority order) in more detail to determine which action(s), if any, to take.  It’s at this stage where the sections from the starfish factor in since it’s entirely conceivable that team members have different opinions on how each one affecting the team.

Stage 5 – Commit

Once we’ve made some decisions about what to do the team should select one or two of the actions and commit to resolving them.  By selecting a small number of actions we not only increase the likelihood that the actions will actually be completed, we also introduce change gradually and make it easier for the team to adapt.

Eric recommended that we be as rigorous in defining our commitments as we are with user stories.  By applying the same standard we can better define what “done” means for the commitment.

Wrap-up

As a newcomer to this Agile world I found Eric’s talk and exercise incredibly beneficial.  As with so many things one can only learn so much by reading about these topics so actually seeing and participating in the process really helped me understand their purpose.  Now that I’m moving onto a new team at work where we’re going to start using more Agile techniques I hope to be able to apply these lessons soon.

On a related note, the next AgileIndy meeting is on Tuesday, December 6th at 6:00 PM.  This meeting is billed as a “User Story Writing Workshop” so it should be pretty interesting.  I hope to go but it’s in downtown Indy so I’m not sure if I can make it from my northside office.  If you’re interested be sure to check the group’s Meetup page for logistics.