Monthly Archives: July 2011

Agile Landing Zones

Posted on by
Reply

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.

Introducing Landing Zones

Posted on by
2

On an aircraft carrier, the landing zone describes a small section of deck that a pilot must touch down in to land the plane safely. By analogy, a landing zone for a product describes a range of measurable attributes that your product must deliver to achieve the product vision.

Landing zones are useful for products as well as complex projects and programs. For such complex systems it can be difficult to define “good enough to ship” without considering a lot of different factors and making tradeoffs between them. Recently I have been introducing landing zones as one technique for getting a bigger picture on agile projects and programs. I also find landing zones helpful in identifying architecture and design risks and potential required innovations.

I first learned about landing zones from Erik Simmons. Erik is responsible for creating, implementing, and spreading requirements engineering practices at Intel. Long ago, he and his colleagues taught requirements classes at Oregon Graduate Institute. That’s where I met Erik and learned about landing zones. Since then I’ve helped several clients use them for managing complex programs and projects. They are particularly useful when many requirements needed to be considered and it is important not to lose sight of make or break requirements.

Online information about product or program landing zones is scarce (the only other references I found were a brief glossary definition in Tom Gilb’s Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage.

At first glance a landing zone seems nothing more than a glorified table. Each row in the landing zone represents a measurable requirement. Each requirement has a range of acceptable values labeled Minimum, Target, and Outstanding. The goal is to have each requirement within this range at the end of development. Inside the range is the desired value, labeled Target. Minimum, Target, and Outstanding are relative to your budget and timeframe.

Here’s an example of a landing zone for a loan processing system (all the examples I am using are concocted for simplicity’s sake; any relation to landing zones for real projects is coincidental):

Landing Zone for a Loan System
Attribute Minimum Target Outstanding
Adding new loan agreement 2 weeks 24 hours 12 hours
Add new product 3 weeks 2 weeks 1 week
Adjust loan terms 4 days 2 days 1 day
Access loan risk 1 day 6 hours 10 minutes
Assign loan servicer 1 month 1 week 1 day

And another for a smart phone (this one was cooked up by comparing competitive benchmark data):

Landing Zone for Smart Phone
Attribute Minimum Target Outstanding
Battery life – standby 300 hours 320 hours 420 hours
Battery life – in use 270 minutes 300 minutes 380 minutes
Footprint in inches 2.5 x 4.8 x .57 2.4 x 4.6 x .4 2.31 x 4.5 x .37
Screen size (pixels) 600 x 400 600 x 400 960 x 640
Digital camera resolution 8 MP 8 MP 9 MP
Weight 5 oz. 4.8 oz. 4.4 oz.

A landing zone is similar to release criteria, except it allows for tolerances in acceptable values. There isn’t one number you are aiming for; you have a range of values for each product attribute or characteristic you are targeting. This gives you some flexibility in defining what’s “good enough.” You’ll note on the smart phone that the minimum acceptable screen size is exactly the same as the target. This is not uncommon. It just means that there is no margin between your target and what is minimally acceptable. Sometimes the variance between minimum, target and outstanding can be small (this is when you know what your target is and how to achieve it, and are willing to accept only marginally less).

When you have little wiggle room in meeting requirements, you might simply want to define acceptance criteria with hard and fast numbers that simply must be met. I find it helpful to define landing zones for those product attributes that have some degree of flexibility in their outcome.

I like the way landing zones can help bring focus to a lot of complexity. If you are building something really big, you can roll up your product’s success to a few dozen things to monitor (instead of hundreds). In contrast to a list of release criteria, a landing zone also allows you to see a bigger picture and make sense of it: When one attribute is edging below its minimum, what is happening with the others? Are they trending below minimum, too? If so, you have a big problem with achieving your overall product goals. No, and you have a landing zone which allows you to achieve a successful product/system launch even if every requirement isn’t exactly on target.

Most important, landing zones allow you to make tradeoffs in multiple dimensions. The art is in understanding the tolerance for those attributes that define your landing zone, and then selecting reasonable values for minimum, target and outstanding.
If you are defining a landing zone for a new system or product, it may require you to do some research, experimentation, and prototyping to determine appropriate attributes and their values. If you are replacing an existing system, you probably know what capabilities need to be improved (and your minimum values are likely at least as good as the current system you are replacing).

If you have competitors, you will most likely benchmark their products as part of investigating what you can reasonably expect to achieve. For inspiration, look at comparative product reviews. For example see http://cell-phones.toptenreviews.com/smartphones/. Simple criteria, if met, are checked; other cells have explicit values.

Yet what’s good enough? A good landing zone allows for some flexibility in meeting goals without forcing you to accept unreasonable compromises. If all your landing zone attributes fall in the minimum acceptable category, do you still have a viable product? By definition, yes, your product is minimally acceptable. But that doesn’t guarantee its success. It means you have “landed”. You didn’t miss the aircraft carrier, but you are perilously close to the edge. You’d like to be in the target zone for most of the attributes.

In my next post I’ll write about using landing zones on agile projects and how architects can and should be involved in defining, vetting, and recalibrating landing zones.
If you’ve had experiences with landing zones I’d like to hear from you.

Software Architecture Stewardship

Posted on by
Reply

On agile teams, architects do more than design and implement the interesting tricky bits. They typically balance a wide range of concerns: short-term goals, overall system design integrity, risks versus efforts, design expediency.

The successful agile architects I know aren’t ivory tower experts.

They take a leadership role in defining how the system is structured, organized and implemented, as well as how it evolves. They make sure there isn’t a hairball of component dependencies. They are hands-on and engaged in day-to-day development work. They actively ensure that the system is designed in a way that will sustain ongoing, incremental development. They are comfortable writing and refactoring code and figuring out how to fix things and improve the architecture. When things are “broken”, they often step in to help.

An example of this that stands out for me is the story an architect told of how he helped improve the performance of an underperforming website. It was way too slow, and doomed to be even slower unless they reworked the architecture. Over the period of two weeks he worked with a small team to analyze the performance and then refactor the design. He wasn’t a superhero, he just applied his know how, working with the team who knew the deep technical bits. He succeeded in turning this design around because he knew they could improve things once they measured performance, found out where the real bottlenecks were and worked to clean them up (using good design principles and practices). After finding out where bottlenecks were, they first restructured some of the JavaScript code to eliminate several extraneous trips to the server. Then, they cleaned up a couple of service interfaces, cached some data on the service, and eliminated some of the more complex queries. Same functionality; only now the website performed up to snuff. He didn’t view himself as a superhero; just as someone who did what was needed get things back on track. He believed that they could clean things up if he spurred this activity with the right mindset and a fresh pair of eyes; and they did. (Not every attempt at architecture rework has such immediate payoffs….I recognize this, yet still admire his attitude and skill).

The definition of a steward is “someone who manages another’s property or financial affairs; one who administers anything as the agent of another or others”. I like this definition. To me, stewardship has deep implications about the role an architect ideally plays on a team. It means you pay attention, take care, and are responsible for the creation and upkeep of the software. You are responsible for safekeeping the architecture, yet you don’t own the architecture. Sure, you may work out key design details of the architecture, but you are a team player. The system’s success and sustainable development is more important than your own individual technical contributions. While being a technical leader, you also value teamwork. You don’t expect to be the only one coding or designing the challenging or interesting parts. You do what you can each and every day to sustain the system’s architecture.