The unofficial Marie Kondo guide to continuous improvement

What if project debriefs didn’t feel so terrible?

Unless a project was unreservedly successful (probably the least likely ones to be debriefed), they’re greeted with anxiety, fear and that dread you feel being walking into a messy house, knowing you have to clean it up.

It’s easier to live in a mess short term, but soon you lose your keys and your wits.

In work life, it’s easy to understand why teams stick with short, surface debriefs or no debrief at all.

Teams hot off a project are tired from rushing and finishing — they don’t want to see that project again, at least for a while.

Then there’s the pain of a debrief once you get there. People may feel singled out — rightly or wrongly. They may regret their mistakes or fear peers will blame them for group failings.

Some may fear the conflict inherent in squaring multiple views of how the project went. Digging through mounds of results, processes and bills can be exhausting.

With so many barriers in place, it’s easy for a team to question if a debrief is meaningful, worth the time.

So let’s focus on making them meaningful.

Marie Kondo has neither seen nor endorsed this article, but I’ll borrow on an aspect of her KonMari global minimalism evangelism nonetheless. For those who haven’t watched or read her properties, Kondo encourages people to clean up their spaces using their intuition and feelings.

First, she asks people to regroup their stuff in categories, ignoring where they lay in a mess. As though physical items had souls, she asks you to pick them up and decide if they give you a sense of joy or meaning. If they do, make room for them. If they don’t, it’s time to let go.

This practice stands against a typical room-by-room or little-by-little approach, which leads to a cycle of constant tidying that never leaves a place feeling all that tidy.

Retrospectives, as practiced in scrum methodology, consider personal meaning when trying to learn lessons after development projects.

After a team completes a project, they’re asked to bring artifacts of the project process that feel important to them. They share the story of those artifacts, and they’re then combined and used to form a project timeline. This becomes the basis for the typical conversation: what went well, what didn’t, what would we do differently.

Compare this to a less heartfelt debrief.

In a boardroom, there’s a big chart on the wall, neatly printed with all the performance indicators, meetings, deadlines, documents, approvals — the whole critical path, perhaps. The team must consider the entire process in scope. The group picks a couple of unnecessary things, a deadline that should have been moved up. If it was a particularly tough project, people lament that they probably need an entirely different process, strike a working group, and head off.

Or perhaps you’ve been part of a far less formal debrief — an hour around a board table with nothing to reflect and consider. Finally breaching the silence, the senior manager delivers a few remarks on how hard the team worked, all the hours they invested. More silence begs the inevitable question — what didn’t go well? One of the firecrackers in the room unloads the same concern they’ve been harbouring forever. That idea’s put in the parking lot because it’s too big to address at today’s meeting. Others raise a few safe points — they could have used more time here, a quicker decision there.

Neither scenario encourages people to share anything risky. The first assumes everyone’s working off the same version of the truth, and the latter avoids establishing any fact to avoid confrontation. Not all events are meaningful, but some are, and your debrief must include them to be successful.

Embracing subjectivity — people’s personal view of what’s meaningful — helps you strike a balance.

Unless you’re doing a full root cause analysis of a significant system failure, your team will most likely surface the key lessons through sharing the artifacts that stuck with their memory. They’ve subconsciously sorted what’s essential from what’s not, helping you focus on the pieces of the project that need the attention.

Personal stories are vital to giving the team meaningful lessons to take away. You’ll discuss those opportunities for change found in the artifact timeline, but you’ll wrap up with people sharing their self-assessment — what went well, what didn’t and what they’ll do differently. No commentary or criticism allowed.

You might invite other team members to share what they learned from others’ stories and artifacts that they’ll take away for themselves. Either approach helps create a safe environment where people are more likely to share what happened, knowing they won’t be subjected to critique and that their story has helped others learn as well.

Including meaning in your debrief is especially crucial for teams whose project processes aren’t as repeatable as they are in software. You may never use the same method again, so taking the critical path approach helps you look backward, not forward. The team and its people will endure into the next project, though, thus making a debrief personal gives you the best shot at learning that will help you in the future.