Transitioning from Scrum / Kanban

If your team is already running Scrum or Kanban, you don't need to throw everything out and start from scratch. Most of the concepts you're used to have direct equivalents in Flights - they just carry less baggage. The transition is less about learning new things and more about unlearning the parts that weren't serving you.

Mapping Scrum to Flights

If you've been doing Scrum, most of the concepts will feel familiar - they just have different names and, more importantly, different expectations around ceremony. The key difference is that Flights strips away the ritual overhead while keeping the parts of Scrum that actually help teams deliver.

A Sprint becomes a Flight, but with an important twist: flights don't have to be a fixed length. If a project needs ten days, run a ten-day flight. If it needs three weeks, run a three-week flight. You're no longer forcing work into arbitrary two-week boxes. The work determines the timeline, not the other way around.

The biggest shift is philosophical. Scrum assumes that teams need a prescribed set of events to function well. Flights assumes that teams are capable of figuring out how to communicate and coordinate on their own - they just need a clear structure for what they're building and when it needs to land.

Mapping Kanban to Flights

Kanban teams often resist the idea of time-boxed work, and that's understandable. The continuous flow model has real strengths - no arbitrary deadlines, natural WIP limits, and a pull-based system that lets work progress at its own pace. Flights doesn't ask you to abandon all of that.

Think of flights as a layer on top of continuous flow. Your Kanban board columns map naturally to flight statuses: "To Do" becomes takeoff, "In Progress" becomes active, "Blocked" becomes emergency, and "Done" becomes landed. The board metaphor still works - it just shifts from a horizontal pipeline to an airport departure board.

WIP limits still apply, and they actually become more intuitive. Instead of limiting the number of cards in a column, you limit the number of concurrent flights per team. A team of six can reasonably handle two active flights and a ground mechanics rotation. Try to run four flights simultaneously and you'll feel the strain immediately - the same way you'd feel a column overflowing on a Kanban board.

The continuous flow model doesn't disappear - it becomes the domain of ground mechanics. Bug fixes, tech debt, dependency upgrades, and small improvements flow continuously through the team's ground mechanics rotation while flights handle the larger, goal-oriented initiatives. This separation gives you the best of both worlds: structured delivery for projects and continuous flow for everything else.

What to Keep

Transitioning to Flights doesn't mean burning down everything you've built. Your team has developed practices and tools that work for them, and the smart move is to keep the things that genuinely help you ship.

Keep your issue tracker. Whether it's GitHub Issues, Linear, Jira, or sticky notes on a wall, your issue tracker is where the details live. Crates in Flights can link to issues in whatever system you use. Flights provides the strategic layer - the "what are we trying to accomplish and by when" - while your issue tracker holds the tactical details of individual tasks.

Keep code reviews. Flights has nothing to say about your engineering practices. Code reviews, pair programming, mob programming - these are team-level decisions that exist independently of your project management methodology. If your team does thorough code reviews, keep doing them.

Keep CI/CD. Continuous integration and deployment are prerequisites for working effectively with any methodology. Flights assumes you can ship incrementally. If you can't, fix that before worrying about your project management approach.

Keep retros if they work. Some teams get genuine value from structured retrospectives. If your team leaves a retro with actionable improvements and actually follows through on them, that's a practice worth keeping. If your retros have devolved into "went well / didn't go well / action items that nobody reads" - that's a ceremony you're doing out of habit, not necessity.

Keep anything that helps you ship. This is the ultimate test. Does this practice make your team faster, better, or happier? Keep it. Does it exist because someone read a book about Scrum in 2015 and said you had to do it? Drop it.

What to Drop

Here's where it gets liberating. There are practices that most teams do out of obligation rather than conviction - things the process demands but the team doesn't actually need. Flights gives you permission to stop doing them.

Drop sprint planning ceremonies. You don't need a two-hour meeting every two weeks to decide what to work on. Flight planning is a conversation, not a ceremony. The captain and crew discuss the objective, load the crates, set the dates, and start working. If that takes fifteen minutes, great. If it takes an hour because the scope is complex, that's fine too. But it's driven by need, not by a calendar invite that fires every other Monday at 10 AM.

Drop backlog grooming sessions. The "grooming" or "refinement" session is where Scrum teams spend hours discussing work they might never actually do. It exists because Scrum needs a pristine backlog ready for sprint planning. Flights doesn't need that - you scope work when you're ready to fly, not weeks in advance.

Drop story point estimation. Story points were meant to be a relative sizing tool, but in practice they've become a proxy for time estimates that everyone pretends aren't time estimates. Teams spend hours debating whether something is a 5 or an 8, and then the estimates have zero predictive value anyway. Crates are done or not done. That's it.

Drop velocity tracking. Velocity is a vanity metric. It measures how many made-up numbers your team completed, not how much value you delivered. Flights replaces velocity with a simpler question: did the flight land on time? If flights consistently land late, you have a scoping problem. If they land on time, you're doing fine. No charts required.

Drop status meetings that exist for the process. If you have a meeting whose sole purpose is to update a status that could be conveyed by looking at a dashboard, cancel it. Your team's shared view of all flights shows everything at a glance - what's in the air, what's preparing, what's landed, and what's in trouble. If someone needs a status update, they can look at the board.

Gradual Adoption

The worst way to adopt any new methodology is to mandate it across the entire organisation on a Monday morning. People resist change they didn't choose, and they're right to. The best adoption is organic - it starts with one team, proves itself through results, and spreads because other teams see it working.

Start with one team or one project. Pick a team that's open to experimentation. Ideally, choose a team that's already frustrated with their current process - they'll be motivated to try something different. A single team running Flights for one project is enough to test the waters.

Run your first flight alongside your existing process. Don't abandon Scrum or Kanban cold turkey. Run a flight in parallel with your sprints for one cycle. Keep your existing ceremonies but also track the same work as a flight. At the end, compare the two experiences. Which gave you better visibility? Which required less overhead? Which did the team actually enjoy more?

Let the team decide. After the pilot, have an honest conversation. Did Flights work better? Worse? About the same but with fewer meetings? The team's experience is the only metric that matters here. If they prefer their old process, respect that. If they want to switch, support them.

Don't mandate Flights top-down. If leadership forces Flights on teams that didn't ask for it, you'll get the same resentment that killed agile in most organisations. Flights should spread because teams choose it, not because management decreed it. The methodology works because it gives teams autonomy - taking away their autonomy in how they adopt it defeats the entire purpose.

Iterate on your adoption. Your first flight won't be perfect. That's expected. Maybe you scoped too broadly. Maybe the landing date was too ambitious. Maybe the captain took on too much. Learn from it, adjust, and try again. By the third or fourth flight, your team will find its rhythm - and you'll wonder why you ever spent two hours in sprint planning.