Over 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. 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.
We tried going process-free. That lasted a few weeks before leadership started asking "when does this ship?" and nobody had an answer.
So we landed somewhere in the middle.
It's called Flights - and it's not new; someone tried it back in 2021: https://simonhoiberg.medium.com/...
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 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.
The thing that surprised us most was how well it communicated upward, sideways and to the rest of the organisation.
When we told our CEO "sprint velocity dropped 15%," we'd get blank stares.
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.
We started with sticky notes and a shared Figma file. It worked well enough that we built 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.
We know the obvious reaction: "AI is writing all the code now, who needs project management?" Honestly, we've found the opposite. AI makes
individual developers faster, but it doesn't solve the coordination problem. If anything, teams ship more things in parallel now, and the need
for visibility into what's actually happening has gone up, not down. Your AI pair programmer doesn't know that another team's flight just went
into emergency and yours needs to adjust course.
We've been running it in production for over a year across multiple teams. It was also built as a human-AI
collaboration and experiment - Engineers working with Claude from first commit to production, including the database migrations, E2E tests, CI/CD.
Live demo: https://agile.flights
Handbook (explains the methodology): https://agile.flights/docs
Happy to answer questions about the methodology and the tool.
Very cool! We have been looking for a good PM product...one potential addition that you could do is to add AI to suggest how PMs can move forward on backlogged tickets
The idea is very good… how do you plan to drive the mindset change in companies so that this becomes useful for them?
The captain accountability model is the right instinct someone owns getting it to the destination, not just managing the process.
Curious how the "landing" moment connects to actual deployment. Most project management tools treat the handoff to infrastructure as someone else's problem, which is exactly where the accountability chain breaks.
Does agile.flights have plans to integrate with GitHub or CI pipelines so "crate is done" maps directly to "crate is deployed and running in production"? That would close the loop the flight metaphor is reaching for — right now it stops at the runway.
The "headwinds/tailwinds" language for communicating status upward is the best part of this. We burned months trying to get non-technical stakeholders to care about sprint metrics. Plain language that maps to something intuitive beats a velocity chart every time. How are you handling mid-flight scope changes when a captain wants to add crates after takeoff?
Love the thought behind the name, @henrikhussfelt. Congrats on the launch!
@henrikhussfelt Congrats in the launch! I love this ideology. You mentioned the captains are strict which is great cause we need someone focused in landing that plane! However how does a small team with only a couple managers/supervisors navigate this process with so many flights that need to take off? Or is this geared more towards bigger teams and enterprise?
The flight metaphor is doing real work here — a sprint implies circular motion (you always restart), a flight has a destination and a real cost to rerouting mid-air. The "no story points, just done or not" discipline is the key insight.
Curious how you handle scope creep: if a crate grows during the flight, do you reroute mid-air (extend the flight) or leave it on the tarmac for the next one?
Great work launch team! 🚀 I love everything flight, so this is a fantastic concept for engineers. Particularly captains, crews and crates. Superb way to gamify project management.
Would be great if you could add "teams" -> Custom Airlines ✈️
Scheduled activities -> Scheduled Maintenance / Food & Beverage time
Custom Boarding Pass showing project inception to Project go live date with a loading bar which you can show incremental progress on as tasks are completed.
Backlog -> This can be ATC tower
Would be great it you clicked on an item or card similar to ADO and you could see the boarding pass in the card and even if you added a Departure/Arrivals after duration showcasing when a project is due to be completed and maybe a delayed status if it misses the window.
Also the landing page is great but I think the dashboard UI could be better, maybe if you used the same background from the landing page as opposed to just off white/grey.
Wishing you all the best with the launch! ❤️
Nice work Henrik very cool concept here! "we should have fewer meetings" and then we'd schedule a meeting to discuss that... make me laugh out loud, this is also quite quintessentially Swedish. Curious about if there is a "backlog" in a similar way to scrum, and how does the team decide on what goes into the flight? I always find that selection (eg what to work on) is the most difficult decision and can be costly if you choose incorrectly. How does it work here with the Flights methodology?
Jason Dainter