Every few weeks someone posts a version of the same question in the agile subreddits. We're five people. Same Slack channel. We ship daily. We don't run sprints. Why would we schedule a meeting to talk about how we work when we already talk about how we work constantly?
The replies are reliably worse than the question. "Inspect and adapt." "Continuous improvement." "It's in the Scrum Guide." Those aren't reasons, they're slogans, and a founder burning runway can smell a slogan from a mile off.
I've come around to thinking the person asking is about 70% right. The ceremony they're refusing genuinely is a waste of their time. The thing underneath it is not, and it's worth separating the two. Here's the distinction, and the 25-minute version I'd actually defend in front of a skeptical founder.
What they're actually refusing
The retro most people picture is 90 minutes, a facilitator, a Mad Sad Glad board, and eight action items nobody opens again.
That format exists for a reason. Informal feedback channels stop scaling somewhere around a dozen people, so a 40-person org builds a ceremony to replace what used to happen in the hallway. It's a workaround for size.
A five-person startup has the hallway. It works. Most of what a big-company retro surfaces on Thursday, a small team knew on Tuesday and fixed on Wednesday. And the cost isn't hypothetical: five people in a 90-minute meeting every two weeks is roughly a day and a half of engineering time a month, at a company whose runway is measured in months.
So when someone answers "because the framework says so," the skeptic is right to ignore them. They're not running Scrum. They're running a company.
Where the objection breaks
Conversation is excellent at incidents and blind to patterns. Staging eats an afternoon. Someone fixes it, posts in Slack, everyone moves on. Three weeks later it happens again, different symptom, same root cause. Someone fixes it again. Nobody says "this is the fourth time this quarter" because nobody is counting. Each instance was small enough to absorb and the fix was fast enough that the pattern never became visible to anyone.
Frequency is the information, and continuous feedback throws it away. We aggregated every retrospective ever run on our platform: 86,977 boards, 1,071,253 cards, written by real teams between October 2023 and July 2026. The top complaints weren't dramatic. Testing and QA led at 10.2% of all complaint cards, then tickets and requirements at 8.1%, then deploys and releases at 4.9%. Communication, the thing every agile book names as the problem, came in at 1.9%.
Look at what the top entries have in common. They're slow-burn structural problems that are nobody's emergency on any given afternoon. That's exactly why they never come up in the hallway, and exactly why they compound.
Your feedback loop runs one direction more than you think. At five people, the loudest voice usually signs the paychecks. That doesn't make anyone a bad manager, it's just what happens when the person with the most context and the most conviction is in every single conversation. Junior engineers don't push back on a founder in a live thread about the founder's own architectural call.
The first time I ran a write-before-you-talk retro at a company that small, the top-voted card was about me. Specifically, about how often I changed priorities mid-week and how much rework it caused downstream. Nobody had said it out loud in four months. It was uncomfortable, and it was the most useful single data point I'd gotten about that team all year.
The bill arrives at hire number seven. Startups don't stay five people, that's the entire point. Decisions made in a hallway leave no record. The founding team remembers why the billing service is shaped the way it is and why nobody touches the import job. Hire six engineers in a quarter and none of them have any of that. They'll relitigate calls you settled in March while you spend your quarter re-explaining instead of building.
Where the skeptics are right
I'd rather be honest about this than sell a ceremony. There are cases where I'd tell you to skip it.
- Two co-founders who pair all day, pre-product, no employees. Your Tuesday walk is the retro. Do it deliberately once a month and write down what you decide.
- The cycle where everything went sideways on one incident. Run a postmortem instead. It's a better format for a single event with a clear cause.
- You already run a monthly written review that asks what's slowing you down. That is a retro. Keep it, skip the second meeting.
What doesn't count: "we're too busy." Five people for 25 minutes is about two hours of company time a month. One repeat deploy failure costs more than that in a single afternoon, and you've had four of them.
The 25-minute version
No facilitator training, no icebreaker, no sprint required. Every two weeks, or monthly if your cycle is slower.
- Five minutes of silence. Three prompts is plenty: what slowed us down, what worked better than expected, what are we about to hit. Everyone types at the same time and nobody reads until the timer ends.
- Five minutes to group and vote. Pull duplicates together, because duplicates are the signal you came for. Two votes each.
- Ten minutes on the top two only. Everything else stays on the board as a record. You're not solving the month, you're finding the thing that keeps quietly costing you days.
- Five minutes to name one change and an owner. One. Not a list.
That last point is where most small-team retros die. Walk out with eight process improvements and they have to compete with shipping. They lose, every time, and after two rounds of losing the team learns the meeting doesn't produce change.
The tooling part
I work on Kollabe, so take this with the appropriate grain of salt. The patterns generalise, and if your tool does these differently, swap in the equivalent.
Two behaviours matter more than anything else at this size. The first is that cards are submitted before anyone can read them, and can be submitted anonymously per session, so the founder's take isn't the first thing everyone anchors on. The second is that action items outlive the meeting: whoever gets assigned one is notified immediately, and anything still open shows up in a weekly email digest rather than quietly decaying on a board nobody reopens.
Async matters too. Nobody needs to be in a room. Post the board Monday morning, let people add cards through the day, and spend fifteen minutes together on the top two.
The rule of thumb
Here's the question I'd hand a skeptical founder, and it's the whole argument compressed:
If this problem were happening for the fourth time, would anyone on your team be able to tell you?
If the answer is yes, you genuinely don't need a retro this month. If the answer is no, you don't have a ceremony problem, you have a memory problem, and no amount of talking in Slack will fix it. Talking is how you handle the instance. Writing is how you catch the pattern.
Start with a board and three prompts. Twenty-five minutes, once a fortnight, one change with a name on it. If you want somewhere to put it, Kollabe's retros are free for small teams and work async. But the tool is the least interesting part of this. The record is the part that compounds.
Top comments (1)
A retro is just a time to reflect and learn. Every team should take some time to do one, even if it’s something as small as chatting about what didn’t work well.