Part I · The problem with how we build today
Standups, Ceremonies, Tickets — and the Illusion of Progress
Version 1.0 · November, 2026
In this section5
Modern software teams often confuse activity with progress. Agile and Scrum introduced rituals meant to support alignment, but over time those rituals hardened into routine. What was once lightweight became procedural. And what was once intended as a means to an end started to feel like the end itself.
In many organizations, the day is filled with movement: standups, sprint planning, backlog grooming, retro meetings, estimation sessions, ticket refinement. Everyone is busy. Everyone is “aligned.” The boards are colorful and always moving.
But the product itself? Often unchanged.
This is the illusion of progress: the feeling of moving forward when the work that actually matters—working software—has barely advanced.
Standups: the daily status theater
Standups began as a quick check-in. For many teams, they now consume time without generating insight.
- They rarely uncover unknowns.
- They often devolve into individual reporting.
- They create a false sense of shared understanding.
- They reward talking about work over doing work.
A good standup answers one question: What does the build need? Most standups answer a different question: How do I account for my time?
Ceremonies: institutionalized busyness
Sprint planning, grooming, retros—these were meant to serve the team. Instead, teams serve them.
Ceremonies create predictability, but they also create inertia. Once they’re on the calendar, they rarely go away. Each one reinforces the idea that coordination is the work, when in small-team environments, building is the work.
When a team spends more time preparing for meetings than writing code, something has inverted.
Tickets: the abstraction trap
Tickets were supposed to break work into manageable chunks. Over time, they became the primary unit of reality.
- A feature isn’t real until there’s a ticket.
- A question isn’t valid until it’s added to the backlog.
- Progress isn’t recognized unless it’s “moving” on a board.
But building great products requires fluidity: conversations, experiments, quick iterations, messy discovery. Tickets, by their nature, flatten this complexity.
- They capture tasks, not insight.
- They track output, not outcome.
- They create overhead, not clarity.
Boards move even when products don’t
The great danger of tickets, standups, and ceremonies is not that they waste time—though they often do. The danger is that they simulate progress.
- A standup can feel productive.
- A groomed backlog can feel organized.
- A sprint can feel structured.
- A burndown chart can look encouraging.
But none of these guarantee that the product is better today than it was yesterday.
In Build First, we measure progress differently:
Does the working software itself materially improve?
If not, the team is busy, but the product is not moving.
Removing the illusion
Build First strips away everything that doesn’t directly advance the product.
- Fewer meetings
- No mandatory ceremonies
- No endless backlogs
- No process to maintain for its own sake
Instead, attention flows to the only thing that matters: the evolving build. That becomes the meeting, the ticket, the plan, the proof.
When working software is the source of truth, the need for ceremony evaporates—and the illusion of progress gives way to actual progress.