Category Archives: Retrospectives

An Active Listening Retrospective

The team I am on holds a retrospective at the end of each week-long iteration.  I am a huge fan of retrospectives as they can help teams improve their processes and nip developing problems in the bud.

Our team has a lot of Agile experience and we typically trade off the facilitator role, so the retrospectives have a nice variety of styles and everyone gets a chance to improve their facilitating skills. Our retrospectives normally gravitate towards process improvements or specific technologies that we can improve as a group.  This week however, I wanted to experiment with a new format that I came up with influenced by some meditation and mindfulness practices that I have learned over the years.  One of the techniques I wanted to use in the retrospective was active-listening.

Some of the questions that were on my mind…

  • When we are pair-programming and our pair asks a question are we giving our full attention to what they are asking, or are we more focused on the problem that we are working on?
  • When someone raises an issue at the team standup, are we mentally preparing our rebuttal and not focusing on what is being said?

Laying the Groundwork

This style of retrospective needs to be held in a quiet place like a conference room, with enough room for team members to spread out in pairs without distracting one another.

At the start of the retrospective I reminded the team that we had all probably come from working on some challenging task, and our minds may still on those tasks to some extent.  To be fully present at the retrospective, I asked everyone to take a moment to clear their minds and focus on being present.  Next time I may try a short breathing exercise to help that process, but sometimes just reminding people to be present is enough for them to realize the distractions that may be going on for them and to put them aside.

The Mechanics

I asked everyone to take a few minutes, in silence, to think about what happened in the last retrospective.  What went well, what could have been improved, what pleased them, what frustrated or challenged them, whatever came to mind from the iteration.

I then asked people to pair up.  I chose names out of a hat because I wanted the pairs to be random and possibly have people pair up with someone that they might not normally seek out.  Also it eliminates the stress of “choosing” someone.  If there is an even number of people at the retrospective, the facilitator can participate, otherwise they focus solely on facilitating.

I then instructed the pairs to find some space away from the others, and for a few minutes (3 minutes in our case) one of the people would be the speaker and the other would be the listener.  I encouraged the listener to pay close attention to what the speaker was saying, and try not to form responses in their minds.  If the conversation lagged the listener could ask open-ended questions, but ideally they would focus only on listening to what the person was saying.

After the 3 minutes was up, I asked each of the listeners to tell the group what they heard from their speaker.  Everyone did a great job recalling what was said.  After each “listener” spoke I asked the “speaker” if the listener accurately relayed their conversation and if anything had been left out, which gave them a chance to fill in the gaps or clarify something that was said.

We then repeated the process changing speaker and listener roles.

After everyone had a chance at the “speaker” and “listener” roles.  I went around the room and asked each person if they heard anything that stood out in particular or that surprised them.  I made a conscious effort to allow each person to say what was on their mind, without getting a conversation started with the whole group.  If others chimed in I asked them to please wait until everyone had a chance to speak before we turned it into an open discussion.

A few common themes emerged from the individual observations, and after everyone had a chance to speak individually we discussed the common issues for a bit and came up with some actions to address them coming out of the meeting.  I wrapped up the meeting reminding everyone that we are often hyper-focused on the problems in front of us and may not give one another our full attention, but that we should be mindful of that and try our best to listen to one another.  I hope we can build on that as a team.

The Take-Away

One of the coolest things about the format, that I didn’t realize until it was happening, was that everyone got a voice through someone else telling their story about the iteration.  It is inevitable on any team that some people are more outspoken than others (I am no shrinking violet), but this way everyone got the floor.

I think it was also an opportunity to remind everyone that we each have our own perspectives and we should respect and try to understand each other, even when we may not agree.

Total time for the retrospective, with 6 participants, was 45 minutes.

Further Reading/Watching

If you are new to retrospectives, I highly recommend Esther Derby and Diane Larsen‘s book Agile Retrospectives – Making Good Teams Great.  It has great techniques for organizing and facilitating retrospectives so that they are most effective.  They also have formats that are designed to address specific issues that may be a concern for your team.

If you are interested in mindfulness, I recommend that you check out the Center for Mindfulness at the UMass Medical School or take a look at these videos with Jon Kabat-Zinn, founder of the Center for Mindfulness, speaking at Google.

Stone Soup Development

I consider myself lucky to work in an environment that not only follows, but embraces, Agile and XP practices.  We follow test-driven development.  We pair program almost all the time, and we switch pairs frequently, usually at least once per day.  The benefits of these practices hit home this week during our iteration retrospective when the question was posed “What were you proud of this week”.

There were some interesting problems with very creative solutions that happened during the iteration, but the thing I was most proud of was a simple little piece of code.

Around the middle of the iteration I worked on a “calculator” that made some determination based on a set of rules.  We’ve all written code like this 1000 times before, it was not an especially difficult task.  But it was the kind of thing that could get ugly pretty quickly, and yet still “work”.  It was the kind of algorithm that could have easily morphed into a nasty tangle of boolean logic.

