Blog Posts tagged with: retrospective

May 02 2012


Why Retrospectives Should Get Personal

What do you get when you cross a bunch of passionate, self-directed engineers with an agile, iterative approach to both software and personal development? Predictably, you get continuous delivery of customer value and solutions to really hard problems. Additionally, as a nifty bonus, you get a new kind of discussion forum that brings all the best qualities of agile software development to individual improvement: the Personal Retrospective.

Before your imagination goes too far, let me assure you this does not require hugging, silly hats, or revealing favorite brands of underwear. Nor is there screaming into a mirror or "Fight Club" activities of any sort. The Personal Retrospective is an undertaking at Relevance that forms a cornerstone of our company culture and a critical ingredient to our goal of continuous improvement at all levels.

Great Feedback in 60 minutes or Less

The key ingredients for a Personal Retrospective at Relevance are five or so team members who have first hand experience with the subject's recent performance and another Relevance employee who serves as a neutral facilitator for the discussion. During the meeting, the individual is provided with an hour of open and honest feedback which validates and appreciates areas where they are providing their best value to their team and clients, and calls out ways they may not be meeting the mark or have the greatest room to grow.

An agenda is set ahead of time by the subject (with the help of the facilitator) to focus the feedback on areas and goals most important to them. The experience can be extremely positive, giving deeper insight into the impact your actions have had on those around you, as well as deeply emotional as you hear the negative effects even your best intentioned actions have had on the team.

Sometimes there are surprises, though often the subject has at least some notion of where things are not going great, and a critical component of a successful Personal Retrospective is a list of clear action items and mechanisms to encourage and monitor improvement once the meeting concludes.

I Never Thought it Would Happen to Me...

Recently I had the opportunity to participate in my own Personal Retrospective to evaluate current performance as an Agile Project Manager and Coach. Although I had requested the meeting and chose the attendees, it was still quite intimidating to hear several people who I respect greatly talk about me both positively and critically (and often in the third person as guided by the facilitator to ensure the messages are clear and actionable). In the end though, it worked wonders to quiet the distracting internal voice of insecurity by hearing where my efforts are helping the team. Additionally, it helped me understand where I have been dropping the ball, along with recommendations on how to get on the right track.

The guesswork has been largely eliminated in the form of a group of trusted peers stating "This set of things you do, they are really good; keep doing them. This other set of things, you're doing okay, and here are some tweaks to make them better. And this set of things, these actions are having a negative effect on us and the project; here are examples of them and some clear ways to change these behaviors."

Bringing the Love Home

This isn't a review. No money, position, or responsibility changes are made as a direct result of what is said. It is a safe forum for enabling feedback to help folks at Relevance along in their journey. Such a personal and sometimes difficult meeting may not be for everyone nor for every organization, but it is an option you and your team should consider when looking for additional ways to get to the next level of individual and group performance. If you'd like more specifics on how the process works, give us a shout and we'll be happy to help. If it doesn't work, you can always go with the silly hats and underwear stories.

Oct 06 2009


NFJS, the Retro (Twin Cities Edition)

We had a terrific conference retrospective this weekend at the Twin Cities NFJS show. Eight people participated, with me facilitating. The conversation was good, and everyone left excited to implement the SMART goals that we chose.

As usual, we followed the basic structure from the Agile Retrospectives Book: Setting the Stage, Gathering Information, Generating Insights, Deciding What To Do, and Closing.

Setting the Stage

The NFJS conference retro is an odd beast: a sixty-minute retro embedded in a ninety-minute talk about using retros in your own organization. This poses a few special challenges:

  • The team needs to have a working agreement to occasionally "go meta" and talk about the mechanics of the retro during the retro. This risks reducing the value of the retro, but so far attendees have found it effective.
  • The team isn't really a team: it is a subset of the conference attendees thrown together for the first time to do the retro. So, the facilitator has to choose the activities in real time to match the size and composition of the group.

Sticking to the time box, we covered these ground rules in the first five minutes.

Gathering Information

