In war, you need to have a reason for every action. One misstep, and you put your entire squad in danger.

That's why the U.S. Army treats every training exercise like the real thing—to the extent that they conduct performance critiques after every activity. Team leaders are tasked with planning an exercise retrospective, which focuses on dialogue and participation from everyone involved.

But their process for unpacking a drill wasn't always so inclusive. According the The Oxford Handbook of Military Psychology, the U.S. Army's retrospectives used to be lecture-based, absent of any back-and-forth with the soldiers who actually participated. As you might expect, they didn't learn much.

After studying the process in the early 1970s, the U.S. Army switched from this talk-at-you approach to a talk-with-you approach called after-action reviews (or AARs). These reviews encourage participation, and occur immediately after each mission, project or critical activity. They revolve around four basic questions:

• What did we plan to do?

• What actually happened?

• Why did it happen?

• What do we do next time?

With AARs, soldiers went from passive listeners to active participants, discussing the timeline of events and where they could improve. The atmosphere transformed into a safe space where suggestions were welcome. And, most importantly, AARs actually promoted learning.

Your team likely isn't thrust into harm's way on a regular basis, but maximizing the benefit of every action is still crucial to your project's success. Here's how teams at SalesforceIQ, Asana, and more use project postmortems and retrospectives to learn from every task.

How to Run an Effective Postmortem

1. What are Postmortems and Retrospectives?

2. What Postmortems and Retrospectives Are Not

3. Strategies for Running a Successful Postmortem or Retrospective

4. Apps that Help You Collaborate on Postmortems

What are Postmortems and Retrospectives?

The U.S. Army is far from the only group that tries to learn from its exercises. Around the globe, businesses and organizations have their own AAR-like processes for digging into how they can improve their processes next time around.

These meetings go by various names, but two of the most popular are:

• Postmortems, which are meetings that happen after a project is finished or "pronounced dead." The name comes from the surgery used to find the causes of someone's death.

• Retrospectives, or "retros," which are regular meetings during an ongoing project that reflect on the past few weeks. They're a common part of the Agile project management strategy, and the name that literally means "to look back on past events."

Plans for running a retrospective and tools for pulling the results together vary widely depending on each team’s needs. Asana, for example, prefers Toyota’s well-known 5 Whys technique, which keeps participants asking "Why?" until they understand the root of a problem. Other teams use structures like "mad, sad, glad" where they categorize items for discussion based on feelings, or the "4Ls," where team members list things they liked, learned, lacked or longed for.

No matter what you call them, these types of "lessons-learned" meetings all share similar goals: identify and celebrate what’s working, then come up with a plan to fix what’s not working.

When you do them right, retrospectives result in a culture of learning, sharing, and constant improvement. Teams get the autonomy to create happier, healthier, and more productive working lives for themselves. And as a result, they build a more successful organization.

What Postmortems and Retrospectives Are Not

Although methods vary from team to team, there are a few things postmortems and retrospectives should never be:

1. Cheap talk

If a team can’t convert what they learn to action, then they’re just talking in circles and wasting time.

Lack of ownership can lead to items falling through the cracks or sitting in a dusty backlog indefinitely.

Jessica Barnett, product manager for About.com, tries to focus on finding actionable takeaways, so her team can build a process that they believe in. "If you don't actually improve or change the process, you’re going have a room full of people who don’t buy into the process anymore."

2. Gripe sessions

Everyone needs to vent sometimes. The key is to ensure that discussions—no matter how emotionally charged—lead to improvement.

It's not about complaining, Barnett says. "It’s about fixing things. There’s no team that thinks ‘I love absolutely everything about everything.’ That doesn’t happen. But your team should feel like they’re actively improving the way that they work."

3. Blame games

If someone is worried they’ll be punished or reprimanded for a mistake, they’re less likely to own up to that mistake or explain how it happened. But if you don't fix a pitfall, you're likely to tumble into it again.

Scott Bessler, chief architect for SalesforceIQ, says blame can be a big obstacle to productivity. "I’ve seen retros dissolve into ‘Why didn’t this task get done?’ and engineers feel a little blamed or feel like they have to answer to that," he says "It can make everybody feel unproductive."

Instead, teams should focus on using that time to grow. "That’s something that I think has worked really well for us," Bessler says. "When teams are trying things out, we give them the freedom to do that."

Blamelessness is also crucial to the success of the 5 Whys, a method that head engineer Malcolm Handley relies on at Asana.

To get to the root of a problem, it’s important to understand the timeline of events that occurred, and who did what. If someone is hesitant to admit they made a mistake, that makes learning difficult.

"Maybe I’m saying you did something wrong, but it only happens to be you; it could have been any of us," Handley says. "It just means our tools or our processes failed us."

Strategies for Running a Successful Postmortem or Retrospective

Every team has a postmortem or retrospective meeting format that works best for them. In general, though, effective retros or postmortems share these characteristics and steps.

1. Plan ahead

Try to plan for the meeting to take place soon after an issue occurred or a sprint is complete. Asana teams, for example, try to hold a 5 Ways meeting two to three days after a problem is discovered.

Knowing when you'll run the retrospective beforehand helps teams plan ahead and avoid wasting meeting time.

Asana's teams spend time before the meeting piecing together the timeline of events for the issue they’re discussing, along with any other relevant information. Team members make sure to look at meeting notes beforehand so they come prepared. This helps the team avoid speculation during the meeting, and allows them to get to the root cause of an issue faster.