Instead, my pair and I started out with a few simple cases and applied a few brute force implementations in the “Calculate” method.  We continuously refactored as more tests were added and the complexity grew, reducing duplication and breaking the problem up into more digestible chunks.  At some point, my original pair swapped out and someone else swapped in for an hour.  It was late Friday, we improved some of the naming, added a few more test cases and supporting logic, then called it a day.  Energized work in action.

Monday morning, a new person swapped in.  Normally I would have swapped out since I had been on it the longest, but there were a few scheduling conflicts and so I stayed on.  We finished the class, ending up with very expressive names, a “Calculate” method that read like plain English, and small methods that did one thing, and did them right.  Again, this problem wasn’t rocket science, but it was done right.

Everyone brought something to the problem and helped refine the design.  We discussed trade-offs, avoiding traps like “my idea” and “your idea”.  After discussing it at the retrospective, it reminded me of a story that I learned as a kid called Stone Soup.  We started with nothing, everyone threw a little something in the pot, and we came out in the end with a nice little piece of code.

New Team – First Retrospective

Rally recently held a “success tour” event in Boston. I have been using Rally for about 18 months, but recently began using it on a team that is new to Agile, so I was interested in seeing if I could pick up anything that would help ease the transition. The event started with a roundtable of executives who have successfully used Rally, and a quote that hit home for me was from Jochen Krebs who said “every team needs to find its own unique path within the Scrum framework”. Joechen’s presentation at the Boston event can be found here (you have to hit the “older” button a few times to get to his presentation).

An interesting follow-up to Jochen’s presentation was given by Heather Kanser who pointed out the danger of teams “cherry-picking” the parts of Agile that they wanted. Their talks were complimentary as Jochen’s comment about teams finding their own path was “within the Scrum framework”.

I came from a team that has had good success using Rally and Agile in a particular way, and one of the challenges for me has been to tailor the approach for a new team. We’ve been introducing some new processes and adoption has been a challenge for both sides. We introduced some new processes about how we do releases and validation, and recently pushed out a new release of the software. It seemed like a good time for a retrospective. Of course, if I read my own posts, I would have remembered that the right time for the first retrospective may have been right when I first joined the team.

The comments for “what did we do well” were very encouraging. Collaboration, better testing, delivering what we promised, fixing architectural issues were all mentioned. I was particularly pleased that delivery of promised features and improved testing were included. These were areas that I pushed hard for and it was gratifying for the team to see the value. It is always nice too when you hear team members say “that can wait for the next release”. I think one of the hardest parts of initially adopting Agile is having faith that regular releases will provide an opportunity for more incremental improvements down the road. Delivering what you promised is more important than trying to add more features near the end of the development cycle.

There was some good discussion about what we could do better. This was one of those times where as I heard at the Rally event, the team needed to find its own flavor. I tried to stay back a bit from the technical aspects and work more to facilitate the discussion. It was very interesting to see how what we thought were the most important items to address evolved over the meeting. We have some actions and a follow-up meeting scheduled. Should be interesting.

Project Retrospective

I held my first project retrospective this week. It was probably overdue, but there is no time like the present right?

I found Peter Steven’s blog and Boris Gloger’s paper on Heartbeat Retrospectives helpful in setting the format. I decided to cover the following topics in our retrospective

  • What did we do well?
  • What can we improve on?
  • Who has ownership of the things that can be improved?
  • What are the priorities?

We used sticky notes and a white board. You need to be succinct to state your point on a sticky note. Plus once they go up on the whiteboard they tend to lose ownership and they become the team’s ideas. There were only a few times when we had to ask who wrote something and that was only to clarify an idea. The group ownership of ideas keeps things flowing and prevents the meeting from being driven by one or two strong personalities.

Starting with “what went well” set the tone that the meeting is going to be positive and constructive. At other companies I have been at these type of meetings often turned into a finger pointing exercise and went downhill rapidly. Our team has a lot to be proud of, and it was great to reflect on the things we did well. And if it ain’t broke…..

The things we thought we did well broke down into 3 catgories: Team, Process, and Technology. I am not sure if that categorization was planned or an impromptu decision. Grouping them into categories didn’t really serve any purpose other than it allowed us to acknowledge each point as we decided where it belonged.

Like any project there are things that we can do better. We purposely did not put any limits on what people thought we could do better. Once we put everything up on the board we broke it down into two groups: Team and Organization. Team means we can do it within the framework of our own team structure. Organization meant we had to bring others (HR, management, etc) into the mix to help address the problem.

Once we had things broken down into 2 categories, it was time to prioritize the lists. There are a couple of different schemes you can use here. Seeing the same issue raised by multiple people may indicate something that is important. Ultimately we decided to do a simple voting scheme where everyone got one vote, and that seemed to work pretty well. Next time we may try giving everyone three votes, but that’s for next time. We have a small team, so there were only a few items in each category that got votes, but even that tells you something, and we were able to prioritize those items. The reality is you can’t fix everything, so you focus on what is most important.

Probably the most important part of a retrospective is that you take action on the high priority things to improve. I am anxious to seize the momentum and teamwork of the meeting. That is the challenge for me and the team in the very near future.