To gather information, we used the team radar activity from the book. A few minutes of brainstorming identified about ten possible items to rate. That is too many to actually rate, so we used dot voting to narrow down to four items. Each participant used a Sharpie to make three dots next to the items they considered most important. As usual, the moving about the room helped people get engaged physically and mentally.

The items and their individual rating (1=worst, 10=best) follow:

  • meaningful content: 8, 7, 8, 7, 7, 7, 7
  • speaker quality: 9, 8, 8, 8, 8, 8, 9
  • track organization/session selection: 7, 8, 6, 6, 6, 6, 5
  • price/value: 8, 7, 6, 6, 8, 7, 6, 8

These numbers are quite high; overall possibly the highest I have seen at a conference retro. Also, the lowest scores were on track organization. When selecting talks for a conference it is almost impossible to please everyone, so while the scores were lower I was not optimistic about finding a useful recommendation. (Note that as the facilitator I kept these musings strictly to myself during the retro!)

Generating Insights

To generate insights we used the learning matrix. This exercise uses four quadrants (happy/sad/ideas/appreciation) to guide brainstorming. In the interest of space I will not reproduce the matrix results here: the information would be meaningless without pages of explanatory text.

Unusually, the "ideas" section filled up first. In fact, to hit the time box we didn't even manage to fill the other quadrants.

Deciding What To Do

To keep to our sixty-minuted time box, we agreed to dot vote for two items on the ideas list, and convert them to SMART goals. A SMART goal nees to be *S*pecific, *M*easurable, *A*chievable, *R*elevant, and *T*imely.

We ended up selecting these goals:

  • By February 2010, update the website and printed materials to include a single-line of text describing the "recommended audience." Free text might seem dumb compared to some kind of tagging, and it is delibarately so. We started to discuss a system of categories and realized that this would make the goal more complex, and therefore less likely to be implemented. Keep it simple.

  • By February 2010, run a birds-of-a-feather (BOF) session titled "What To Do on Monday!" Everyone agreed that the conference talks were inspiring, and included ideas that could create massive improvements back at the day job. But massive improvements are often beyond the immediate control of conference attendees, and it is frustrating to go back to work on Monday and not be able to start a new practice. The BOF will allow attendees and speakers to look across all the conference topics and generate a list of bite-sized ideas. If the BOF goes well, we will use it to generate an outline for a formal talk.

February 2010 might seem like a long way off, but since the retro was a breakout team that did not include the people who would actually have to implement the recommendations, it seemed wise to allow the work to be done during the winter off-season for the NFJS tour.


To close the retro, we did a quick thumbs up/down/sideways check to see if the participants found the retro useful. Votes were seven up, one sideways.

All in all, a good sixty minutes. I am excited about implementing the new ideas, and I think that the regular recurring nature of NFJS provides a great opportunity to close the feedback loop faster than at a conference that runs less frequently.

Recommended Reading

Jul 22 2009


Teaching retrospectives by example: NFJS Salt Lake City

Want to learn about agile retrospectives? Participate in one! At the No Fluff, Just Stuff software symposiums, I am doing a talk on retros where we begin by doing a retrospective on the conference itself.

At the Salt Lake City show this weekend, we had eight participants for the retrospective. NFJS talks are ninety minutes long, so we took the first sixty minutes to run a retro on the conference. Given that we only had a day of experience to retrospect on, and that we were not a cohesive team but were "thrown together" by people selecting the talk, I wondered if we would have enough to talk about. This turned out to be a non-issue, as everyone threw themselves in with gusto. We could have easily gone longer, and as facilitator I had to enforce the timebox on each phase.

Setting the stage

As an icebreaker, we did a variant of the Checkin exercise from the Agile Retrospectives book, using the question "If this conference was a movie, what movie would it be?" Answers included:

  • Driving Miss Daisy
  • Casino Royale
  • El Diablo
  • Lord of the Rings
  • Serenity

We had a few laughs, and the exercise broke the ice. However, nobody referred back to the movies in later exercises, so we will all just have to wonder if NFJS folk are orcs, reavers, outlaws, chauffeurs, or Quantum.

