Over a year ago, our engineering team ditched Scrum. Not because we read some contrarian blog post, but because we looked at our calendars and realized we spent more time talking about work than doing it.
The breaking point
Standups that ran long. Grooming sessions nobody prepared for. Retros that concluded "we should have fewer meetings" and then we'd schedule a meeting to discuss that. Sprint planning where we'd argue about whether a task was a 3 or a 5, knowing perfectly well that the number meant nothing two days into the sprint.
The irony wasn't lost on us. We'd adopted Scrum to be more productive, and the framework itself had become the thing slowing us down. Not because Scrum is inherently bad - it's a fine system for teams that need the structure. But our team had outgrown it, and instead of admitting that, we kept bolting on more process to fix process problems.
Going process-free (spoiler: it doesn't work)
So we tried the opposite. No standups, no sprints, no planning sessions. Just a backlog and a team of competent adults who could figure it out.
That lasted about three weeks.
Without any structure at all, two things happened immediately. First, leadership started asking "when does this ship?" and nobody had an answer. Not because we didn't know, but because nobody was responsible for knowing. Second, individual contributors were productive, but the team wasn't coordinated. Three people would accidentally work on the same problem while a critical blocker sat untouched because everyone assumed someone else was handling it.
Process-free sounds liberating until you realize that coordination is a real problem, and ignoring it doesn't make it go away. It just makes it invisible until something breaks.
Finding the middle ground
What we needed was minimal structure with maximum clarity. A way to define what we're building, when it should be done, and who's responsible - without the ceremony overhead that comes with most frameworks.
We found it in a concept called Flights, originally proposed by Simon Hoiberg back in 2021. The idea is dead simple: a project is a flight. It has a takeoff date, a landing date, and a captain who's responsible for getting it there. Tasks are crates loaded onto the flight. Team members are crew. People doing maintenance work between flights are ground mechanics.
That's it. No story points. No velocity charts. No burndown graphs that give everyone a false sense of confidence. A crate is done or it's not. The flight lands on the date or it doesn't.
What surprised us
The thing that surprised us most wasn't the productivity gain - though that was real. It was how well the methodology communicated upward, sideways, and to the rest of the organisation.
When we told our CEO "sprint velocity dropped 15%," we'd get blank stares. Fair enough - that sentence requires a graduate degree in Scrum vocabulary to parse. When we said "this flight is hitting headwinds but still lands Friday," everyone in the room knew exactly what that meant. No translation layer needed.
The aviation metaphor isn't just cute branding. It maps to intuitions that everyone already has. Flights have destinations. They can be delayed. They can hit turbulence. They can make emergency landings. Everyone has been on a plane. Nobody has been on a sprint.
How we got here
We started with sticky notes and a shared Figma file. Literally just rectangles with flight titles on them, dragged around a canvas. No app, no database, no automation. Just a Figma file and a team that believed in the methodology.
It worked well enough for two years. Then we decided it was time to build a proper tool around it - an airport-board-style dashboard where you see what's in the air, what's on the runway, and what's landed. Captains, crew, status - all visible at a glance.
That tool became agile.flights.
Is this just Scrum with different names?
No, and this is the most common question we get. On the surface, a flight looks like a sprint and a crate looks like a story. But the methodology underneath is fundamentally different.
Scrum prescribes a rigid set of ceremonies, roles with specific responsibilities, and artifacts that teams must maintain. Flights strips all of that away. There's no mandatory standup, no story point estimation, no velocity tracking, no sprint review ceremony. The captain owns the flight and decides what process the crew needs - which might be a daily sync or might be nothing at all.
The core difference is philosophical. Scrum assumes teams need structure imposed on them to function well. Flights assumes teams are capable of self-organising and just need a clear framework for defining what they're building and when it should land.
If you're curious about the details, the handbook explains the full methodology. And if you want to try it, you don't need our tool - a whiteboard or a Notion page will do just fine. The methodology is free. The app is just a convenience.