Frequently Asked Questions
Answers to the questions we hear most often from teams evaluating or adopting the Flights methodology. If your question isn't covered here, it probably means we haven't been asked it enough yet.
General Questions
Is Flights just Scrum with different names?
No, and this is the most common misconception. 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 sprint planning ceremony, no mandatory standup, no story point estimation, no velocity tracking. 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.
Do I need the agile.flights app to use the methodology?
Absolutely not. The founders of this app spent two years running Flights by dragging rectangles around a Figma board - literally just shapes with flight titles on them. No app, no database, no automation. Just a Figma file and a team that believed in the methodology. And it worked. The agile.flights app exists because after two years of that, we decided it was time to build something purpose-built - with a proper airport board, crew assignments, and ground mechanics tracking. But the methodology itself is just a set of principles and practices that work regardless of how you track them. A whiteboard, a spreadsheet, a Notion page, or a Figma board will do just fine.
What size teams does this work for?
Flights works best for teams of 2 to 15 people. Below two, you don't really need a methodology - you're just two people talking. Above fifteen, coordination overhead grows exponentially regardless of what process you use. For larger organisations, the approach is to have multiple teams of 2-15, each running their own flights independently, aligned through shared North Stars. A company of 100 engineers might have eight teams, each running their own flights. The North Stars provide the strategic alignment that keeps everyone moving in the same direction without centralised coordination.
Does this work for non-engineering teams?
Absolutely. The aviation metaphor is universal - it doesn't assume you're writing code. Marketing teams can run a flight for a product launch campaign. Design teams can run a flight for a rebrand. Operations teams can run a flight for a process improvement initiative. Any team that works on time-bound projects with defined objectives can use Flights. The crates might contain design deliverables instead of pull requests, and the "deployment" might be a campaign going live instead of code reaching production, but the structure works the same way.
Roles and Teams
Can one person be captain of multiple flights?
No. The methodology requires one captain per active flight — shared captaincy creates the same accountability gaps Flights is designed to eliminate. You can only be captain of one active flight at a time. This is a deliberate design choice, not a limitation. Being a captain means being accountable for a flight's success - removing blockers, keeping the crew aligned, making scope decisions, and communicating status. That's hard to do well for one flight, and significantly harder for two or three simultaneously. When a captain is split across multiple flights, each flight gets a fraction of the attention it needs. If you find yourself wanting to assign the same person as captain of multiple concurrent flights, it usually means you either need more people stepping into the captain role or you're running too many flights at once.
What if we don't have enough people for ground mechanics?
Scale it down rather than skipping it entirely. Even a half-day rotation helps - one team member spending Tuesday and Thursday afternoons on maintenance work is better than nobody doing it at all. For very small teams of two or three, the ground mechanics role might be as simple as reserving Friday afternoons for tech debt and cleanup. The point isn't to have a full-time maintenance team. It's to make maintenance visible and intentional rather than something that only happens when things break.
Who decides who's captain?
Ideally, the team decides. The captain should be the person best suited for the specific flight - someone who understands the problem domain, has the context to make scope decisions, and is motivated to drive it to completion. That might be a senior engineer for a complex infrastructure flight, or a junior engineer for a feature they've been championing. Rotating the captain role across the team is a great way to develop leadership skills and prevent any single person from becoming a bottleneck. Avoid letting the captain role calcify into a permanent assignment for the team lead - that defeats the purpose.
Process Questions
How long should a flight be?
The default recommendation is one to three weeks, with fourteen days as a solid starting point. Short enough to maintain urgency and focus, long enough to accomplish something meaningful. But unlike sprints, flights don't have to be a fixed length. A small, well-scoped initiative might be a five-day flight. A complex migration might justify three weeks. The length should be driven by the scope of the work, not by an arbitrary cadence. The key constraint is: if a flight needs more than three weeks, it's probably too broad and should be split into sequential flights.
Can we add crates mid-flight?
Absolutely. Plans change, and pretending they don't is one of the biggest failures of rigid frameworks. If you discover mid-flight that you need an additional piece of work to achieve the objective, add a crate. If a bug surfaces that blocks the flight's progress, add a crate. The captain should keep an eye on the total scope to make sure additions don't turn a focused flight into an overloaded one, but the ability to adapt is a feature, not a bug. This is one of the areas where Flights explicitly differs from Scrum, which traditionally discourages changes to the sprint backlog once a sprint has started.
What happens to incomplete crates when a flight lands?
Triage them. Every incomplete crate gets one of three dispositions: move it to the next flight if it's still important and relevant, hand it to ground mechanics if it's maintenance-level work, or drop it entirely if it turned out not to matter. The worst thing you can do is automatically carry everything forward into the next flight without thinking about it - that's how flights inherit scope bloat from their predecessors. Forced triage at landing is one of the most valuable aspects of the methodology. It makes you actively decide what matters instead of letting unfinished work pile up by default.
How do we handle dependencies between flights?
The best answer is: keep flights independent wherever possible. If Flight A can't land until Flight B delivers a specific API, you have a dependency problem that no methodology can fully solve. That said, dependencies happen in the real world. When they do, communicate them early and explicitly. If a flight is blocked by another team's work, declare an emergency - that's exactly what the status exists for. It makes the dependency visible and triggers a conversation about how to resolve it. Over time, aim to structure your teams and flights so that each team owns enough of the stack to operate independently. Cross-flight dependencies are a sign that team boundaries or flight scopes need adjustment.