How We Do a Retrospective

There is no one right way to do a retrospective, there are many good techniques...and a few bad ones. Utilizing more than one technique is a good way to get different conversations going with your team, and expose different areas that could use a little fixin'. That said, I do have a "tried and true" technique that we've used on a number of teams over the years. It's usually pretty good at getting the conversation going, and can be done in 30 minutes or less to keep you from being stuck in "yet another meeting."

First things first, at the start of any retrospective you should review the action items or results from the previous iteration's retrospective. Have the people assigned to each item report how it went and what got accomplished. Nothing gets a retro off to a good start like saying, "Remember that problem we had last week? It's fixed!"

A Few Supplies and a Little Preparation

We're going to need:

1. Three colors of sticky notes. Regular square ones will work fine. For this example we're going to use purple, yellow, and green.
2. A box of pens, preferably all the same kind. I like to use sharpies because big pens on small paper ensures we get short items on each card rather than essays. Using the same pen also keeps things a little more anonymous.
3. A whiteboard. In the absence of a whiteboard the big easel sheets would do the trick.
4. A timer of some kind. I picked a timer up for about $200...it also makes phone calls, surfs the web, plays Angry Birds and sends text messages and email. It's high end for a timer, but it does the trick.

For the prep work, take our three colors of sticky notes and split them up so each member of the team has a few of each color. The number really doesn't matter, but we usually end up with 6 to 8 of each color for each person. Give each member of the team their own little pile of sticky notes and a sharpie.

Gather The Data

The colors signify good, bad, and confusing items from the previous iteration. Since we went with purple, yellow, and green we'll say that purple = pain, yellow = confusing, and green = good. Set the timer for 5 minutes and have the team write as many items as they can think of for each color from the previous iteration. They should do this on their own, writing their own thoughts down, we'll collaborate and discuss later. If your team is smaller and iterations are pretty short, put less than 5 minutes on the clock.

When the time is up, have each team member walk to the white board and stick their notes on the board. No order to them, just get them on the wall. Once all the stickies are on the wall, take a couple of volunteers to group them by subject, not by color. We're not looking for all the bad things that happened in one cluster, we're after what was good and bad about a given subject to the team. Aim for 4 to 8 categories, and try not to get them too broad. Once you have your categories, circle them and put a one or two word title above the cluster. It should look something like this...

Discuss

We've got things broken down, next up we have to decide what we're going to tackle. Best way to do this is to Dot Vote. Dot voting is an old stand by in agile. Each team member gets 2 or 3 votes and they place a dot next to the category they want to discuss. If they think a category is very important they could put all three of their dots next to that category. We do want each team member to use their votes though, abstaining isn't allowed.

When everybody has voted we'll discuss the top two vote getters and try to pull an action item or two out of each category. Do a quick run through of each sticky, set the timer at 10 to 15 minutes, and get to discussing. Try to involve everybody in the discussion as well. Since everybody contributed to the stickies on the wall it should be easy to get the quieter folks to speak up as they likely added a note to the category.

What Are the Goals Here?

Goal numero uno in this set up is to get everybody to put stickies on the wall with what they thought went good or bad or confused them during the last iteration. By doing this we have everybody involved in the retrospective right away, and increases the likelihood of them speaking up during the discussion.

The second thing we're after is discussing categories of issues rather than smaller issues raised by one person. The goal of any retrospective is to look back and see what we can do to make the whole team better, not just what the loudest, type A personality, Alpha-Dev wants fixed to make his life better. By categorizing everybody's issues we can compare what everybody thinks, discuss the broader issue, and derive a good actionable, assignable action item from that.

Some Issues: Learn From My Mistakes

Doing this, or any, retrospective style 6 or 8 or 10 retrospectives in a row will stop yielding good results. That happened with one of my teams and we kind of got in a rut. Once in that rut the retrospective became an "Airing of Grievances" (minus the festivus pole) and we weren't getting good action items. In reality, we were getting bad attitudes towards the retrospective and incremental change was not coming our way.

One particular retrospective we had done the categorizing and completed our voting and a sticky note from one member of the team had not made it into a category we were going to discuss. In order to get it discussed, the owner of the sticky moved it into a category we were going to talk about. It was posed to the team if we should leave it, and the consensus was it wasn't there for the voting, it shouldn't go in now. The offender wasn't too happy with this decision and slapped it back in to be discussed...at which time one of us removed it, tore it up, and threw it away. Team over individual in the retro. Always.

As noted earlier, and solidified with my first issue above, this isn't the only way to do a retrospective and it shouldn't be used iteration after iteration. However, it does get the conversation going and it will usually yield an item or two that your team wants out of its way. Give it a shot the next time you have a retrospective.

