Landing the Flight

Landing is not just "stopping work." It's the deliberate moment where the team declares that the flight has achieved its objective. Done well, it creates closure, captures learnings, and sets the stage for what comes next.

Definition of Landed

A flight lands when its core objective is achieved. Read that again. Not when every crate is complete. Not when the task list hits zero. When the goal is met. This distinction matters more than almost anything else in the Flights methodology.

If the flight's objective was "users can check out with Apple Pay" and that feature is live, the flight has landed - even if you didn't get to the "add saved payment methods" crate. That leftover crate can move to the next flight, get assigned to a ground mechanic, or be dropped entirely. The flight itself is a success because it delivered its outcome.

This outcome-oriented definition of "done" is what separates Flights from task-driven methodologies. In traditional agile, a sprint "fails" if the team doesn't complete every story in the backlog. In Flights, the only question is: did we land where we said we would? If yes, the flight is a success. If some cargo didn't make it, that's a prioritization decision, not a failure.

Teams that internalize this mindset ship faster because they focus on outcomes over outputs. They learn to cut scope ruthlessly, keep the goal in sight, and resist the temptation to gold-plate features that aren't essential to the mission.

The Landing Process

Landing a flight is straightforward. The captain confirms that the flight's core objective has been met. This might mean the feature is deployed to production, the migration has run successfully, or the design system update is merged and documented. Whatever "done" looks like for this specific flight.

Next, the captain triages any outstanding crates. Each incomplete crate gets one of three treatments: move it to the next flight if it's still important, assign it to a ground mechanic if it's small maintenance work, or drop it if it's no longer relevant. This triage should be quick - five minutes, not an hour-long grooming session.

Finally, the captain changes the flight status to "landed." The flight moves to the landing phase, where it's visible as a recently completed initiative. This visibility is important - it shows the rest of the organisation what the team has shipped and creates a moment of recognition for the crew's work.

The captain should land the flight promptly when the objective is met. Don't let a landed flight sit in "active" status while the crew polishes edge cases. That distorts the board's accuracy and can delay the next flight's takeoff. Ship, land, move on.

Retrospective

Keep it light. The goal of a flight retrospective is to capture useful learnings, not to conduct a formal ceremony. A 15-minute conversation beats a 1-hour facilitated session with sticky notes and dot voting every single time.

Three questions are all you need. What went well? What didn't? What would we change for the next flight? Go around the crew, give everyone a minute to share their thoughts, and write down the highlights. That's it.

No blame. If a crate took longer than expected, ask why - but with curiosity, not accusation. Maybe the scope was bigger than anticipated. Maybe there was a hidden dependency. Maybe the estimate was just wrong. Understanding the cause helps the team plan better next time. Assigning blame just makes people defensive and less likely to surface problems early.

Act on the learnings. If the retro reveals that the team consistently underestimates backend work, adjust future flight planning accordingly. If crew members report that the daily sync was unhelpful, experiment with dropping it on the next flight. Retros that generate insights but no action are a waste of everyone's time.

Some teams skip retros entirely, and that's fine too. If your team communicates openly during the flight and naturally adjusts its process, a formal retro might not add much. The methodology doesn't mandate it. But if things aren't going smoothly, a retro is the easiest way to start fixing them.

Archiving

Landed flights move to the archive after the team has processed the learnings. This isn't immediate - give the flight a few days on the landing runway so the team can see what they shipped and stakeholders can review the outcome. Then archive it.

The archive serves as institutional memory. It's a record of everything the team has shipped - what the objective was, who was on the crew, how long it took, and what crates were delivered. When someone asks "when did we launch the new payment system?" or "who worked on the API migration?", the archive has the answer.

Over time, the archive becomes a powerful tool for planning. You can look back at past flights to estimate how long similar initiatives take, see which team compositions work well, and identify patterns in what causes emergencies. This is real, evidence-based planning - not abstract story point calculations.

Don't archive too eagerly. A flight that just landed should stay visible for a bit so the team gets the satisfaction of seeing it on the board. But don't let the landing runway become cluttered either. Once the retro is done and any follow-up crates have been reassigned, archive it and clear the runway for the next landing.