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.