Action Items Round Two

In my last post I discussed keeping your action items assignable and actionable. In the days since that post went out, I've seen a few more things to add to the subject of action items. We're agile, we're all about continuous improvement.

Action Items Are To Improve Team Workflow

Action items are things the team agrees to try in their next iteration to improve a process which is giving them trouble. In otherwords the team has identified a problem in how they're getting their work done and the action item they've decided on should help fix that problem. Some examples of action items I've seen on team boards in the past...

1. Add Work In Progress limits to our scrum board.
2. Make our Product Owner the single point of contact for our field engineers to limit the context switching of developers.
3. Add a large, red light outside our team area to let the rest of the office know that the team is in heads down "quiet time" and shan't be interrupted.
4. Try planning poker at our next planning meeting.

If the item would go straight to the value stream of your project, meaning it's something you are going to work on that will apply directly to your deliverable, then I usually don't classify it as an action item. Things that gostraight to your deliverable are typically specific features, setting up hardware, and technical spikes. (More on those in a sec.)

Not every retrospective will yield action items and that's OK. If you're doing short iterations and are humming right along, you may have a very short retrospective and be pretty happy with how everything went. There's nothing wrong with NOT having a problem on your team.

Technical Spikes

Spikes are meant to answer a question and should be time boxed. This stems from a couple things we as developers are very good at: Taking too long to come up with an answer and going off in the weeds, down a number of tangents and returning with what we think is the absolute perfect solution. Enter the technical spike. Limit our off in the weeds time, give us a definite end time, and force us to come up with A solution prior to coding it into the PERFECT solution.

Why don't I think spikes are action items? Because in the long run they should be answering a question about something that will likely go straight to the value stream of the project. Usually we're answering a question about some portion of code that's new to us, a framework we haven't used before, or something along those lines. These questions need to be answered for us to deliver our product, not necessarily to improve the team, its process and its flow. (Though not delivering our product will most decidedly have a negative impact on the team.)

An an example of what I mean, I have a spike assigned to me right now to look into a GUI testing framework for our project. This is clearly a question for us, and not something that I need to do to improve the next iteration and beyond. It's something that will provide direct value to our client.

So, let's say I finish my spike and settle on Selenium as our GUI testing framework of choice. After three or four iterations we see that our selenium tests are getting quite large and out of hand, at that point the team would probably identify an action item to clean those tests up. (And we would of course assign a steward to oversee that clean up.)

The Working Agreement

In my last post I got a very good comment from Fanlan:

At my company, we distinguish between tasks (Action items) and working agreements. "We will do a peer (code) review when we think we have finished a user story" is an example of a working agreement.

Many of the teams I've been on we haven't been too explicit with our working agreements, though I think that's a mistake on our part as I do like being more explicit about team workings. Leaving things open for interpretation rarely goes the way you wanted it interpreted, so I do like Fanlan's suggestion here.

In my example our team was going to try out code reviews and added them as an action item for the next iteration. In that context we don't know if code reviews will work for us or not, so we're going to run with incremental change and see how it goes. In another example we may want to add WIP limits to our team board, but after a couple of iterations they may not change our flow. If all goes well with our action items then I'd add the new practices explicitly to that working agreement for the team, but we should go through the "try before we buy" period before full adoption by the team.

Incremental change is a big deal in making your teams and your deliverables go better. Work at those retrospectives and their resulting action items, you'll see those improvements start to take hold.

Action Items: The Results of the Retrospective

One of the principles of agile is incremental change. Looking inward on what your team is doing that could be better is one way to get that incremental change, and team retrospectives are a great way to do that looking inward. If you're not familiar with team retrospectives, essentially they're a fairly informal gathering where teams bring up issues and kudos over recent work and decide on a few things that they want to improve. The things they decide to improve are usually called Action Items.

Having been on a few agile teams and taken place in many a retrospective there are a couple of things that come to mind in regards to action items.

Make Your Action Items Actionable

Ok, that sounds a little on the obvious side, and it can be. But it's a very real problem with many action items.

A team gathers and they find an issue with their code. For example our team is working on a large, old code base. There are many pieces of it that are just scary to change. So the team brings this up at the retrospective. Many people have issues on the board such as, "code is scary to change." Or something like "our code is difficult to work with." And since it's a dev team somebody has probably taken a little initiative and just put, "Code SUCKS!" up on the board. After some discussion the team has decided on an action item of: Improve the Code.

The whole team is there, managers, product owners, QA folks, everybody, and they settle on "Improve the Code" with some gusto. This is an item we KNOW we need to do and the whole team is behind it. If we're going to succeed, we need to IMPROVE THE CODE!

