In my last post I introduced the idea of landing zones, a set of criteria used to monitor and characterize the “releasability” of a product. A landing zone contains system attributes that must be achieved to declare “success” along with their minimally acceptable, ideal target, and outstanding values.

If you’re unfamiliar with landing zones, one concern you might have is the size of a landing zone. How many discrete system characteristics can you reasonably expect to track? At first blush, you might expect that the more complex a product or system, the more attributes should be tracked.

But an agile mindset leads me to a different answer: You don’t want to keep your eye on too many dials and gauges. It’s simply too difficult to monitor that many constraints for most projects. Yet you don’t want to have too skimpy of a landing zone either. A handful of disconnected system attributes isn’t worth much. You want to capture the essential success criteria in your landing zone. Things that are both important and measurable.

If you have more than a few attributes, it can be helpful to organize them according to category: e.g. cost, performance, data quality, reliability, usability, etc.). One large multi-year program I know of had a separate landing zone for each functional area (which was comprised of dozens of applications and services). In each functional area, dozens of individual landing zone characteristics were tracked. Establishing and monitoring landing zone for a phased-release or multi-year product or program can be a big challenge. How can you establish accurate target values for what’s going to be delivered two years from now? You may not be able to. But you do your best given what you know now and what you can reasonably project for the near future. Agile teams believe it is better to plan to replan than to over specify the future. If you embrace agile values you need to get comfortable with periodically re-planning and readjusting your targets. You should strive to firmly nail down parts of a landing zone that you expect to achieve over the next few months, leaving the rest of your landing zone purposefully sketchy.

And when new evidence comes to light, you likely will need to readjust your landing zone. What initially appeared to be achievable or reasonable targets can shift in light of new facts or market changes. No one wants to deliver yesterday’s product to today’s market. Landing zones, like release criteria can and do change. When they do, people have to make informed decisions to readjust targets. For instance, you may have worked hard to meet some early achieved landing zone targets, only to find out that your early decisions had negative consequences on future work. You may have created some technical debt that either needs to be paid off (with interest) in order to achieve your next targets. But given time or budget constraints, you may decide to recalibrate your landing zone (and set expectations lower).

A landing zone is rarely cast in concrete. Things that can wiggle around and get more defined over time should be allowed to do so. But as your system architecture emerges and requirements inevitably change; it still helps to have concrete targets to shoot for. And the more precise the landing zone criteria are, the easier they are to design for and verify. I’ll say more on that in my next post.