A Feel Good Retrospective

If you're not careful, retrospectives can sometimes feel like work or routine for your team. Chances are that if you see the retrospective on your calendar and think to yourself "ugh, another retrospective," that your team is saying the same among themselves. This is a sure indication of the need to freshen things up.

A problem with freshening up your retrospective format is that many of them are pretty derivative. How many times have you tried to find a new format and come up with the "pretend your team is a hot air balloon or pretend your team is a boat" type of retrospective? Not very original and you're not fooling the team by changing your boat into a rocket ship. It's the same exercise.

Most retrospectives end up with the team being told to identify some problems and a solution or two for these problems. Yay. We all get it.

Having felt like this over our past few retrospectives I did lots of research to find something, anything, different. Lo and behold I came across a retrospective format on respected Agile evangelist and speaker Ben Linders' website.

It's called the Core Qualities retrospective which focuses on identifying each team's members strengths and then aligning them with problems your team is facing.

While we didn't come away with any takeaways (we ran out of time and I'm a stickler for schedule), I feel like this was one of our most enjoyable and beneficial retrospectives ever. In my almost five years at Business.com, I can't recall a time during a retrospective that our team members smiled and laughed so much. I found myself also grinning ear-to-ear as we went around and talked about the qualities we appreciate in one another.

People simply don't get enough praise and appreciation in their lives (especially at work) and this exercise was really powerful for the team. I can honestly say that despite the fact that no problems were surfaced and no solutions provided our team came out of that room as tighter-knit group. It may sound sappy, but there you have it.

Here is our tangible output:

How can you not feel good about seeing words like that under your name? (BTW I got helpful, organized, concerned, disciplined, flexible.... not bad for a ScrumMaster ;) )

So if your team is feeling a bit burned out on retrospectives I highly suggest giving this one a shot and your team will be able to reestablish why you all work together. You've got nothing to lose and I assure you that your team members will feel appreciated. What more do we want at work?

Are Your Agile Retrospectives Growing Stale?

The other day I stumbled upon Michael James' ScrumMaster Checklist and decided to fill out and see where we were at as an agile team. While I'm not going to go into detail, there were some things that caused a great deal of self-reflection for me; in particular:

Have you tried a variety of formats and locations for Sprint Retrospective Meetings?

This is something I've been wanting to do since last time I decided to breathe life into our agile retrospectives with great success. While this method has been a tremendous format for gathering feedback on the previous sprint, it seems that the team is getting a little too familiar with how it's supposed to go. Another problem is certain team members struggle to think of two positives and negatives in advance of the meeting so we waste time as they frantically try to get something on paper.

In researching different formats that people have used, I stumbled across this list of agile retrospective formats and think I'll be rolling out the 6 Thinking Hats Retrospective Plan for next week's retro. I'll be posting my experiment on my blog when the results are in!

What kind of formats have you used in your retrospectives? Any thoughts or suggestions are much desired.

How to Breathe Life in Your Retrospectives

I mentioned in a post a few weeks ago that our development team was singing the retrospective blues and was going to implement a retrospective meeting that turned the tables on how feedback from the team was provided.

Yesterday we relaunched the fantastic looking Business.com, which is the product of a lot of planning and hard-work across a project that lasted 4 development sprints. I took this opportunity to try out the format that Marc Nazarian laid out on ScrumAlliance.com and here's what happened:

(note: we ran this as a project-wide retrospective, but the same process is to be followed on sprint retros)

I sneaked into the board room early and laid out four cards with two different colors in front of everyone's seats. It was clear when everyone stepped into the room that things were going to be different this time.

The first task for the team was to rate how the project went from their perspective.  Needless to say I'm pleased with the results:

We hold our teams to really high standards and have communicated that a 5 in a situation like this would mean an absolutely flawless project, which in my eyes is nearly impossible to achieve. Our teams can always improve and this project was no different.

With that out of the way, it was time for the team to find out about the cards. Each person was to write down one thing that went well on each yellow card and one thing that didn't go so well on each of the red ones. Instruct your team to keep it 3 words or less.

Tip: Naturally, everyone said it would be difficult to keep feedback to just a few words, but encourage them to play along as it will become evident why in just a few minutes.

Tip: Instructing people to come up with feedback on the spot can be tough in a group environment because time is always a constraint and people feel on the spot. What I did to mitigate this was tell everyone in advance to come up with two positives & two areas in need of improvement. Even with preparation this still took longer than I wanted so watch the clock.

The next step is to tell everyone to pass their red cards to the person to their left and the yellow cards to their right. They now know each person will have to read someone else's cards. It was precisely at this time that, with a huge grin, one of my developers blurted out "this is so much better than what we've done in the past!" Results.

You then go around the table with the team trying to explain the issues that were brought up on the cards in front of them. It's a very powerful exercise as it gets the team to put on the shoes of someone who may have a completely different job description and see the world from their perspective. After the presenter was through describing their cards, I asked the author of the cards to rate how the presenter did in getting to the crux of the issue. Every single one was rated 5. A well-aligned team indeed :)

