Choosing between traditional and adaptive development

The Iron Triangle of scope, schedule, and budget is fundamental to managing software delivery initiatives. Two general approaches are available for managing this aspect of delivery. With the traditional approach, we try to identify all needs, risks, and costs in advance and create a detailed, comprehensive plan before beginning development. With the adaptive approach, we begin with a vision for the product and incrementally evolve the solution based on feedback from stakeholders. Either way, we must deal with scope, schedule, and budget. However, the mechanisms we use are very different with each approach, and the metrics we can use to steer the initiative are different as well.

There are two key factors to consider when choosing an adaptive or traditional approach to Iron Triangle management: Urgency and uncertainty. Generally speaking, when either urgency or uncertainty is high, an adaptive approach is called for. When both urgency and uncertainty are low, a traditional approach is called for. It’s only fair to say that the choice is not always obvious.

Urgency

In the context of software development and delivery, urgency refers to time-to-market pressure. Independently of uncertainty, high urgency grants us little time for up-front analysis. We have to get some sort of solution into place by a date certain, or business consequences will ensue. The consequences may be loss of first mover advantage in a new market; dramatically lower return on investment due to missed sales opportunities (possibly seasonal, for instance); financial penalties for failing to meet regulatory requirements by a specified date; or similar costs.

Note that urgency does not describe the case when a high-ranking executive has a certain pet project he/she is keen to do; nor does it describe the case when a senior technical person is eager to get a favorite leading-edge technology into the company so that he/she can play with it. Urgency is a business consideration.

Uncertainty

Uncertainty has been defined as "the gap between the information required to perform a task and that already possessed by the organization" (Laufer & Howell). Laufer further classifies uncertainty into two types: End uncertainty and means uncertainty.

Everyone (well, mostly) agrees that we can’t know every detail about a solution in advance. What is less clear is exactly how much we need to know in advance in order to justify taking the traditional approach to an initiative. (Yes, you read that right: You have to justify using the traditional approach; history has not been kind to it, with good reason.)

We will definitely know the business capability that the initiative is meant to support. Otherwise, the initiative would never have been started. What we may not know in advance, however, is exactly what that support will ultimately look like (end uncertainty), or exactly how best to build it (means uncertainty). When one or both those factors has to be determined empirically through the direct experience of creating the solution, then we will tend to choose the adaptive approach to development.

To illustrate, let’s consider a few common types of initiatives that corporate IT departments carry out.

Example 1: Router replacement

Scenario: Your information security group recommends that you install two different brands of routers on the corporate network. They reason that a hacker who discovers a way to get through one type of router may be foiled when he/she reaches another router of a different type. Currently, all the routers in the environment are the same brand.

You are assigned to manage a project whose goal is to replace about half the routers in the environment with a second brand, and ensure everything still works properly. Let’s say that will be around 1,500 routers in 20 locations, just to set some sort of scale for the initiative.

Does this call for a traditional approach or an adaptive approach? The business capability to be supported is clear: Improved information security. What about urgency and uncertainty?

Urgency is low: There are no imminent threats and no fires to put out, there is no regulatory requirement to do this, and there is no market pressure. Based on urgency, there is no reason to think the overhead of the adaptive approach would be repaid. (Yes, you read that right: There is no magic in the adaptive approach; frequent feedback and high collaboration have costs and you had better be sure those costs are repaid by the results.)

End uncertainty is low: It is easy to see that the end result will be the same number of routers as we currently have, serving the same roles in the same places in the network.

There is some level of means uncertainty: Our technical staff have not worked with the new brand of router before. On the other hand, routers are commodity items and the staff have worked with a number of other brands of routers in their careers. It is reasonable to expect the new routers will not be radically different beasts from any other type of router.

This seems to be a good candidate for the traditional approach to Iron Triangle management. We can calculate the cost of the new devices and software licenses. We can predict some amount of time will be needed for lab work to learn how to configure the new devices and to verify the network will still function in the same way when they are installed. We can predict some amount of time for the rollout.

