agile.flights
Agile died in a JIRA board - replace sprints with flights
95 followers
Agile died in a JIRA board - replace sprints with flights
95 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.
@henrikhussfelt That distinction makes sense a flight that landed is done, a rollback is its own mission with its own destination. The "new flight for fixes" pattern actually aligns with how the best teams I've seen handle hotfixes: separate scope, separate accountability, separate captain. Keeps the original flight's success record intact too. Is there a way to link flights so the fix flight references the original, or is that relationship tracked elsewhere?
@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...
The idea is very good… how do you plan to drive the mindset change in companies so that this becomes useful for them?
@damian_quiroga we don't ;-) Either you like the concept or want to try it - or you don't :-) The handbook is there for anyone to apply it - the app is just assistance.
This is not as much business as it is a possibly better way of working.
@henrikhussfelt I love the attitude!!! Wishing you success
@damian_quiroga 🙏 Thank you!