In this post
“We hit a few blockers this sprint but we’re back on track.” Your project manager has said some version of that on three consecutive Thursday calls, and you have no way to check it.
Retros for non-technical founders are the cheapest fix for exactly that problem, and your dev shop may not be running them at all. Nobody warns you to ask, because retrospectives get written up as a thing engineers do among themselves.
The output of one is a document you can read in ninety seconds without understanding a line of code.
What a retro actually is #
At the end of each work cycle the team spends a short meeting on one question: how did the last stretch actually go, and what one or two things should change next time? The Scrum Guide caps it at three hours for a one-month sprint and says it is usually shorter for shorter sprints. That meeting is the retro.
The 2020 Scrum Guide defines the event narrowly: the team inspects how the last sprint went with regard to individuals, interactions, processes, tools and its definition of done, identifies the assumptions that led it astray, and picks the most helpful changes. Scrum.org’s plain-language version is worth five minutes if you want the vocabulary before you raise it with your agency.
Your Thursday call already covers status, and a demo covers the product itself, where you click through working software and say whether it does what you asked. Retros cover the third thing, which is how the work went: what slowed the team down, what they got wrong, what they intend to change.
There is a daily version of the same idea, covered in three questions that turn standup into proof in our free course. The retro is the slower, more honest sibling of that conversation.
The research is unusually strong for a meeting #
Scott Tannenbaum and Christopher Cerasoli ran a meta-analysis of debriefs: 46 samples, 2,136 people, team and individual debriefs, real and simulated settings, medical and non-medical. Published in Human Factors in 2013, it found that on average debriefs improved effectiveness over a control group by about 25%, and the authors conclude that properly conducted debriefs can improve performance by roughly 20% to 25%.
That is a large effect for a short meeting. It comes with a condition: the authors say “properly conducted” and report that alignment, and possibly facilitation and structure, bolstered the effect. That is not a group of tired people saying “went fine, next sprint.”
Which is why the thing you check is never whether a retro happened.
What you should get as the founder #
Ask for a one-page summary after each retro. Skip the raw notes, and skip the invitation to sit in, because your presence changes what people say out loud.
Here is the shape of a useful one:
That last block is the whole reason to ask for the document.
The one line that tells you the most #
Read the carried-over section before anything else. An action item that appears in three consecutive retros is a team that has diagnosed a problem, agreed on the fix, and cannot get to it.
- Sometimes that is your fault, because you keep adding scope on top.
- Sometimes the fix is much harder than they said in the room, which is worth a direct question.
- And sometimes the team simply lacks the authority to act: if their developers cannot spend two days on the test suite without a change order from their account manager, the same item will surface forever, which tells you the constraint sits in the commercial relationship rather than in engineering.
Either way it is a live signal you can act on this week without knowing what a flaky test is.
Notice that the sample above puts a task on the founder. A retro that never generates work for your side may have been sanitized before it reached you; that is our reading of the pattern, not a measured rate. Stefan Wolpers catalogued 21 sprint retrospective anti-patterns if you want to see how many ways this meeting can go quietly hollow.
How to ask for it without starting a fight #
Frame it as a request for a document rather than a change to how they work. Something close to:
“Do you run retrospectives at the end of each cycle? If so, could you send me a short written summary after each one - what went well, what slowed you down, what you’re changing, and anything carried over? I don’t need to attend.”
That phrasing gives them the format and takes the meeting off your calendar in the same sentence, and any team that already runs retros will say yes in under a minute.
Watch what comes back. A team that has been running retros produces the first summary within a cycle, sometimes by forwarding one they already wrote. Teams that have not been running them either start, which is a win, or explain that their process is too lightweight for that, which is the answer you were fishing for. Refusal to write anything down at all belongs on the same list as the other dev shop red flags.
Where this fits with the demo #
A team can write an honest, useful retrospective about a product that still crashes on login. The retro covers how the work went; it says nothing about whether the software actually runs, so it is only half of what you need.
For that you need the other half: a fifteen-minute session where somebody clicks through the actual product in front of you. The Friday demo rule in the course covers the format and the questions to ask during it. Pair the two and you have process health on one page and working software on a screen, which between them close most of the gap that makes founders anxious between invoices.
The habit is not free. A meeting every cycle, plus the work the team commits to, comes out of the same budget as features, so a week with a retro fix in it ships fewer features. The upside is the written summary above, and that is the trade to weigh. Our own written-first habits are in async remote XP practices.
Both of these are downstream of one habit: knowing what your team is doing through written artifacts rather than reassurance on calls.
Start with one question this week #
On your next call, ask when the team last ran a retrospective and what came out of it.
You will get a specific answer with a date and an action item, or you will get a pause while they reach for one. The pause tells you more than the tidy answer would have, and either way you know something this week that you did not know on Monday.
