How to Keep Your Product Development on Course with the 1 in 60 Rule

May 1, 2023
QA

In aviation, the “1 in 60 Rule” is a rule of thumb used by pilots to approximate heading errors and the necessary course corrections. In a nutshell, it states that for each degree off course over a distance of 60 nautical miles, you'll end up 1 nautical mile off course. It may not sound like much, but the difference can be huge. Take Flight TE901 for example.

On November 28, 1979, a sight-seeing aircraft from Air New Zealand piloted by Capt. Jim Collins crashed into the side of Mt. Erebus in Antarctica. An investigation found that the crew had not been informed of a two-degree correction to the flight path prior to takeoff. Instead of flying through McMurdo Sound, they flew head-on into the side of a volcano.

The 1 in 60 Rule isn't only useful for pilots. It's a reminder that the farther we go, the more off course we can end up. The real lesson is that small corrections early can help us avoid bigger corrections later.

“The 1 in 60 rule isn't just a navigation aid; it's a mental framework designed to reinforce the importance of making constant course evaluations and corrections.”
— Jeff Haden

Defects Don't Get Less Expensive with Time

It's a well-known fact in software development that the earlier you find a bug, the cheaper it is to fix. It's easier and cheaper to make a small change when you do it early, but harder and more expensive to make the same change if you catch it later. In spite of this, many companies take a reactive approach to defect management, and to product development in general. A proactive approach might alert a team to issues as new code is written and provide an early warning system.

I worked on a team created near the start of the COVID-19 pandemic. During the first six months, “we didn't have time” for team retrospectives because there was too much work to do. We delivered nearly seven months late because we did not make time for course corrections along the way. The company used multiple Angular applications, yet it took us nearly two months to deploy a new application for the first time. We did not have any real users providing fast feedback during development. At our first production deadline, we were missing a critical feature for our business users and could not deliver on time. We spent twenty months developing software without delivering any value. It's good work if you can get it, but most companies can't afford to spend that much time/money without some return on their investment in the near term.

Timing is Everything

If I design, develop, and build you a new snow blower ready for delivery in June, or a lawn mower in December, you won't have much use for it. Depending on when you deliver a new application, certain features may be more or less important to a given user. If you don't deliver the right thing at the right time, you won't be able to provide the value the business needs, when it needs it.

It's rare for me to work on a new application that doesn't have to account for an existing application or handle existing data. Most new applications I interact with perform the same types of functions: Create, Read, Update, and Delete (CRUD).

I've seen a pattern develop over time as to how such applications are built. Create a way to:

Load existing data.
View existing data (Read).
Add new data (Create).
Edit your new or existing data (Update).
Remove some of the data (Delete).

You can't edit data that doesn't exist, so you create the ability to add it before you can edit it.

Our team delivered a new application to replace two legacy applications, with the ability to add new data. Unfortunately, business users at that time needed the ability to edit existing data MORE than they needed the ability to add new data. We were out of sync with the business because we didn't establish milestones or “waypoints” along the way.

“You can't set an accurate course until you know exactly where you want to go”
— Jeff Haden

Bundles are for Insurance, Not for Software

Agile software development emphasizes delivering value more frequently, in small batches. The goal of Agile is not to deliver software faster, but to deliver value sooner in order to get fast feedback from the user.

My team at the time released software in large release “bundles”. Many days I'd start with a number of items to complete (let's say five). I'd complete two of them and by the end of the day, I now had seven things left to complete. It was impossible to make progress, and the size of our releases only grew bigger and bigger.

The bigger the release, the more time it takes to develop, test, deploy, and get feedback from real users. It's also more difficult to identify the root cause of a defect when an issue is reported. The problem isn't limited to software releases. Code commits can be just as problematic when changes for multiple pieces of work are combined in a single commit. The more changes in a commit, the longer it takes to review, and when it includes unrelated changes, it can also create confusion.

Working in small batches allows teams to deliver value sooner and get fast feedback about any needed changes, allowing the team to quickly iterate on those changes to meet business needs.

“Small releases allows us to constantly adjust course based on real users using our systems.”
— Paul Beers

Taste as You Go

Paul Grizzaffi wrote about a family recipe he followed for Thanksgiving that didn't turn out quite right. He followed a recipe, made no deviations, it wasn't particularly complicated, but it came with high expectations which were not met.

He mentioned how he learned both on his own and in various cooking classes to “taste as you go”. If you wait until the end to sample your dish, it could mean disaster–even if you're not on one of those high-pressure cooking shows.

A facet of the 1 in 60 Rule is to constantly monitor progress and make frequent course corrections. The Scrum corollary would be “Inspect and Adapt”. “Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.” (2020 Scrum Guide) Inspection and Adaptation are two pillars of that process. Sprint Retrospectives are a way to “Inspect & Adapt” at the end of a Sprint, but why wait until the end? Continuously identify what works and what doesn't and adapt accordingly, whether dealing with people, processes, products, or practices.

Stay on Course

Even the best pilots drift off track. It's important for all of us to recognize when we're wrong, or simply to recognize we don't have all the answers. The sooner we do, the less work it will be to get back on course.