When recording our latest episode of Troubleshooting Agile, on which metrics make sense for assessing a team, I was reminded of a technique for gauging project progress that I’ve used very successfully with several clients.
Have you ever landed an airplane? For understanding this method, simulators count just fine—my own experience is from Microsoft Flight Simulator on the TRS-80. Jeffrey has landed gliders so he got it right away. If you haven’t been at the controls yourself, search YouTube for “landing into a crosswind” and watch at least one landing. I’ll wait.
Back now? The key thing you might have noticed is that while there is an ideal path from the sky to the runway, actual airplanes don’t follow it - you are always a little to the left, then a little too low, then a little too high, and so on. This is more noticeable in a crosswind but it happens even if conditions are perfect.
Pilots use a glide slope indicator (pictured above) to show them how far they’re off from the ideal trajectory and what to do to correct it. In the illustration, the plane is a little too low and too far right. The pilot needs to move left and up to get back on track.
Your agile project can also use a glide slope indicator that shows how you are doing against the “ideal” project path. This can be a burn-up or burn-down chart or, as my teams did it, a simple status list of major project elements, or any other tracking tool. The difference is that you set the expectation that you will be off track throughout the project—always ahead or behind a little in one or another area—and you annotate the tracking tool to explain how you are correcting for error. Next to a too-low burn-up chart line, you write “Cutting scope in config screen”; on an amber status line, you write “adding tests to bring bug rate down”. Each annotation tells the reader why we’re off track and what we’re doing to fix it, just as a glide slope indicator does in an airplane.
As with most methods we’d recommend, the measurement is an invitation to a conversation, and the method reflects and reinforces an understanding you’ve created with your audience beforehand, about the inevitable ups and downs of any software project. As a bonus, it’s also very helpful to the team itself, as it shows trust and confidence that they will get back to the desired path soon, and illustrates the wide variety of methods you can use to achieve that (and not just “type faster!”)