Memory Lane

Retrospectives are simple, but not easy. The general idea is to get the team together, establish a context, gather relevant data, develop insights, and decide what actions to take. Esther Derby covers the retrospective structure well in a slide presentation on her blog.

Action Items

Retrospectives are about improvement. That improvement comes through action. If we look at the differing retrospective plans on the retrospective wiki, we'll notice that nearly all of them mention action items as an intended outcome of the plan.

Assuming the retrospective went well, the team has agreed action items. Now what?

Benefit, Action, Measurement, Timeframe

Action items are great, but there needs to be more to it. You should be able to answer the following questions:
  • Why are we doing this?
  • What are we doing?
  • How will we know?
  • When will we see the benefits?

If you have agreed action items with no intended benefit and no means to validate the result, I suggest you reconsider the change. Changes always impact the team. Changes most often impact the team in multiple ways, some of which we cannot easily detect. I am not against change. Improvement cannot happen without it. Given our environment and systems are in a constant state of flux, change is necessary. But I do caution against change without purpose and measurement.

With not only action items, but clarity around them, we are ready to introduce Memory Lane.

Memory Lane

The most important agile practice?

As a coach, I've gone into numerous environments with the intention of introducing agile. Of course, I always talk about the values and the principles. Of course, I try to help people to see that there is no one true agile. There's no prescribed set of practices that once followed earn you the agile merit badge.

At the same time, these teams need something concrete. What things can one do in order to set them on the path to "being agile"?

Where do we begin?

There are so many practices to choose from, where does one start?

You could pick something easy and generally unoffensive to anyone on the team and start there. Continuous Integration is often a good place to start when you're looking for something nobody is threatened by. Or perhaps you could identify some of your more troubling areas and try to tackle those. This is more risky, but can give rapid and significant return.

I've seen a lot of coaches take approaches such as these. And I've seen them work well. I've done it myself.

But over the years, I've come to value one agile practice as a solid starting point over all others…

The Retrospective