If we are using a devops approach to this type of work, we might plan for 5-6 weeks of lab work, resulting in scripted configuration and rollback procedures with automated tests, followed by a one week rollout, or less. If we are using old school manual methods, we might plan for 1-2 weeks of lab work, followed by a 12-16 week rollout, and allow for additional production support resources to deal with misconfigured routers, of which there will inevitably be a few just because of the manual approach. In either case, it is a straightforward traditional-style initiative.

Example 2: Application server implementation

Scenario: After some years of ad-hoc growth, the company has reached a point that it needs a well-thought-out technical infrastructure that includes, among other assets, application servers that have the capabilities necessary to support the company’s growing transactional workloads.

You are assigned to manage a project to select and implement an appropriate application server product.

Does this call for a traditional approach or an adaptive approach? The business capability to be supported is clear: Improved technical infrastructure. What about urgency and uncertainty?

Urgency is low. Remember that urgency, in this context, refers to time-to-market pressure. In this case, you are receiving a lot of noise from technical staff, particularly from the enterprise architecture group, about the importance of having high-end application servers in the environment as quickly as possible. Objectively, however, the current state of the technical infrastructure is adequate for the company’s short-term needs. They are simply eager to play with new technologies. It is actually a very positive attitude about work, on their part. But their enthusiasm for technology is not a decision factor for you.

End uncertainty is low. The vision for the end result is quite clear: A server farm capable of handling projected operating needs for the next few years.

There is some degree of means uncertainty. The technical staff have identified three products that may offer the capabilities the company needs. We need a practical way to choose one of these three products.

In the old days, the only approach that would have been considered is to invite the three vendors to make presentations about their products, and to analyze all available marketing literature about them. Then, the company would make a large wager on one of the products. In a way, this approach resembles the Monty Hall problem.

Monty Hall was the host of a television game show in which contestants were presented with three doors. A prize waited behind one of the doors. After selecting a door, if it was not the prize door the host offered the contestant the opportunity to change his/her mind about which of the two remaining doors to choose. Most people tend to stick to their original choice, possibly due to a cognitive bias that reinforces decisions we have already made, such as neglect of probability or choice-supportive bias. Statistically, however, it is advantageous to switch. By switching, you improve your chances from one in three to two in three.

When we take the traditional approach to the project to implement a new application server, we are playing the same game. We have a one in three chance of choosing the best product for our needs based on the sales presentations and marketing literature. That gives us a two in three chance of making the wrong choice. When we discover our choice was not the best after all, we have already sunk so much money, time, effort, and ego into it that we cannot easily switch. The tendency has been not to switch in any case, for the same psychological reasons as contestants on the game show tend not to switch doors.

In reality, this sort of problem calls for an empirical approach. Our technical staff must lay hands on the three candidate products and work with them directly, even if only in a lab environment, in order to get a sense of how they really work, how difficult they are to live with, and whether they will introduce technical dependencies on other parts of the technical infrastructure. This raises our chances of making the right choice to three in three. Those are pretty good odds, I think.

Thus, the degree of means uncertainty is actually much higher than it might seem to be at first glance, and the level of business risk is higher as well. Although application servers are commodity items, they can and do have some significant differences. The best fit for one environment may not be the best fit for another. Merely comparing lists of technical features will not expose all the differences in manageability, supportability, and cost of ownership, nor will they identify any issues we may have in integrating each product with our technical infrastructure.

In addition, it is not objectively true that every enterprise requires the absolute best-in-class product in every category irrespective of all other concerns. Instead, it is necessary to match cost of ownership with the value returned.

In this case, we prefer to take an adaptive approach. We might choose to take a page from set-based concurrent engineering in this sort of scenario, and run three proof-of-concept initiatives concurrently. Another advantage of the adaptive approach is that it opens an additional option that is not obvious when we are thinking in terms of vendor sales presentations: The cloud. A fourth proof-of-concept can be done using cloud services without incurring any additional business risk.