But our (somewhat) hypothetical team has missed the important part of this action item: HOW do we improve the code? Just saying "improve the code" is the dev team equivalent of saying, "Well, duh." We're always striving to improve the code, but what's that first step? Make sure your action items are indeed items and not overall team goals.

Drag the discussion a bit further. Start asking questions when you settle on a broad action item such as this. If you start digging, you'll arrive at that first step to your bigger goal. For example, our team notices that they have a small seam in their code where they could get their data layer wrapped in an adapter and add some more testability to both sides of that data layer. Now they have an actionable action item: Wrap Data Layer in an Adapter.

Make Your Action Items Assignable

The next retrospective comes around, and we working hard at getting actionable action items. After some discussion, we realize that we could use a quick code review before we move our features to "development complete." Performing a code review is pretty actionable, and everybody on the team can participate. Our team is happy with this action item and they decide to tackle it the next iteration. They've also decided to assign it to "Everybody."

So they just assigned it to nobody.

It's human nature, if everybody is assigned to a team task to complete of their own free will, nobody will take care of it. Code reviews will likely not happen, and we'll arrive at the next retrospective with everybody looking at each other thinking, "I thought somebody else would take the lead on that."

Even if your action item probably does need to be done by everybody on the team, as would be the case with our code review example here, assign it to one person to oversee that it actually happens in the iteration. Make that person a steward of the action item. This person likely needs to do nothing more than bring up at the first stand up to remember our code reviews, then later volunteer to do the first one and the ball will be rolling. Additionally, at the next retrospective the team has a person that is accountable to report back on the results of that action item from the previous iteration.

Retrospectives are great tools, possibly the greatest tool for incremental change. Keep an eye on those action items and keep them actionable and assignable.

Upcoming Speaking Events

Trying to slow down the speaking and associated travel schedule this year, but not giving up on it entirely. So, here's what I've got coming around the corner...

Stir Trek

On May 6th, Stir Trek happens again. This has quickly grown into one of the region's more popular conferences, and it's only a one day thing. I'll be presenting "Executable Requirements: Testing in the Language of the Business" in the Testing Track there this year. There's something cool about seeing your slides on a movie screen. There's also something daunting about following Jim Weirich on the schedule...

Columbus Ruby Brigade

On May 16th I'll be presenting at the Columbus Ruby Brigade. It's not directly a Ruby topic, but the good folks at CRB have been kind enough to give me an hour to present "The What's, Why's, and How's of Kanban." So, it's not specifically for the Rubyists, but Kanban is good for everybody! If you're thinking, "Really? The Kanban talk AGAIN??" Yes, again, because I need the practice for...

Agile Dev Practices

June 9th I have the honor to be on stage at Agile Dev Practices West, again presenting "The What's, Why's, and How's of Kanban." Yes, more of Tim yammering on and on (and on and on) about Kanban and how it will cure all that ails you, but this time I get to do that yammering in Vegas! I am really looking forward to this conference and the crowd that will be different from the normal developer type crowd at most of the conferences I attend.

LSSC Video of My Kanban Experience Report

Back in April I was selected to give a Kanban experience report at Lean Software Systems Consortium in Atlanta, and as luck would have it InfoQ had set up a camera in the room I was presenting in. Yesterday, they posted it online: http://www.infoq.com/presentations/Moving-to-Kanban

This was the first time I was recorded giving a presentation, so it's the first time I've seen myself give a presentation. And I must say, I am one of the presenters I've ever seen! OK, maybe not, but it wasn't as embarrassing to watch myself as I thought it would be. Seeing myself at least let me see some things I can improve on. (Dear Lord, Tim...STAND STILL for a second.)

And while I'm throwing some video out, Dave Giard recorded a video interview with me back at Codemash this past January. I finally got around to watching that one, too. For Dave's beer being off screen on one side and my bourbon off screen on the other side, it went pretty well.

Dave's Technology and Friends, Episode 71: http://technologyandfriends.com/archive/2010/02/15/tf0071.aspx

 

 

Upcoming Speaking Events

As is normal for me this time of year, I’ve got a number of events that I’m attending to do a little speaking and a little learning. This round will take me to three states, but only one time zone (thank goodness).

Indy Tech Fest, May 22

I’ll be presenting on Lean Software Practices. We’ll go through the seven principles of Lean Software Development, and I’ll present some experiences with each as I’ve practiced Lean over the last few years.

Indy Tech Fest might not be too familiar to us here in central Ohio, because it’s outside our MS region. (gasp) But, the folks in Indy do a bang up job with their events, and they have a large, active .Net community. This is my second year venturing west to join the folks at Indy, and it was a great time last year.

The Path to Agility, May 27

