How Retrospectives Make or Break Marketing Teams

Episode Transcript

I work with a team in health and life sciences that ran a retrospective after every single sprint for months.

Not sporadically. Not when things went wrong. Every sprint. The meeting had a named owner. Leadership sponsored it, so attendance was perfect — nobody skipped, nobody dialed in from a parking lot with their camera off. On paper, this team was doing the thing.

And it produced nothing. Nothing. Months of retrospectives and I could not point you to one thing about how that team worked that was different at the end of it.

I'm telling you this first because you've probably heard the opposite version of this episode — the version where retros are the practice everybody skips, and the fix is to stop skipping them. And there's real data behind that. In this year's State of Agile Marketing Report, 52% of marketers who rate their Agile implementation as extremely successful run retrospectives, versus 35% of everybody else. That's the widest gap of any practice we measured — wider than sprints, wider than Kanban boards, wider than WIP limits.

So the practice works. It just didn't work there.

That gap — between a team doing retros correctly and a team actually getting something out of them — is what this episode is about. Because that team eventually fixed it. It took one change. It wasn't a training, and it wasn't more effort. It was less.

---

Welcome to The Agile Marketing Edge, the first podcast dedicated to turning Agile theory into real-world marketing breakthroughs. I'm Monica Georgieff, Principal at AgileSherpas and your guide on this climb to smarter, faster, outcome-driven marketing. Every week we dig into the what, who, and how behind Agile marketing — from building high-velocity workflows and cutting waste, to measuring what actually matters and scaling success across teams.

Quick note, in case you were bracing for a different voice: I'm not Andrea. I'm Monica Georgieff, and I'm taking this one. She'll be back — she is not lost somewhere on the mountain.

I'll say this, though. Of all the episodes to hand off, this is the right one. That team I just told you about — I'm the person who was in the room. Retros are where I spend an enormous amount of my actual working life, which means I've watched a lot of them do nothing, and I've watched what changes when one finally clicks. So the stories in this episode are mine, and so are the scars.

Today we're squarely in the how — the day-to-day practices, the stuff that actually happens on a Tuesday afternoon. We're going after the practice that gets skipped more than any other, defended more weakly than any other, and correlates more strongly with success than any other. Those three things are related, and by the end of this I want you to understand exactly how — and I'll come back and tell you what fixed that team.

---

Let me be honest about the data first, because I don't want to oversell it.

52% versus 35% is a correlation. I can't tell you that adding a retro to your calendar next Tuesday makes your team extremely successful. That's not how any of this works, and if I said it, I'd be overselling this practice the way people oversell every other one.

But I can tell you the mechanism I think is underneath it. And it's not complicated.

Look at your Agile practices as a set. Standup coordinates the work. Planning selects the work. A review inspects the output. A Kanban board visualizes the flow. Every single one of those operates inside the system. They're how the machine runs.

The retro is the only one that operates on the system. It's the only practice whose entire job is to change the other practices.

Which means if you drop it, here's what actually happens: you don't stop being Agile. You freeze. Whatever version of the process you installed in month one — the sprint length someone picked, the board columns someone drew, the definition of done nobody has looked at since — that's your process now. Permanently. You will run it in month thirty-six exactly the way you ran it in month one, and you will call that Agile because the ceremonies are still on the calendar.

That's the theater. Not the fake standup. Not the sprint that's really a waterfall in a two-week costume. The theater is a system with no capacity to change itself, performing the visual language of adaptability.

And it explains the gap in the data better than "retros are magic." The teams running retros aren't succeeding because of the retro meeting. They're succeeding because they're the teams whose process has been through thirty rounds of correction, and yours has been through zero. They're not smarter than you. They just have a loop and you don't.

And here's the part that should make you uncomfortable — because it's what happened to my health and life sciences team. A retro that changes nothing is functionally identical to no retro at all. Same frozen process. Same theater. The only difference is that theirs cost thirty minutes a sprint and gave everyone the reassuring feeling of having done the work.