It isn’t that adaptive methods somehow make us aware of cloud services; they certainly don’t. It’s just that once we’ve settled into a certain line of thinking it’s hard to get outside the box again. In this case, the line of thinking is "invite vendors to make sales presentations." We want to remain focused on "application server capability to handle transaction load X under conditions Y with cost of ownership Z."

This example shows that even a straightforward technical infrastructure initiative can benefit from the adaptive approach under some circumstances. Adaptive development is not necessarily limited just to business application development.

Example 3: Customer self-service application

Scenario: The company would like to provide an internet-based self-service facility to customers who need answers to routine questions or help with routine problems, to alleviate the workload at the call center and to free up support personnel to deal with more significant customer issues. Customers have been complaining about slow customer service, and some have already dropped us and taken their business to competitors.

You are assigned to manage a project to develop this facility.

Does this call for a traditional approach or an adaptive approach? The business capability to be supported is clear: Improved customer service. What about urgency and uncertainty?

Urgency is high. Customers are complaining and jumping ship. Competitors are already providing self-service facilities that we lack. The longer we delay in getting something usable into the hands of our customers, the more market share we will lose. We don’t have to provide the perfect solution in the first release, but we do have to provide a workable solution quickly.

Recalling that we prefer the adaptive approach when either urgency or uncertainty is high, we could say that our analysis is complete at this point and we know which approach to use. But urgency is not the only factor that draws us toward adaptive methods in this case.

End uncertainty is high. The user experience is going to be a critical success factor here. We have to keep customers from moving to our competitors, and we have to make our systems compelling enough to bring some of our lost customers back to the fold. That means the design of the user interface and the user experience generally have to meet or exceed customer expectations. We don’t have time to spend a year doing market research.

Means uncertainty is not an issue. Our technical staff know how to build applications for web browsers, smart phones, and various other consumer devices. We need to take an adaptive approach because of end uncertainty. We want to build more than one solution and test the solutions against the real market in real time, incrementally delivering functionality and conducting empirical market research by using A/B testing in the field. Feedback will be live and in production. The traditional approach does not include any mechanisms to support this, so it is out of the question.

A word on agile development

Many people assume that if they use agile methods then they are automatically doing adaptive development by definition. While it is true that agile methods were conceived with adaptive development in mind, the two are actually separate concepts that have no dependencies on one another. In fact, nearly all agile projects I have worked on, seen, heard about, or read about have been carried out in the context of a traditional approach to the Iron Triangle. Only a handful have been genuinely adaptive projects. They ran iterations, they used continuous integration, they practiced test-driven development and pair programming, and used other practices associated with agile development.

But they also had the project budget allocated in full in advance, defined 100% of scope in advance, and committed to a final delivery date in advance. Most of them enjoyed little or no direct collaboration with stakeholders, and had no feedback other than the business analyst re-writing sections of the requirements document in the form of user stories. These are not characteristics of adaptive development.

Some people will insist that as long as a process includes provisions for change control, then it qualifies as "adaptive," no matter how clumsy or frustrating those provisions are. Beware. If you try to run a project as if it were adaptive when it really isn’t, you will soon find yourself grinding painfully against the grain of the universe. And that’s no fun.

I mention this only as a word of caution. It’s all to easy to fool ourselves by making assumptions about buzzwords. You need to look at the way things are actually done, rather than the labels with which they are decorated. And be aware that "agile" does not necessarily mean "adaptive."

Conclusion

In real life, we don’t often have free rein to choose our approach to Iron Triangle management on a case-by-case basis. More often, things are done in a certain way in each organization, and that’s that. But when you do have the luxury to choose an approach, you can do so based on objective criteria, and it turns out not to be a terribly complicated decision. It’s good when useful things are not terribly complicated.

Perhaps more interestingly (as it will occur more frequently), when you inherit an initiative already in progress that seems to be grinding painfully against the grain of the universe, you might be able to perceive that the initiative was set up from the outset with the wrong assumptions about Iron Triangle management. That is often the root cause for delivery problems, after all. If you are able to explain why that is so, you might be able to do something about it.