At this point the feedback was flying in fast and keep in mind that this is a team who normally would do their retrospectives in 5 minutes time with most of the feedback being of the "I think the sprint went great" variety. The team was noticeably excited to have an engaging forum to improve the process.

Tip: As the feedback comes flying in, it can be helpful to write the areas of improvement on the board because you will be coming back to these.

After everyone is finished presenting, the team passes their two red cards to the left (discard the yellow ones for now) and you go around the room suggesting improvements for each.

Tip: As Mr. Nazarian warns, everyone is going to want to chime in on most issues, so be sure to have the person reading the card provide their ideas first. Everyone will have a say in the end, but it's best to get a suite of ideas instead of only from those who traditionally dominate meetings. Sometimes the best ideas come from the most unlikely sources.

If you're doing this right, you'll have three lists on the board: what the team should stop doing, start doing, continue doing. From these the team will take the top priority ones and decide how they will change for the better.

Our biggest issue that we're going to be tackling is how we use our tracking tools to aide the development process. We have a pretty basic configuration of JIRA to track requirements docs, psds, bugs, and issues while the developers use Pivotal Tracker for their "marching orders" and sprint organization. The team felt frustrated with our convoluted integration of these two tools as well as the difficulty in tracking versions of documents and the changes within. Since this is a large issue, there will be future discussions on how to fix these problems, but the feedback so universal around tracking that it's imperative we solve these problems.

At the end of the meeting, I once again asked the team to rate something; this time being the return of investment of their time for the retrospective. Here was the result:

Though I may have missed vote, the tally was merely for posterity. Everyone was delighted with the effectiveness of the new retrospective format and I honestly (and perhaps cheesily) think the team walked out of that board room with an improved sense of unity and camaraderie. The process was engaging, fun, and elicited a treasure trove of thoughtful feedback. I'm now tremendously motivated to re-evaluate all of our agile cadence meetings to hit the bar that was raised with this new retrospective.

Tip: As ScrumMaster, you are the time keeper. I knew we would be pressed for time and even so our meeting went thirty minutes over. Perhaps this was because we were reviewing the whole project, but there's a lot to discuss in 60 minutes so try to keep things moving.

Here is some of the feedback I've received since the retrospective:

As posted by our Lead Designer in Yammer (to our entire company):

If you call it a debrief, postmortem or retrospective,the fact is Tim Sorweid nailed it today. Mr. Sorweid facilitated an excellent session with key members of the  team. The focus of the event was to identify wins and opportunities for improvement. One team member was overheard saying "Tim is scrum master equal to none."

And in an email to the team from an engineer:

I want to thank Tim again for re-evaluating the Retrospective Meetings and coming up with a new format that was truly valuable.  I think we can all agree that the old format had become monotonous, and we were no longer taking anything valuable away from the meeting. Once again thank you Tim, it's ideas and meetings like this that are going to help shape this company. 

I'm not trying to toot my own horn (that much), but am instead trying to show the immediate gratitude by the team of finding a format that is useful for them. If you've been struggling with your retrospectives you owe it to your team and company to try this right away!

Killing the Retrospective Blues

One recurring problem that has been happening on my projects lately has been ineffective retrospectives. Usually we go around the table and air our grievances in a very festivus-like manner and the feedback has dragged on to the monotonous "I think everything went great this sprint" by each developer.

As I notice this happening, I began to encourage people to have "something negative" to say about the process with the understanding that our process isn't perfect and it's there for the team to mold and shape in a way that makes sense to them. I came to the (very late) realization that this is a pretty poor approach on many levels.

1. Going around the room is generally an ineffective way to get meaningful feedback. Since this is tedious, people feel the need to keep it short so we can just get it over with. 
2. Nudging people to say something critical about the process sends the wrong message to the team. In my experience, most developers are unlikely to volunteer anything critical for fear of upsetting anyone unnecessarily. It's not about being negative, it's about providing constructive criticism. Also good things can be mentioned and celebrated as well. The ScrumMaster needs to find a format that solicits the correct type of feedback in an engaging and constructive fashion.
3. In this format, you're unlikely to get a good list of improvements to make to your process. I'm pretty lucky these days to come away with one thing that we can change positively next sprint.

It's really not until writing this that I realized I have failed the team tremendously. Retrospective is designed to be a powerful tool for change and improvement to the development procedure. It is supposed to engage the team members to feel as owners of a living & breathing process. Meaningful adjustments should be identified every sprint and attempts should be made to instill these improvements the next time around. Simply going around the room and briefly talking about what transpired is a pretty awful attempt at this and we've been doing it wrong for so long. Ugh.

Coincidentally, I came across this blog post on ScrumAlliance.org about the very topic (written today to boot) where Marc Nazarian lays out a simple yet seemingly effective approach to turn the tables on retrospectives. The idea is to get people to write very succinct feedback onto cards, pass them to other team members who then try to describe the issues written down by their colleagues. This is interactive and serves as an entertaining way to get cross-functional teams to see the process through the eyes of another.

I recommend giving this post a read if you're like me and stuck on a retrospective process which is largely ineffective and tedious.

Thanks Marc!