Why You Should Use Agile Flights With AI

Key Points

• Traditional agile frameworks were designed to coordinate large teams. For solo operators and small teams, the ceremonies are the overhead.
• Flights is a lightweight framework where each flight is a bundle of related tasks with an ETA, a pilot, and its own kanban board — no standups, no sprint planning, no retros.
• Claude Cowork acts as air traffic control across concurrent flights while Claude Code pilots individual workstreams, letting multiple projects fly in parallel without blocking each other.

I’ve tried everything. Scrum with two-week sprints. Kanban boards in Notion. Linear for a while, which is a great tool but built for engineering teams with proper sprint cycles and team workflows. Plain old to-do lists in Apple Reminders. At one point I was running a Trello board, a spreadsheet, and a notebook simultaneously, which is just three systems for losing track of the same tasks.

The problem was never the tool. The problem was that every project management framework I tried was designed for a team of people who need to coordinate with each other. I don’t have that problem. I’m a solo operator running multiple businesses. The standup is me talking to myself. The sprint review is me reviewing my own work. The retro is me thinking “I should have done that faster” and then moving on.

Then I found Flights.

Why traditional agile breaks for small teams

Agile was built to solve coordination problems. Daily standups exist because people on a team lose track of what others are doing. Sprint planning exists because work needs to be negotiated across capacity. Retrospectives exist because communication gaps between team members create recurring failures.

When you’re one person, none of those problems exist. You know what you’re working on because you’re the only one working on it. You don’t need a planning session to negotiate capacity with yourself. The ceremonies become pure overhead.

The iterative model creates problems too. Two-week sprints force everything into the same time box. But real work doesn’t come in uniform two-week chunks. Some things take three days. Some take three weeks. Cramming a three-day task into a two-week sprint creates slack. Cramming a three-week project into a two-week sprint creates pressure to cut corners or carry work into the next sprint, which defeats the purpose.

For startups and solo builders working under constant uncertainty, the rigid structure of scrum actively slows you down. You spend time serving the process instead of the process serving you.

What Flights gets right

Flights is a lightweight, ceremoniless agile framework created by Simon Hoiberg. The core idea is simple: a flight is a merge between a sprint and an epic. It’s a group of related tasks with its own kanban board and an ETA.

No fixed two-week length. No mandatory ceremonies. No prescribed meeting cadence.

Each flight has a pilot (the person responsible for landing it), a co-pilot if needed, and staff working on tasks. The board is straightforward: To Do, In Progress, Done, Canceled. You book a flight with tasks that belong together or depend on each other, set an ETA, and fly.

The part that matters most for how I work: flights run concurrently. You’re not locked into finishing one sprint before starting another. Multiple flights can be in the air at the same time, limited only by how many pilots you have available. If a flight gets stuck, you don’t let it block everything else. You call an emergency landing, move unfinished tasks back to the backlog, and free up the pilot for something else.

This maps perfectly to how I actually build. I might have a client deliverable that’s a five-day flight, a blog migration that’s a two-week flight, and a side project feature that’s a three-day flight. They don’t need to fit in the same sprint. They fly on their own schedules.

Claude Cowork is my air traffic controller

Here’s where Flights goes from a good framework to something that feels like it was designed for AI.

You can’t run two sprints at once. But you can have three flights in the air simultaneously. The concurrent model only works if something is tracking the airspace, and that’s where Claude Cowork comes in.

Cowork sits above all my active flights. It knows which ones are in the air, what tasks are in progress, what’s blocked, and what’s approaching its ETA. When I start my day, I check in with Cowork the same way an air traffic controller checks the board. Which flights are on schedule? Which ones hit turbulence overnight? Is there a pilot free to take off with a new flight?

Here’s what a typical morning looks like. I might have three flights active:

Flight 1: Client website redesign — ETA next Tuesday. Four tasks on the board, two in Done, one in Progress, one in To Do. On schedule.

Flight 2: Blog post migration — ETA end of week. Six tasks total, converting old Webflow posts to MDX. Three done, three queued. Ahead of schedule, tailwind.

Flight 3: New feature for a side project — ETA was yesterday. Two tasks stuck in Progress because of an API issue. This one needs attention or an emergency landing.

Cowork holds all of this context. I don’t need a standup to know the status. I don’t need a sprint board to see what’s behind. I ask Cowork and get an honest answer about where everything stands.

Claude Code pilots the flights

Each flight has tasks on a kanban board. Claude Code picks up tasks, executes the work, and moves them through the board. The pilot analogy works because Claude Code doesn’t decide where to fly. I set the destination when I book the flight. Claude Code handles the execution.

A task might be “build the contact form component” or “convert the April blog posts to MDX.” Claude Code takes it from To Do, works through it, and lands it in Done. When it hits turbulence, like an unexpected error or an approach that isn’t working, it flags me. When it has tailwind on a straightforward task, it lands early and I can assign the next one.

The concurrent model means Claude Code can be piloting a task on one flight while I review completed work on another. I’m not waiting for a sprint to end before starting new work. I’m not context-switching between unrelated tasks on the same board. Each flight is its own contained workstream with its own board, and Claude Code moves through them independently.

When a flight has all its tasks in Done, it lands. I review the work, close the flight, and book the next one. If I have a new flight prepped and a pilot available, takeoff is immediate. No sprint boundary to wait for.

What this looks like day to day

The morning check-in takes five minutes. I open Cowork, scan the active flights, and make decisions. Does Flight 3 need an emergency landing or can Claude Code work through the API issue? Is there room to book a new flight since Flight 2 is ahead of schedule? Any tasks that need my input before Claude Code can continue?

Throughout the day, Cowork manages context across flights. I make judgment calls when flagged and handle the high-leverage decisions: what to build, what to cut, what to prioritize. Claude Code handles the execution. The coordination tax that would normally require a project manager or a team lead is zero because there’s no coordination problem to solve. There’s just an air traffic controller keeping flights on schedule and pilots landing tasks.

The result is that multiple workstreams move simultaneously without me becoming the bottleneck. That’s the thing scrum could never solve for a solo operator. You were always the bottleneck because you were the only person on the team. With Flights and AI, you’re not the only person anymore. You’re the air traffic controller with a fleet of pilots, and the question isn’t how many sprints you can run per quarter. It’s how many flights you can keep in the air at once.