Home > Management and Careers

Computerworld - Project management experts like to tout the benefits of conducting postmortem reviews to determine whether projects met their goals and to learn lessons that can be applied to future efforts.

Although postmortems are useful, they don’t enable project teams to identify and correct problems during a project. To get at problems in real time, Esther Derby and Diana Larsen advocate periodic reviews between project iterations.

In their recently published book, Agile Retrospectives (The Pragmatic Bookshelf, $29.95), Derby, principal at Esther Derby Associates Inc. in Minneapolis, and Larsen, a partner at FutureWorks Consulting LLC in Portland, Ore., say that real-time retrospectives provide technology benefits like catching software defects quickly, as well as management benefits like preventing friction among members of a team. They recently discussed the approach with Computerworld’s Thomas Hoffman.

What are the biggest benefits of agile retrospectives?

Derby: Agile retrospectives help teams deal with conflict before it becomes a blowup. That ability to address conflict results in creating a sense of trust between the team members and provides them the ability to handle conflicts when they come up.

Many IT managers say they lack the time for postmortems. How can they be persuaded to try ongoing evaluations?

Larsen: As a place to start, emphasize that this is an important part of the continuous process improvement effort for software development. Most organizations and managers have bought into the notion that continuous process improvement is important. When you conduct retrospectives, you have a way of improving lots of things: methods, teamwork and processes, which work together toward improving productivity.

Naysayers will argue that conducting retrospectives during the course of a project will lengthen it unnecessarily or tie up resources.

Larsen: Scrum [an agile software development methodology] uses the term “inspect and adapt” — this idea that we’re continually looking at what we’re doing and adjusting it so it makes sense. The beauty of this is that you may approach a team and ask, “Can we try a retrospective just for the next iteration? We’re not making wholesale changes for the length of the project, just this one time.” That’s such a low threshold of investment by the team that they’ll say, “OK, we’ll give you an hour or a half-hour.”

It segues so nicely into planning the next iteration and reduces the amount of time you need for planning. That approach makes this a low threshold for risk and makes it an easier sell job than a postmortem at the end of a project where you’re committing two or three days of time.

Derby: I sometimes ask people this question: If you knew at the beginning of the week what you know now, how much time could you have saved? If you go back and look at [the past week], you can find some ways to save yourself time.

Avoiding the Do-nothing Retrospective

Teams who identify external groups as the source of their ills and want those people to change end up frustrated. Waiting for other people to change is an exercise in futility. The most powerful place to start change is within the team. Even when your team doesn't have direct control, your team can take action to influence or change their own response. Change happens in the course of normal work. Teams who believe their retrospectives are a waste of time often keep their improvement plans completely separate from their daily work plans. When the plans are separate, no one finds time to do the "extra" work. This excerpt from Agile Retrospectives, by Esther Derby and Diana Larsen, is published with the permission of the publisher, The Pragmatic Programmers LLC.

Your book stresses that team members should explore their feelings during a project. Why is there so much emphasis on this?

Derby: Engineers try to avoid the “F word” — feelings — when they’re working with each other. But if you don’t bring this up in some way, then people won’t talk about the things that are truly important to them. When you leave that out, you get a very sterile analysis.

Larsen: When people communicate on a team, there’s more than just rational thinking going on. To ignore that is to ignore a big piece of what’s going on.

Derby: Ask members of the team, “What’s going to have the biggest impact on us?” or “What will we have the most energy to work on?” I’ve seen teams where they’ve ID’d the most important things to work on, but if they’re not emotionally invested or they don’t have the energy to work on it, it’s not going to go well. There’s more and more research that says that people don’t decide things rationally. It’s all emotionally decided, and we rationalize it later.

What are some common misconceptions that people have the first time they try a retrospective?

Larsen: It tends to fall into two buckets. They overestimate what can be accomplished in a one-iteration retrospective, or they severely underestimate what can be accomplished. I have bumped into people who believe they can turn around everything that’s wrong in an organization in a one-hour retrospective, and that’s way overestimating what’s possible. It’s key to set an appropriate goal.

Derby: If you can solve one problem a week, you go a long way toward solving a lot of problems.

Do agile retrospectives negate the need for postmortems?

Derby: I think you learn different things at different points. In agile retrospectives, you look at issues that occurred during a particular iteration. After a release, you might look at other things.

Read more about Management and Careers in Computerworld's Management and Careers Topic Center.