A Retrospective based on Agile Values

On Wednesday I ran my first retrospective. I decided to focus on some of the positive values that make up a good team: Simplicity, Feedback, Courage, Respect and Communication. The values came from the second edition of Kent Beck's book: Extreme Programming. I also used another great book Agile Retrospectives to help me out. We only have one copy of the book in the office, more are on order, I plan to buy one personally for myself. Being my first retrospective, I was slightly nervous, the format I chose was a little different from our normal agenda. Some of the methods I wanted to try we hadn't used before in our team. Our iterations are weekly, so we find that a one hour morning retrospective is enough time to disccuss and work through the issues of the last week.

Agenda

• Check in - 5 mins
• Reading Prime directive - 5 mins
• Brainstorm Values - 20 mins
• Dot voting Values - 5 mins
• Discuss results - 15 mins
• Retrospective feedback - 10 mins

Total: 1 hour.

Check in

The retrospective kicks off with a brief check in. It's a chance for every team member to quickly state how they felt about the last iteration. Part of it's value is reminding every team member that their voice is important. With a team of 14 people, some more vocal than others, it's important to respect everyone's opinion.

For check in, I asked each member to describe how they felt about the last iteration, but I deviated slightly from the normal format by asking that they limit their answer to only one of five adjectives:

• Happy
• Angry
• Apprehensive
• Sad
• Hopeful

Their answers were mainly "Happy" with a few "Hopeful" and one "Angry"; more on that angry later.

Prime Directive

After the check in I asked a team member to volunteer to read out the prime directive. Retrospectives are about learning, improving and reflection. People can be vocal in retrospectives, but things should remain positive and not descend into negative blame and personal criticism. The words of the prime directive remind everyone that:

Regardless of what we discover,
we understand and truly believe that
everyone did the best job they could,
given what they knew at the time,
their skills and abilities,
the resources available,
and the situation at hand.

Then, by a show of thumbs, the team voted on if they agree with the statement. The majority of people normally vote thumbs up. Sometimes people have a half way vote, this tends to be a personal criticism of their own performance, rather than directed towards their team mates.

Brainstorm Values

Prior to the meeting, I'd made up five posters on the wall of the meeting room. The team spent 20 minutes talking about and defining what each of the values mean in relation to the team. Post it notes were stuck on each of the posters.

Dot Voting

I asked each team member to vote on a scale of one to ten on each of the Values, with a one meaning we were not honouring the value and a 10 exceeding in the Value . The team placed sticky dots on a star chart. The average rating of each Value was agreed on. The individual ratings were then used to place the values in a comparative order:

The team felt Courage was our strength, followed on by Communication, then Respect, Simplicity and lastly Feedback.

Discuss Results

I followed up the results by asking why did the team think feedback was voted as one of our weakest values. The team conclusion was that it was not a criticism of  internal feedback, but rather our interaction with business owners outside of the team. An action was agreed to address this. This was the source of the anger mentioned at the check in earlier.

I wanted to end the discussions on the positive, so I asked a similar question about courage and why that was voted a team strength.

I think that the wide spread of votes regarding simplicity was worth discussing, but time was not available to discuss this further.

Retrospective Feedback

I closed the retrospective with return on time invested chart (ROTI). Agile is about self anaylsys and continual improvement. It's important to apply the same principles to the retrospectives too. I wanted to spend a minute getting feedback on how the retrospctive can be improved next time. This type of retrospective recieved 4 votes saying that it was a break even, received benefit equal to time invested and 8 votes for just over that judgement. Someone commented that it was not the best retrospective, but not the worse that we've ever done either, but not one that they would want to do every week.

I tend to agree, I felt previous retrospectives have created some strong actions that have seriously improved the team. This week's retrospective was deep in discussion, but lacking in  strong actions.

Comments

[Shane Dwyer]

Ben,

Caitlin pointed me in the direction of your blog. I'm really keen to run one of these workshops for one of an ideation sessions around 'reducing complexity'. Thanks for the background, great food for thought.

Cheers
Shane