In this article

Have you ever been on a fully-loaded airplane ready to depart, but instead you're stuck at the gate on a "ground hold" because of weather or some other type of issue at your destination airport? You look out the window and notice that the weather is beautiful and there's not even a line of planes waiting to take off. Why can't we just go?!

Know when to start and when to finish

When the computerized systems that help manage traffic flow realize that bottlenecks are likely to form, new departures are held on the ground. This not only saves gas by preventing circling in the air waiting for your turn to land, but also helps to reduce congestion and risk. This is the air traffic control version of valuing completed work over starting something new. 

An agile software development team that focuses on completing work in progress before starting new efforts actually ends up completing work faster. One of the ways teams can hold themselves accountable to finishing one aspect of the project before starting another is by limiting work in progress (waiting to take off if there is a bottleneck close to the destination). 

If someone on the team has capacity to help with a new task, it may be best for them to lend a hand in finishing work that's already been started, especially if the team has reached their work in progress limit.

Completing work in progress is one of many ways that an agile software development team can work in a way that supports a sustainable pace. This doesn't just mean that the team's work hours are constrained in some way. It also includes being intentional about the way the team interacts with stakeholders, when they decide to demo or deliver work and any other cadences that help drive the daily and weekly pace of the team and stakeholders. Teams that bounce between feast and famine, or are asked to surge on a regular basis, usually struggle to deliver in ways that are predictable both in timing and quality.

In the same way it's wasteful and risky to have planes circling while they wait for their turn to land, having work in progress "circling" on a software project introduces additional cost, additional risk and distracts the team from working on the highest payoff aspects of the project.

Be ready for (nearly) anything

Nearly everyone is familiar with US Airways Flight 1549's unplanned water landing, commonly referred to as The Miracle on the Hudson, that occurred in 2009. After a bird-strike on takeoff disabled both of their engines, the crew found themselves in a terrifying situation: they were low, slow, over a populated metro area and in the most congested airspace in the country. The lives of 150 passengers, 5 aircrew and any number of New Yorkers on the ground were in immediate danger.

On the flight deck, the two pilots quickly reacted. Captain Sullenberger took over flying the aircraft (an obviously important, but sometimes overlooked activity when an emergency occurs), began searching for a place to land and communicated with air traffic control for assistance. First Officer Skiles grabbed the emergency checklists and began troubleshooting the engine issues, doing everything humanly possible to get either engine to restart. In the passenger cabin, the flight attendants began preparing the passengers for an emergency landing. 

Although the crew had never prepared for this specific scenario, they used a common set of terms and operated within their defined and agreed-to roles to bring about a safe resolution to the emergency. 

Because of the standardization and automation involved in the air traffic control system, the controller providing direction for Flight 1549 was not only able to offer multiple options on places to land, but continued to control multiple other aircraft operating in his airspace at the same time!This YouTube video captures the audio recording from the controller's perspective from bird-strike through landing with a map of the aircraft's course. Even if you can't make out the details of each transmission, listen for the simple and concise nature in how information is relayed.

By defining and publishing flight paths to and from airports, standardizing the language and style of communication and holding each other accountable to these standards, air crew and air traffic controllers are able to maximize simplicity and allow for the ability to embrace changes that occur during emergencies, unexpected weather events or mechanical failure.

The most successful software development teams I've been a part of have always strived to maximize simplicity. From a technical perspective, simple code reduces the likelihood of defects and allows for an easier transition back to a customer or support team when the project is over. From a team-based perspective, simplifying communication channels, implementing automation and agreeing to a set of working agreements allows a development team to reduce the cognitive burden of having to recreate the wheel for events and activities that are commonplace. 

Having this cognitive 'space' available allows teams to embrace change that is inevitable on a software project. From massive changes like the COVID-19 pandemic severely limiting day-to-day life to smaller shifts between competitors in a niche industry, the assumptions and desired outcomes at the start of a project are likely to change before the project is over. Teams that have taken an approach to maximize simplicity will be much better positioned to deal with this change.

Although the stakes in a real-life aviation emergency may never equal that of a software development effort, teams that have maximized simplicity through automation and standardization allow for the space needed to handle changes that will certainly come with a project of any complexity.

Always look for a chance to learn

As an Agile Coach, I'm regularly looking to learn more about my craft and want to find ways to help others do the same. Concepts and learnings from nearly any field of study or practice may help us find ways of working that allow for continuous improvement. One of the mantras of our organization is "Strong Opinions, Weakly Held" — essentially, we commit to the best known approach until evidence comes along that we should make a change. 

Here's to always being on the search for a better way!

 

Notes:

The IT related concepts covered in this article can be found in their full context in the Manifesto for Agile Software Development and the associated Principles Behind the Agile Manifesto, which are among the founding documents of the Agile Software Development movement. For additional reading on this topic, check out The Phoenix Project: A Novel About IT, Dev Ops, and Helping Your Business Win.

The film Sully is based on the events of US Airways Flight 1549, and from my perspective, does a great job at telling the story in a way that's (mostly) true to the facts of the event.