The Four Dimensions of Adaptability

I was reminded recently that people think of adaptability in too few dimensions. To me adaptability and agility are synonyms characterized by “the ability to both create and respond to change.” I might extend this definition to include both anticipated and unanticipated changes. If we know something is going to change—product prices for example—then we build appropriate flexibility into our software systems. Unanticipated changes, however, call for adaptation, a step beyond flexibility. The four dimensions of that adaptability are:

  • People
  • Process
  • Product
  • Architecture

I’ve seen organizations embrace agile development methods, thinking they will solve responsiveness problems, only to realize that an agile team and process won’t overcome the complications of a 20-year old legacy application with no automated tests; snarly, smelly code; and an antiquated architecture.

The core objective of product development in today’s volatile business environment is to “deliver a continuous flow of value to customers.” We have to deliver a product today, and revise it tomorrow, and enhance it the next day, and augment it the day after that. Some of these changes will be anticipated in the product’s vision map while others will be unanticipated, arising from unexpected uses of the product. Skimping on product adaptability (one quality dimension) has a significant impact on the future, and the future is tomorrow.

Of the four dimensions of adaptability—people are the most important. Teams must move beyond prescriptive agile to adaptive agile—in fact, move to the point where these descriptive adjectives of agile are no longer needed. Too many teams have a set of agile rules—do this, don’t do that—which is necessary when learning agile, but lack the capability to tackle hard unanticipated changes on real product development efforts. While teams do retrospectives and reflections, they often don’t go far enough in challenging their own preconceived notions of agile.

An adaptive team understands that plans are hypotheses, that pivots may be necessary, that performance measures need to be focused on value and cycle time, that self-organizing teams produce necessary innovations, that cycle time depends on quality, that development is a process of learning new things and adjusting accordingly, and that change is the norm—not the exception. Adaptive team members realize that the most difficult problems are really paradoxes and that the solutions are temporary resolutions. They realize that change is the norm, not the exception.

Adaptive teams understand that process—even agile processes—are guidelines not standards. They aren’t intimidated by what the agile experts say, they adjust to fit their particular situation. Adaptive teams also need to explore processes beyond the agile basics—from Kanban to Lean Startup.

You might think that product and architecture should be combined in the list above, however I separated them to give an extra emphasis to architecture. I worked with a product architect several years ago who built facilities into his company’s product to handle multiple languages. He anticipated the need for this flexibility. Some in the agile community might say that this “anticipation” of change was the wrong strategy—however building in the flexibility or capability to handle anticipated changes can save significant time and cost later. The secret is balancing anticipation and adaptation.

However, we also need the ability for architecture to respond to unexpected changes—the ability to adapt. Object-oriented design, SOA, re-usability, re-configurability, specialized languages, and more point to the need to consider “adaptable” architecture issues early. Martin Fowler, for example, has a series of blog posts on application architecture. Doing and being “agile” involves both developing skeleton architectures up front and then evolving them over time. Choices involving product architecture and the development environment will impact adaptability. Take, for example, the choices around mobile development platforms. Do you develop in multiple native languages that may provide a more sophisticated user experience, or in a multi-platform language that will be less expensive and time consuming to enhance over time? These are not decisions to be made halfway through a release.

A huge issue with the adaptability of products is technical debt. I was talking with an old friend (an in long-time, not age) recently who had gone to work for a startup company that had been in existence a couple of years. In just those couple of years they had managed to inject an incredible amount of technical debt into the product and his strategies for recovery involved wrappings around old code, ramping up testing significantly, and judiciously investing in refactoring. I once worked with a company whose electronic instrument software was so bad they invested 9 months in testing and refactoring for the next release (no new features)—even though the product was being replaced in the not-to-distant future!

Technical debt is insidious because it sneaks up on people over time—sometimes not so much time. As technical debt rises, not only does development time and cost increase, but estimating becomes almost impossible. During the 9 month release mentioned in the last paragraph, the team operated with only a very rough schedule—the product had gotten so convoluted that estimates of time to refactor and test were impossible. At first they envisioned a 3-4 month project, but the snarly code took longer to unravel. However, management’s primary goal for the project wasn’t schedule, but putting the product back into reasonable shape. And, the customers were ecstatic about the new release because it didn’t crash anymore!

Adaptability, the ability to respond to both anticipated and unanticipated changes, grows in importance as the rate of business and technology change accelerates. It’s not enough to have agile people, or agile processes, or an adaptive architecture, or low technical debt—you need all four.