On my honeymoon, we went to California, the parks of the West, and Hawaii. Five weeks, most of them in a rental car. We landed at LAX, drove south on the 101, stopped at Long Beach, found a Starbucks and a Barnes & Noble.
At the Barnes & Noble, we bought a large paper road atlas of the Western United States. My wife navigated from it and I drove, and we made it to every park on the list. That’s how we rolled in those ancient times: like pirates with a map to the treasure.
These days I use Waze, like everyone else. The atlas is on a shelf somewhere, but when I started learning to fly, those paper map memories came back.
In a cockpit, you always need to know where you are. Sure, you might have instruments, GPS, radios. But when you train, you learn to navigate with just a watch, a compass, and a map. That’s called dead reckoning: disciplined arithmetic about where you must be, given where you started and what you’ve done since.
You know where you were when you last had a fix. You know your heading. You know your airspeed and how long you’ve been flying. You do the arithmetic and commit to an estimated position, then you look for a landmark that confirms or contradicts the estimate, and you update. Not certain, just best-guess. Then you do it again.
I think that’s how you can see software development too, and that’s how Agile is supposed to work.
What dead reckoning actually is
Here’s the gist of how you do it in practice. I fly a lovely Piper PA28 called Tond, a 1989 aircraft with no GPS, but a perfectly serviceable compass.
Before a flight, you get your sectional (a fancy name for a map), figure out where you want to go, measure the distance and direction, factor in your cruise speed, and calculate how long you’ll need to fly before you expect to reach your next waypoint. Then you start flying, you start the stopwatch, and you go.
When the time’s up, you check: are you over the motorway junction? The village? The bridge? Maybe you’re a couple of minutes short. Maybe you’re a bit too far to the west. You correct, and move on to the next waypoint.
What you don’t do is wait for certainty, because certainty isn’t available. What you have is a best estimate, and you develop the discipline to act on it and correct it as the evidence comes in. Piloting errors accumulate, wind pushes you off course, your heading indicator drifts slightly. Small errors compound fast, so you update frequently and hold loosely to where you thought you were.
Agile is dead reckoning
Waterfall development is what happens when you treat software like construction: you design the whole thing first, write it all down, build it in sequence, ship it when it’s done. The plan is the plan. Requirements are locked. Changes are treated as failures of foresight, expensive and resisted.
It’s the equivalent of filing a detailed flight plan and then flying it exactly, regardless of weather, wind, or whether the mountain you thought was fifty miles away turns out to be thirty. At some point you land, and you’re not where you thought you’d be, and it took longer than you said, and half of what you built isn’t what users actually needed. This isn’t a theoretical risk. It is what happened on almost every large software project for decades.
What Agile actually is, underneath the ceremonies and the vocabulary, is dead reckoning. You take your best estimate of what needs to be built and in what order. You fly for a short period and you build something real. Then you take a fix: you show it to users, you measure what happened, you run the retro. You find out where you actually are versus where you thought you’d be, and you adjust the heading.
The sprint isn’t supposed to be a miniature waterfall. The backlog isn’t a set of immutable directions. They’re the best calculation you could make with the information you had at the time, and they were already partially wrong when you made them. The sprint review is the fix. Without it, you’re navigating blind. Funnily enough, sprint reviews are the most skipped meeting across all the organisations that claim to do Scrum.
Some teams treat commitments as sacred and the roadmap as a contract, and by the time anyone admits the heading was wrong it’s too late to correct without a crisis. Other teams use Agile as an excuse to never commit to anything, always discovering, always iterating, never actually going anywhere. Dead reckoning requires both: you have to commit to a heading, and you have to be willing to update it.
The arithmetic of being lost
Now, here’s something slightly annoying: you’re never not lost. You’re just lost with varying degrees of precision.
Even with GPS you have a margin of error. Even with a confirmed fix, by the time you’ve acted on it you’ve moved. Position is always a probability distribution, not a point. A good pilot isn’t the one who always knows exactly where they are. It’s the one who has a clear, honest estimate, knows roughly how stale it is, and already has a plan for the next fix.
This is true of software projects too. Velocity is a proxy. Story points are agreed fictions. Burndown charts are estimates of estimates. “When will this be done?” is always a dead reckoning answer, and anyone who gives it with false precision is either being optimistic or telling you what you want to hear.
That’s not a failure of planning. That’s what building software is. The teams that acknowledge it run better retros, give more honest forecasts, and adjust more cleanly when the heading turns out to be wrong. The ones that pretend to certainty spend their energy managing the appearance of being on track, right up until they aren’t.
Keep the fixes coming
In the air, you take a fix every few minutes: a motorway junction, a lake, a town. Small errors stay small because you catch them early. If you were to have an hour of flight between fixes, you’d be almost certainly far off course by the time you realise, and you’d be flying with total confidence toward somewhere you didn’t mean to go.
The sprint review is a fix. The retrospective is a fix. The demo, the code review, the conversation with the engineer who’s been quietly worried about the architecture for two weeks: these are all fixes. Each one corrects the accumulated drift. If you skip them because you don’t have time to waste, and you’re heads-down on the instruments, trusting that because you set the right heading at the start you must still be going the right way, you’re going to be very disappointed.
Long sprints, infrequent releases, rare user contact, retros that get cancelled when things get busy aren’t just process problems. They’re navigation problems. The longer you go without a fix, the further you can drift before you notice.
I still fly Tond without GPS. The estimate is always a bit wrong. The fixes keep it honest.
I’ve never once landed exactly where I planned to.
But I’ve always landed where I meant to. Can you say the same of your software projects?