So the question for this episode isn't "should you run retros." Obviously you should. The question is why so many of them — the skipped ones and the dutifully performed ones — produce nothing. And the answer is that the loop breaks in two very specific places.

---

A feedback loop needs actual feedback going in. Most retros don't have any.

You've been in this room. Somebody asks what went well. Everyone says the team worked really hard. Somebody asks what didn't. Someone says "communication could be better." Everyone nods, because communication could always be better, and it's the one answer that indicts nobody. Thirty minutes later you leave having named zero real problems.

That's not a facilitation failure. That's a safety failure, and it's worth understanding precisely.

Amy Edmondson's research on psychological safety started with a finding that looked, at first, like a mistake. She was studying hospital nursing units, and the units with the best leadership and the best team climate were reporting more medication errors, not fewer. Which is backwards — better teams should make fewer mistakes. They did make fewer mistakes. They just reported vastly more of them, because on those teams you could say "I got that wrong" out loud without it becoming a permanent fact about you. On the other units the errors were still happening. They were just invisible.

Now put that in your retro. When your team says "communication could be better," the errors haven't stopped. You just can't see them. And you cannot fix what your team has decided isn't safe to name.

Here's where I'll push back on how this usually gets handled, though. Psychological safety gets treated in a lot of Agile content as an outcome — do retros, build trust, get safety. I think that's backwards, or at best circular. Safety is the input. Without it, the retro produces nothing, and then people correctly conclude the retro is a waste of time, and then it comes off the calendar. The lack of safety is what killed the practice, and the missing practice gets the blame.

The most common version of this on marketing teams is stunningly mundane: the most senior person in the room speaks first. They say what they thought went wrong. And that's it — that's now the agenda. Nobody contradicts the VP in a meeting about mistakes. You've just run a thirty-minute meeting to confirm what one person already believed.

There are two mechanical fixes, and neither requires a culture initiative. First: the person with the most positional power speaks last. Every time. Second: ask about the system, not the people. Not "who dropped the ball on the launch," but "at what point in this launch did we first know we were going to be late, and what stopped that from reaching anyone?" Same information. Completely different room.

---

Say you fix the input. People start telling the truth. Now you've got the second failure, and this one is dressed up as productivity.

You end the retro with a board full of sticky notes. Eleven improvement ideas. It feels fantastic — look how much we surfaced. Then everyone walks back into a sprint that was already full before the retro started, and precisely none of those eleven things happen.

Next retro, someone mentions one of them again. Slightly more tired voice this time. Third retro, nobody mentions it, because the team has learned the actual lesson: this meeting is where suggestions go to be acknowledged.

That's the death spiral, and notice that it feeds back into problem number two. Once the output side stops producing change, the input side dries up. Why would you risk saying the uncomfortable thing in a meeting that demonstrably changes nothing? So you say "communication could be better," and we're back where we started.

Site reliability engineers solved a version of this with the blameless post-mortem, and there's one rule worth stealing outright: when something breaks, the post-mortem examines what in the system allowed it — the alerting, the deploy process, the documentation — not who typed the command. And the fixes get filed as real work, with an owner and a due date, in the same tracker as everything else the team committed to.

But I want to be precise about the difference between that and a retro, because they get conflated constantly. A post-mortem is triggered by a failure — something broke, and you go find out why. A retro isn't triggered by anything; it runs on a cadence whether or not the sprint was a disaster. Which means it catches the slow stuff. The workaround everybody's quietly using. The handoff that costs two days every single time. The approval step nobody can justify but nobody will remove. Post-mortems find the fire. Retros find the wiring. And marketing teams are usually fine at the first one, at least informally — we'll all sit down and debrief a launch that blew up. We will never once ask why every launch takes three weeks longer than we plan for.

That's the whole trick. An improvement that doesn't go on the board is a wish.