Gathering data

Next, we performed the Team Radar activity. After a few minutes of brainstorming, the team came up with eight possible topics to rate and discuss: prescriptiveness, (topic) diversity, relevance, scheduling, comfort, inspiration, food, timeframe. In order to hit the timebox for the retro, we agreed to use dot voting to select only four of these topics for further discussion.

Each attendee then ranked the four topics on a scale from 1 to 10, resulting in these averages:

  • 6.9 (topic) diversity:
  • 7.9 relevance
  • 5.9 scheduling
  • 7.4 inspiration

There were no major outliers on any of the scores. Overall, these scores are pretty high for a group who is taking seriously the challenge of finding things to improve.

Generating insights

Given the small group size, we elected to have a free form discussion to generate insights. Some of the ideas included:

  • Happy to see non-Java languages such as Clojure, Groovy, and Scala.
  • Would like to see even more non-Java, but ...
  • ... very happy that the Java topics were directly applicable to attendees jobs.
  • The agile talks were developer-focused, would like see more holistic talks.
  • For inspiration, the cornerstone is the first day keynote. Keynote was good, but could have been more novel.
  • Half of the participants had been to multiple NFJS conferences. The feeling of "it blew my mind" was still there, but not as strongly as in the past. Suggestion was made that this was the attendees changing over time more than the conference.

SMART goals are hard ...

The initial discussion of possible SMART goals attacked the lowest-scored item from the Team Radar: scheduling. How can the topics in a multi-track event such as NFJS be better organized so that participants are excited about every talk they attend? After a few minutes talking about track definitions, topic tags, website improvements, etc., we agreed it was a hard problem that was not going to yield a SMART goal in the time we had.

...Until you focus on the people

And then, by focusing on people instead of technology, we came up with two ideas that could significantly mitigate the scheduling problem:

  • Make it socially acceptable to walk out of a talk. Half of the participants said that, given a specific invitation to do so, they would have ducked out of at least one talk after they had seen the first few minutes and understood the agenda. So, at the next show, we request that all speakers choose a point 5-10 minutes into the talk to, well, invite people to leave. Keep count of the number of people who take the offer to decide whether this should become a standard practice.
  • Provide easy-to-find video on the NFJS website so that attendees can get to know each speaker before the show.

I brought the second idea to the conference organizer, Jay Zimmerman, immediately after the talk. He laughed because he is already doing it, building a collection of five-minute videos introducing the NFJS tour speakers. If only all SMART goals went so smoothly!


We voted up/down/neutral on whether the retro was worth the time, with all participants voting "up." The discussions helped each of us clarify our own perspective on the conference. Also, we were happy to have found easy-to-implement recommendations to improve the conference experience. After the retro, we had twenty minutes to discuss how to run a similar retrospective for an agile team, and some of the attendees are planning to try it with their own teams. As facilitator, I was pleased with the retro, and I am looking forward to taking this idea to other cities over the remainder of the year.


  • The Agile Retrospectives book includes dozens of retro exercises, and guidelines for when different exercises are appropriate. It is one of the books we recommend to team members on our projects.
  • Check out the agile talks at an NFJS event near you.

Mar 25 2009


Agile Retrospectives

Agile teams manage change and risk by adapting. But to adapt, you must identify opportunities for change and take them. Retrospectives are a fun, cost-effective way for your team to learn and change.

In this talk, we will begin by conducting a mini-retrospective, so that you get a feel for the basic process. Next, we will review the core principles of a retrospective, and use these principles to compare and contrast a variety of retrospective activities from the book Agile Retrospectives.

Next, we will explore a few retrospective activities in greater detail. These are some of the favorites that we use regularly at Relevance:

  • team radar
  • prioritize with dots
  • learning matrix

Finally, we will talk about how to tune retrospectives to the needs of your team at a specific moment in time. No two retrospectives are alike, and an experienced facilitator adds value by adapting a retrospective to meet the current need.

Popular Tags