Week Notes: Vol. 3 – № 5

How UX can guide retros for better team conversations

Most teams run retrospectives (if they do at all) the same way because it’s familiar, not because it’s effective.

When retros start to turn stale, I’ve found it's often one ceremony product managers are happy to offload to others.

From my experience working across UX and product, a few small changes to retro format and facilitation can surface very different problems and quickly unlock better conversations.

I get it. Agile in practice can be very performative. There’s a reason why “Agile Theater” has become a handy catchphrase.

Half-hearted transformations. Constant reorganization. Limited (or nonexistent) psychological safety.

It’s easier for organizations to mime their way through the ceremonies in the name of “Agile” than embrace the mindset.

But there’s something about retrospectives at the end of a sprint that I love.

They’re proof that asking the right questions helps people name what’s really getting in the way, including things that might not be problems yet.

Not every issue falls under “not going well.” Sometimes, by then, what could have been raised as a concern has escalated to a full-blown problem.

So what are other ways you can ask this question?

Sailboat: Anchors & Rocks

What held us back? (Anchors)

Maybe someone got stuck on an issue and tried to power through instead of asking for help. That’s hard to bucket under “not going well.”

Wanting to learn is good. But persistence can be expensive. As much as someone needs to recognize when they’re stuck, the team needs to offer support.

Also, maybe half the team was out sick or on vacation. Or a critical bug needed attention.

Those things will clearly slow progress, and documenting them can help if you’re asked why your velocity took a dip.

What do we need to watch out for? (Rocks)

As much as we try to identify dependencies at the start of a project, we don’t know what we don’t know until we’re in the work.

Regularly looking forward helps the team identify risks and blockers that need to be communicated to other teams, departments, or leaders.

As John Mayer says, “Bad news never had good timing.” But calling it out early can avoid a crisis.

Three Little Pigs: Straw & Sticks

What is weak & could fall apart? (Straw)

Assumptions, shortcuts, and verbal agreements are real risks that make temporary solutions flimsy. They may have provided a bit of direction, but data and research are likely needed next sprint.

Spikes. Testing. Stakeholder feedback. Don’t forget to make that part of the plan.

Knowing what needs more work will help you prioritize the backlog or upcoming sprint commitments.

What is sturdy but needs more work? (Sticks)

This question really captures everything in the gray areas. There might be work the team is happy to have done, but that doesn’t mean it’s bulletproof.

Just like when our parents said “maybe” when we asked if we could go to Chuck-E-Cheese next weekend, we know what “low-priority” or “not urgent” really mean.

Some things might truly be good enough. But don’t let quality, or the team’s credibility, fall victim to “we’ll fix it in Phase 2.”

People aren’t always kind to their future selves. So document improvements, and discuss as a team how to proceed during refinement or the next retrospective.

Rose, Bud, Thorn: Buds & Thorns

What can we improve? (Buds)

Traditionally, “buds” are things we need to nurture so they blossom. But what do we need in order to do that? Or what if some of those buds are weeds?

As a facilitator, you may need to do some extra prompting to get people thinking differently.

If the team is putting in work to improve, tending to the garden is just as important as tilling and planting.

What are some pain points? (Thorns)

Thorns can be very obvious or very personal.

You’re using “thorns” as a metaphor, which means it invites your team to consider a wide range of possibilities.

The trick with this question is it can easily lead to a bitch session. Leave room for group catharsis, but step in to keep the conversation constructive.

Asking the same question in different ways can unlock conversations that teams might otherwise miss.

When it comes to the four stages of team development proposed by Bruce Tuckman, I’ve found retros can be highly effective at helping teams transition from “storming” to “norming.”

The best teams I’ve worked with didn’t just perform; they talked to each other differently. Retros create the space for a rare kind of discussion.

After all, Agile makes retros a team responsibility, not a role-based one.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”