Why Flights?

Agile started with a manifesto. It ended with Jira. Somewhere between the two, we traded human communication for an ever-growing glossary of terms that only a few understand - and a calendar full of ceremonies that no one enjoys.

Flights is a different approach. It borrows from the best parts of agile - small teams, iterative delivery, clear ownership - and wraps it in a metaphor that everyone in your organisation already understands: aviation.

You Should Try Flights If...

• Your standup takes longer than the actual work you discuss in it
• You spend more time grooming a backlog than shipping features
• Your team has "sprint planning" meetings to plan what you'll discuss in the next planning meeting
• You have a Jira board with 47 columns and nobody remembers what "Ready for QA Review (Pending)" means
• Your retros always conclude with "we should have fewer meetings" and then someone schedules a meeting to discuss that
• You've ever said "story points" out loud and felt a small part of your soul leave your body
• You believe that small, empowered teams shipping continuously beats ceremony-driven development every time

The Problem with Agile

Let's be honest: most "agile" teams are not agile. They're running a waterfall process disguised as sprints, with a Scrum Master acting as a project manager who's been told they can't be called a project manager anymore.

The original Agile Manifesto valued individuals and interactions over processes and tools. But what do most agile teams actually have? A 14-step process, three tools that don't talk to each other, and interactions that are limited to a daily status meeting where everyone talks to the screen instead of each other.

The terminology doesn't help. When you tell your CEO that "the sprint velocity is 42 story points and we're carrying over 3 epics into the next iteration," their eyes glaze over. That's not communication - that's obfuscation.

The Flight Metaphor

Everyone understands flights. You board. You take off. You land. There's a captain responsible for getting everyone there safely. There's a crew doing the actual work. And there are ground mechanics keeping things running between trips.

When you say "this flight lands on Friday," everyone in the room - engineers, designers, product managers, executives - knows exactly what that means. No translation required.

When a flight hits an emergency, everyone understands the severity. When crates are being loaded onto a flight, everyone can picture the work being prepared. When the captain takes responsibility, the ownership model is crystal clear.

This isn't just a naming exercise. The aviation metaphor naturally encodes best practices:

• Flights have a departure and arrival. Every initiative is time-boxed by nature.
• You can't fly forever. Flights that run too long are a clear signal that something is wrong.
• Captains are accountable. One person owns the outcome. No "shared ownership" ambiguity.
• Ground work happens between flights. Maintenance and tech debt have a dedicated space, not an afterthought.

Why It Works

The Flights methodology has been used in production at real companies. It's not theoretical - teams have shipped with it, hired with it, and grown with it. Here's why it sticks:

Universal language. Your CEO never understood sprint velocity. They instantly understand "we expect headwinds, but the flight lands Friday." Flights creates a shared vocabulary that works across the entire organisation, from interns to the board room.

Minimal ceremony. No sprint planning. No backlog grooming. No velocity tracking. You plan a flight, take off, and land. The process gets out of the way so the team can focus on what matters: shipping.

Built-in accountability. Every flight has a captain. Every crew member has a role. Ground mechanics have dedicated time for maintenance. Ownership is never ambiguous.

Visual and intuitive. Your team's shared view of all flights should show everything at a glance - what's preparing to take off, what's in the air, what's in trouble, and what has landed. No burndown charts. No cumulative flow diagrams. Just flights.

What Flights Is Not

Flights is not a heavyweight framework. There are no certifications. No three-day training courses. No consultants who will charge you $10,000 to tell you you're doing it wrong - except if you want to pay someone for it that is.

Flights doesn't replace your issue tracker. Crates - the tasks within a flight - can link to GitHub issues, Linear tickets, Jira issues, or anything else. Flights sits above your existing tools, providing the structure and visibility layer that connects individual work to team-level initiatives.

Flights also isn't dogma. If your team benefits from a daily standup, keep it. If you want to estimate crates, go ahead. The methodology provides the scaffolding - how you build on it is up to you.

Or - you're just bored with your current agile workflow and need to try something new. New and shiny is always better, you know ;)