The Mountaintop Scale

Retrospectives, and meetings in general, only really have value when the people involved feel comfortable enough to share what is on his or her mind. That's why we start with a safety check.

Safety checks are typically on a scale of 1-5. The participants write down a number and anonymously put it into a hat. The runner of the retrospective then tallies the results and decides whether it's worthwhile to continue, or something needs to be done to bring up the safety level of the team.

At least, that's how it was until yesterday. Yesterday brought the introduction of the mountaintop scale. Arguably simpler, but undeniably more accurate, the mountaintop scale ranges from 1-6...with 4 being the highest. Here's an ASCII art picture for your enjoyment.

      4
       /\ 5
    3 /  \
     /    \ 6
  2 /
   /
1 /

As our iteration manager so eloquently put it:

It's easy. If you're between a 3 and a 4, you're a 5. If you're between a 2 and a 3, you're a 6.

Happy retrospecting!

Project 1 Lessons [Retrospective Lead]

Progress on our project hasn't quite been at the pace we would have preferred, though time has certainly flown by. In fact, our speed of feature development was one of the hot topics at this retrospective — the first retrospective lead by the fearless team of Chris and myself.

Overview

Briefly, a retrospective is a look back at the previous cycle of work. There are several methods to go about it, but we're always trying to answer certain questions:

1. What went well?
2. What didn't go well?
3. What's puzzling?

We started our retro in the same fashion as any other: a thorough reading of the prime directive.

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.

Concrete Implementation

After covering our progress on action items from the last retro, it was time to jump into reflecting on our newly-completed iteration. We chose the rather standard format of placing stickies on a whiteboard. Everyone had roughly seven minutes to put as many thoughts as they could capture into their respective categories.

Our retrospective process is fairly democratic. We first want to make sure all the thoughts are captured on the board. Second, we group those thoughts into broader topics. Finally, we give everyone three votes to spend anywhere they like.

• one cannot vote against a topic
• one may spend all three votes in the same place

Discussion generally revolves around the things we can improve. Our retrospective was no different. We dutifully captured input and action items for next time, as well as recording owners for those action items (with group consensus, of course!). Oh David Allen, where would we be without you?

Velocity Check

Sometimes it's necessary to devote time to specific areas of concern before they become problems. The final piece of our retrospective was a section devoted to velocity, or the pace our team is completing features.

On the suggestion of a teammate, the visual we chose for this was a boat. Very similar to the exercise that preceded it, thoughts of things that made us go faster were near the engine of the boat. Ideas for what exactly has been slowing us down were placed near the anchor.

Perhaps unsurprisingly, virtually all of what we discovered here was covered in some form or another during the previous portion of the retrospective.

Takeaways

All in all, it was a pretty successful retro for the team, as well as for Chris and I. We did a many things well and received some helpful feedback on areas to improve, namely:

• Timebox discussions and activities
• Minimize open-ended questions

Both points lead to the overall goal of having concise and effective retrospectives.

Project Fact Our iterations are two weeks long

Comedy Quote "No no, my vote was voting against!"