When Barnett worked for healthcare startup Medivo, they used Trello to keep track of each retro. Whenever someone noticed something that needed addressed in the next retro, they posted it to Campfire and an automation added it to a new card in Trello.

By the time the retro rolled around, team members had already documented their discussion items, so nothing fell through the cracks.

2. Set the right tone

Set expectations for actions and attitudes. It never hurts to emphasize blamelessness, especially if your meeting will include people who are new to the process.

Colorado-based user experience design agency Slice of Lime lightens the mood before retrospectives with their clients with an energizer or game.

"We do a team activity to loosen everybody up first—anything that gets you up and out of your chair and acting goofy," says Erica Birkman, a senior UX designer at Slice of Lime. Birkman says a game is helpful to alleviate any tension before diving into a discussion.

3. Get the right facilitator

A great facilitator or conversation leader can help guide a team toward action.

"For us it’s often someone who’s been around for a while and has enough context on the problem that they can help guide the group to more meaty areas," Handley says.

It helps if the conversation leader in a retrospective meeting isn’t so directly involved, because they’re the person taking notes, and it should also be someone who can make sure everyone is giving input. "You need to have a lot of voices to make a good process," Barnett says. "You should make sure everyone is involved and speaking."

The right facilitator might be someone on the team or outside the team, depending on the type of team and the topics up for discussion. All that matters is that they're neutral and good at keeping the conversation flowing and friendly.

4. Convert information to action

Above all, you should make sure your discussions lead to actual change.

Start by having a system for recording what’s discussed and prioritizing issues that come up.

"If you don’t have things written down, it can be hard to follow up on action items," Barnett says. That's why the Medivo team used Trello to keep track of retros from start to finish.

"One thing I like about Trello is that it’s a seamless process," Barnett says. "Cards come into Trello, and you use that as your place to talk about them and follow up with them." At the beginning of each retro, her team would discuss the action items from the previous retro to keep everyone in the loop, check on progress and make sure items were resolved.

Next, assign an owner for each action item. It might seem obvious, but ownership means that someone is responsible for shepherding this change to the finish line.

At SalesforceIQ, the expected output from postmortems is a timeline and list of action items separated into three buckets. "We sort items into things we should do now and things we should do soon, within next month or so," Bessler says. "Then there are ‘nice-to-haves’ that we want to get onto a backlog somewhere, but we don’t want to spend the time on them right now." Items in the first two buckets are assigned an owner who is responsible for making sure they get done.

The 5 Whys method involves responding proportionally to each action item, which can help make change seem a lot more achievable. If a problem isn’t causing big issues for the team, it probably won’t make sense to dedicate a time and resources to a fix.

That's what Asana's development team learned through their postmortems. "We had a problem where if someone was pushing code from beta to our production branch while someone else was making changes, Git would sometimes merge these two changes in ways we didn’t expect," Handley says.

One small change fixed the issue. They added an extra flag in Git that only allowed the merge to run if everything in the production branch was already in the beta branch. "That’s something small at a level of proportionate response," Handley says. And the change came from an actionable to-do after a postmortem.

5. Share what you learn

Your team should walk out of retrospective meetings with a clear idea of what they learned, and what the next steps are. Then, they should share those lessons. "Get that knowledge out to other people," Barnett says. "Don’t just let it die in some doc somewhere. Get it on paper, circulate it out to other teams, even try to write a blog post about it."

SalesforceIQ shares every post-mortem company-wide. "We share every post-mortem with the entire company in a Google Doc through email, with action items so people can see what we’re coming up with," Bessler says.

Once a month, Slice of Lime holds a company-wide retro where they go over internal items, including things they want to celebrate. "These are similar to our client retros, but we have one extra column for amazing experiences we had or that we created for clients," Birkman says. "We recently got this amazing email from the client talking about how we helped their team grow, learn UX and gain passion for what they’re doing, so I added that to our amazing column."

When Asana teams finish the 5 Whys process, most teams share links to that specific 5 Whys project in Asana. "We figure out the audiences that are relevant to learn from the discussion," Handley says. "In some cases, if we think it’s more important than that, we’ll wait until the next engineering all-hands meeting, and someone will describe what happened and what we learned."

Apps that Help You Collaborate on Postmortems

There are number of different tools to help you collaborate with teams and run retrospective-type meetings. A powerful tool can save time, keep you organized and help make sure tasks get completed, especially if you have remote team members.

These collaborative platforms help teams brainstorm, prioritize, make decisions and assign and track action items:

If you don't need a dedicated postmortem tool, you could use Evernote to keep notes about your projects, or a Google Docs or Quip document to create a report document. The important thing is that you write down your team's thoughts, and turn them into actionable tasks that will help your next projects be more successful.

Philosopher George Santayana once wrote, "Those who cannot remember the past are condemned to repeat it."

But to be successful, it’s not enough to just remember the past. We need to be able to understand why something happened and change the way we work because of that new knowledge.

Remember: Small changes add up to big improvements over time.

Further reading

• Agile Retrospectives: Making Good Teams Great

• Blameless post mortems

• Ask 5 Whys to get to the root of any problem

• The 5 Whys for startups

Credits: Pointing image courtesy Daniel Horacio Agostini; Meeting photo courtesy JD Hancock.