This is the first Path to Agility conference, and it’s being put on by the Central Ohio Agile Alliance at the Arena Grand theater in the Arena District of downtown Columbus. They’re bringing in Ken Schwaber to keynote the event, so I am most decidedly on the undercard.

I’ll be presenting my Kanban experiences over the last few years. It’ll introduce Kanban and how to use it to deliver software. I’ll relay the good experiences and the bad experiences.

There is quite a line up for this conference, and there’s still space available. If you can get a Thursday off work, it’ll well worth the $100 to attend. There are some top notch local agile people presenting. (The Clippers are at home that night, stick around for some baseball.)

Central Ohio Day of .Net, June 5

The “home” event. Can’t miss this one, it’s a great time every year.  Getting the Cincy, Dayton, and Columbus folks under the same roof has made for a great event the last two years.

I’ve been selected to give two talks this year. Upside, I’m giving two talks. Downside, it’ll cut into my hallway sessions.

The schedule isn’t out yet, so I don’t know which session fits where. I’m presenting a beginning IronRuby talk, where we’ll get it installed, bang out some ruby code, hit a few CLR objects, and possibly take a few whacks at a piñata to bring the fun level down a little. The second talk will be the same Lean presentation I’m giving in Indy.

Codestock, June 25-26

My second trip to Knoxville to get in on Codestock. This is a great event. It’s got .Net roots, but offers quite a bit outside the normal .Net conference sessions. There are a lot of choices to make on what to attend over the two days. They did move to downtown Knoxville this year, so I’m looking forward to the new venue.

I’m speaking twice here, as well. I’ll deliver a Kanban talk, and an IronRuby talk. The IronRuby talk is going to go a bit deeper on testing than the one I’m giving at CODODN.

An added benefit to Codestock is Wendy and the boys go along, and we turn it into a mini-vacation. So, I’ll get a little pool time in, which usually doesn’t happen at conferences not named “Codemash.”

Ohio User Group Tour, July 22, 27, 28

We’re going to IronRuby it up at the Columbus, Cincinnati, and Dayton user groups in July. This talk is going to go into testing our C# code with IronRuby, and what advantages there are to this. The reason the CODODN talk is the beginning talk is because I was scheduled talk for these user groups back in December. Since it’s roughly the same crowd, we’ll do the intro at Day of .Net and dive into the testing at the local user groups.

Expect to see some RSpec running against C#, Rails running on IronRuby, Sinatra running on IronRuby, and mabye we’ll get crazy and put a Rails front end on an nHibernate repository or something. All hell’s gonna break loose during this one!

If I survive all this, I’ll have like 3 weeks of summer to kick back and relax…

Lean Conference Recap

Last week I was an attendee and a speaker at the Lean Software and Systems Conference. It was three days of lean, kanban, and flow; and it really got the wheels turning on a few things.

Off the top, a quick warning: If you are a restaurant owner and you don’t usually set up a buffet line in your restaurant, pray that Mary Poppendieck is not among the first few patrons to your new set up. This situation happened at the speaker lunch, and as 50+ lean thought leaders (and me) lined up, Mary came out with, “You would think a restaurant with a buffet line would understand queuing theory!”

Overall, the conference was very interesting. It wasn’t the normal dev conference I’m used to attending. The audience was comprised of project managers and team leads much more so than it was of developers and engineers. It made for a much different dynamic…and dress code. A lot more khakis and golf shirts than cargo shorts and Star Wars t-shirts.

The sessions were pretty good, but this was year two for this conference. That combined with the relative newness of the whole lean software movement led to some overlap in session content. Not saying that’s a bad thing overall, just the nature of the situation.

As with any conference, the hallway sessions add to the whole situation. I saw a few familiar faces and met quite a few new folks, including three guys who had flown over from Sweden for the conference. (And got past the volcano that wreaked havoc on the speaker schedule all three days.)

The only real downer for me was I didn’t get to visit open spaces. I was opposite the open spaces on Friday, so I was preparing to speak or speaking during the first part of the morning. After that, we were tearing down the booth and getting to the airport for our flight home. Would have liked to have seen what came out of those open spaces.

I thought my own session went pretty well. I did 45 minutes of a kanban experience report, and got a few questions near the end. The room was pretty big, so it didn’t lend itself too well to creating the discussion this topic has for me in the past. But, I was video taped for the first time in my short speaking career, so when that link comes out I’ll be sure to pass it around. (After reviewing it to make sure my hair looks ok.)

It looks like next year is slated to be in LA. I’ll submit a topic again, but even if I’m not selected to speak I may have to attend. This isn’t a CodeMash I must-attend-as-long-as-I-have-a-pulse type situation, but more to see how this conference matures and drives lean and kanban forward.