Launched this week
agile.flights
Agile died in a JIRA board - replace sprints with flights
92 followers
Agile died in a JIRA board - replace sprints with flights
92 followers
Replace sprints with flights. A project management tool built around the Flights methodology - time-boxed initiatives with captains, crew, and crates.
Free Options
Launch Team / Built With
Wallet
@henrikhussfelt Hmm, very interesting — never heard of it before. It's just a metaphor though — does that really resonate with people enough to work so well?
Wallet
@henrikhussfelt I'm guessing a captain can only operate on one flight at a time? Similarly, the crew can't be on two planes at once?
@qvaz_ Actually crewmates can jump ship. Metaphorically we imagine someone jumping out of one aircraft and then joining another by being picked up (for fun). We do have crew working on multiple ones at the same time - they probably do that as they refuel ;-)
But yes - the captain part is strict; and given the short iterations this has helped tremendously; also with more people feeling ownership.
@qvaz_ It seem to do, the metaphors are much more graspable than the lingo we have invented as Engineers. What we saw was that people actually started understanding what Engineering was trying to relay when they started talking about "Emergency landings" or "Headwinds"/"Tailwinds".
All in all - there has been so much experimentations done in Agile, and frankly and personally not a single organisation applies it the same as another.
One can look at this as a more fun approach to these types of methodologies than what we've seen so far - but it actually brings business value by making things more obvious to the people outside of the "Engineering" puddle.
TLDR: It seems to work much better than anything we have seen so far. But again; all applications of these types differ :) Try it. It's been a fun ride!
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?
@jasondainter Yeah, that is essentially what we've seen in so many places. Meetings to sort out meetings death. And even where we are going with Engineering in general with support of AI there are so many organisations that are still having this battle - for a long time to come.
The Flights concept or this app does not at all care about the backlog - that usually lives in JIRA, Linear och Github. So there is a Backlog. The methodology and this app specifically helps focus on the essentials which is shipping - and defining what is shipped.
If one uses the "North Star" concept - which is much like general "Where we have to go" statements one ties the flights towards those and get invaluable metrics and updates towards the rest of the organisation - without having to dig through JIRA, Github, Releases or anything like that.
So essentially - this does not solve your biggest painpoint at all - and is still much of a Product Direction question. 🫣
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! ❤️
@minhajulll Awesome feedback!
Looking to create even more of these "Flight feelings", and added a bunch of these to our considerations in the backlog.
Elaborate on the "Custom Airlines" - that caught me specifically.
Regarding the Dashboard UI - it needs a lot of love, specifically the modals :peek: not there yet. :-)
@henrikhussfelt Really glad you liked the feedback, looking forward to seeing some of these implemented in a future release if you choose to do so.
By Custom Airlines I was referring to larger organisations where there are "teams" working on multiple projects. Instead of a "team" you could have a custom ariline I.e. "Third Line Airways", "Finance Bros Airways" you can of course be creative with the suffix name. But essentially, a team rebranded as an airline which would show up on the board.
@minhajulll Ah. Interesting concept! Thank you! :)
@minhajulll modals and background "fixed" :-) Should look better now.
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.
@avinash_matrixgard so in terms of handoffs - the essentials is that the team is cross-functional - meaning no handoff. So that would mean that you have someone from platform/infrastructure actually part of the Crew. Or this is automated enough not to need that skill...
Not to CI, but to Github and JIRA - it's actually already being tested. :-)
Github/JIRA Crate == Done => Webhook => Crate marked as completed.
@henrikhussfelt That webhook approach is the right call "crate done in JIRA" mapping directly to "marked complete" closes the loop that most project tools leave open. The cross-functional crew model makes sense too; the handoff problem usually disappears when the person who owns deployment is part of the flight from the start. Curious how you handle rollbacks if a crate gets deployed and needs to be reverted, does that reopen the crate or create a new one?
@avinash_matrixgard The webhook approach is now live for "Beta" users - and seems to work quite well. Some adjustments left :-)
Good question, in terms of the app itself there is no implementation regarding that at this point; and I do not really think it makes metaphorically sense to push a landed flight back mid air. That will cause confusion.
How it has been approached in the teams we have observed is that they simply create a new flight, new crates with the fixes.
Flights != Release
Flights go from A to B with the stuff we need to get done.
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?
@giammbo I know - we love it :-)
We have to handle scope creep much the same way; but here you have a designated Captain that is in charge. Either drop a crate; or adjust the span (having Headwind). Communication is key.
@henrikhussfelt The Captain as sole decision-maker is the key shift from Scrum, where scope choices get diffused or stall in backlog grooming. "Headwind" is an honest name for it — it signals real friction rather than masking an extension as routine. One thing I'm curious about: when a Captain calls Headwind, does the team get full visibility into the reasoning, or is it more of a top-down "this is happening"? That communication model seems like it could make or break adoption across different team cultures.
@giammbo quick note though - how it has been applied we're we have observed it the Captain is not the sole decision-maker; the crew collaborates. But the Captain can make those calls (so not sole decision-maker; but his job is to come to a conclusion).
Team often knows why they have headwind or tailwind; because they know what the Crates are. The Crew should be autonomous - meaning all should know the "why" in a sense.
That said; Explaining outwards why things are slow (or fast) could be tricky and if we just accept these concepts as the level of communication and have trust in the resolve it works pretty well.
The "job is to come to a conclusion" distinction matters — it's the difference between a Captain who synthesizes and calls it, vs one who simply overrides. If the crew already knows the Crates and the "why," the Captain's call feels like a conclusion the team could have reached together, just made explicit and official. The hard external communication case — explaining headwind to stakeholders who don't have the Crate context — is actually a good stress test of whether the internal framing is solid enough to survive translation. If it can't be explained simply outward, maybe the conclusion wasn't as fully resolved internally as it felt. Really well thought through — looking forward to seeing how agile.flights evolves in the wild.
@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?
@jacklyn_i In the concept when applied we have not looked at managers or super-visors at all; the Team ships stuff. Which means the team is cross functional for the Flight they are on. One of the members is a Captain. This means the Crew gets proper autonomy and can ship what they have been requested to ship.
This methodology has been applied in both small teams and larger ones from what I have personally seen. :)
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?
@abayb we could not agree more - the amount of times we've seen teams struggling with getting across the table with lingo that the counterpart does not understand is unfathomable.
"Oh, turbulence. I get it... ...probably a bit delayed then."
This is up to the Crew and Captain as a team - the methodology and app specifically states that the ownership is with the crew and they are flying on a schedule. If you can fit crates for some reason then by all means refuel mid-air. :) Same with dropping crates, just push them out the door...