The Flight Manual

A lightweight, ceremoniless agile framework to deliver features in a lean and continuous way.

What is ‘Flights’?

Flights is a new, lightweight, ceremoniless agile framework to deliver features in a lean and continuous way.

Lightweight

Flights come with very few predefined ground rules and can be implemented in many ways.

Flights does not claim that you need to follow the ground rules fully — you can adopt the core principles on top of other team practices and still benefit from using Flights.

Ceremoniless

Flights does not dictate when and how to do meetings.

There are no daily stand-ups.
There are no retrospective meetings.
There are no sprint planning sessions.

Of course, it’s hard to imagine collaboration without meetings, and you cannot plan your future work without involving the stakeholders and the team — but it is not a part of the Flights framework.

Aligning, planning, and reflecting on work is something that should be carried out in the way that makes best sense to the specific team, and does not involve or conflict with the practices of using Flights.

Continuous vs. Iterative

At its core, Flights encourages practices that allow teams to deliver features in a truly continuous and lean way as opposed to other frameworks like Scrum and Kanban which focus on iterations.

An iterative approach to feature development can be beneficial, especially in bigger software organizations with development across big teams.

For startups, SaaS development, and teams that generally work under the conditions of extreme uncertainty, a continuous approach will be far more beneficial.

Definition of a Flight

You can see a flight as a merge between a sprint and an epic.
It’s a group of related tasks and it has its own task board.
There are some key differences, though.

Tasks

When you book a flight, you add tasks to it.
Tasks can be anything that needs to be done, but is not restricted to the format of a “User Story” as we know it from Scrum.

As a rule of thumb, it makes sense to book a flight with tasks that belong together, are dependent on each other, or are expected to land at the same time.
However, nothing prevents you from adding unrelated tasks to a flight if there’s “room for it”.

A flight is defined as a regular task board containing (but not necessarily limited to):

• To Do
• In Progress
• Done
• Canceled

ETA

A flight does not have a fixed length (e.g. 2 weeks).
It has an ETA, and it’s determined when the flight is created.

We aim at landing the flight on time.
However, sometimes we have “tailwind” which causes the flight to arrive early.

Other times, we may experience “turbulence”, which causes the flight to be delayed.

Pilot

A flight has a pilot. The pilot can be anyone from the team, and is the person responsible for landing the flight smoothly in production, on time.
The pilot keeps the overview and delegates tasks to the staff (see below) when needed.

Co-Pilot

A flight has a co-pilot. The co-pilot supports the pilot.

Staff

A flight has staff. The staff is anyone from the team, working on the tasks in the flight.

Ground Rules

• A flight must have a pilot.
• A developer can only be a pilot on one flight at a time. (but can be a co-pilot or staff on another flight meanwhile).
• Developers can be staff at multiple flights at once.

The number of concurrent flights are naturally limited to the amount of developers on the team who can act as pilots.

However, you may (optionally) want to define a limited amount of flights that can be “in the air” at the same time.

Concurrent flights

There can be multiple flights in the air, at the same time.

So, in this way, we are not limited to “finishing” one sprint before starting a new one. Flights can fly in parallel, and they can overlap.

It is a good idea to always have a flight booked and prepared for takeoff, in case another flight arrives early and frees up a pilot and staff.

Emergency Landing

Sometimes something unexpected happens.
The flight may become extremely delayed, or we may not make it to the destination at all.

Keeping the flight in the air would cause us to “block” a pilot, which we definitely want to avoid.
In order to keep things transparent, it’s better to close the flight, even if it has unfinished tasks, so the pilot and staff can become available for something else.

We call this an “Emergency Landing”, which is simply the act of formally closing the flight and moving the tasks back to the backlog. We flag the flight as “Emergency Landed” somewhere appropriate for the team to see.

Flights was introduced while working on FeedHive.