And Norm Kerth — who wrote the book on retrospectives back in 2001 — put the framing around all of this before software teams got there. His prime directive, paraphrased, is that we enter the retrospective believing everyone did the best job they could with what they knew at the time, the skills and resources they had, and the situation they were in. It's not a nicety. It's a constraint that makes the conversation productive, because it takes "who's at fault" off the table and leaves only "what would we need to have known."

Here's the version I'd actually argue for on a marketing team, and it's more aggressive than most Agile people will tell you: leave with one action item. Not eleven. One. With a name on it and a date on it, sitting on your board as real work that pushes something else out.

One improvement that ships beats eleven that get acknowledged. And there's a compounding argument here that people miss — one real change every two weeks is twenty-six changes a year to how your team works. Nobody's process survives twenty-six deliberate corrections and stays mediocre.

---

Let me go back to that health and life sciences team, because I promised you what fixed them.

First, what was actually going wrong — and it's both of the failures I just described, running at the same time. The same stilted format every single time. The thornier topics got acknowledged and glided past. They'd end with a list of action items and no owner attached to any of them. And come the next retro, nobody asked about the last batch. Did anyone do those? Did they help? Nobody knew, because nobody looked.

So here's the fix. It wasn't a book. It wasn't a training — which I'll admit is an awkward thing for me to say out loud. The facilitator got to watch somebody else run one. That's it. And the reaction was immediate: "Oh. That's what this is supposed to feel like. That's what it's for."

Sit with that, because I think it's the most useful thing in this episode. That was not a knowledge problem. She knew what a retrospective was. She'd been running them every sprint for months, correctly, by the book. It was a reference problem. She had never been in a good one, so she was faithfully reproducing the only version she had ever seen.

That's most of marketing. We have very few people who've experienced a genuinely useful retrospective and can pattern-match toward it, so we default to the safe version — collect the sticky notes, thank everyone, adjourn.

What that team does now is narrower, not bigger. They're not trying to harvest every observation in the room anymore. They pick the highest-priority thing and stay on it until there's a real decision with a real name on it. Fewer sticky notes. More change.

That's also the answer to the homework objection, by the way. If your retro requires a themed board, an icebreaker where everyone picks a weather emoji for how the sprint felt, and forty minutes of prep — you've built a workshop. Workshops are expensive, and expensive things get cancelled first. Which is exactly what's been happening. Thirty minutes, one honest question, end on time. And rotate the facilitator — not for fairness, but so more people on your team get the reference experience.

---

You're not installing a practice this week. You're closing one loop. Four steps, and the order matters.

**One:** At the end of your next sprint, run one retro with no agenda beyond a single specific question. Not "how did the sprint go" — a question about something you have personally noticed. Why did those webinar assets go out the door twice? What made last week feel so much worse than the week before? Bring that question, source ideas on it, and hold the room to it. One real question beats a full agenda.

**Two:** Leave with one or two action items and clear owners. Ask for volunteers first. If nobody bites, ask the room who'd be the right person to own it — that question is much easier for a team to answer than "who wants more work." An action item with no name on it is a wish.

**Three:** Put it on your work management board as real work — the same board as everything else. If your team sizes work, size it; give it a Fibonacci number like anything else in the sprint. That does something subtle and important: it makes the improvement compete honestly with delivery work, instead of living in a parallel universe where it's free.

**Four:** Write yourself a note to open the next retro with it. Did it move? Did it help? Everyone skips this step, and it's the one that actually closes the loop. It's also the fastest way to prove to a skeptical team that this meeting has consequences.

That's it. That's the practice separating the extremely successful teams from everyone else by seventeen percentage points. Thirty minutes, one honest question, one change that ships.

You already have the time. You've just been spending it on a meeting that doesn't change anything — or on no meeting at all.

---

Until next time, I'm Monica Georgieff. And remember: the struggle is real. But so is Agile marketing.