When to Choose Agile

A fellow agile trainer recently told me that many of his customers are fleeing scrum to get away from the zealots. I sighed and nodded in agreement—all too familiar with those agile enthusiasts who repeat the "agile isn't a silver bullet" mantra—and then proceed to recommend it for everything.

Most would agree that not everything must be agile, but when you ask for examples of what the agile methodology isn't good for, you get blank stares. To figure out when you should and shouldn't use agile, you need to understand how products evolve in the market, determine where your product fits on that continuum, and reexamine agile in that light.

The four phases of product evolution

Products tend to evolve through four maturity phases. Each has unique characteristics and should be treated differently. They include:

1. Novelty: This is the "gee whiz" phase, where a new and exciting idea emerges and people begin to wonder what can be done with it. For example, when online shopping first emerged, people wondered if you could sell clothes, food, or cars online. Would people trust you with their credit card information? Was there really a market for people buying goods from faceless, anonymous entities online? We know the answers now, but we didn't then.
2. Stability: This is the phase when people start to understand what they can do with a given product. The focus shifts from what can be done to how to do it. Remember all those "how to build a shopping cart" books and articles in the late '90s and early '00s? This was online shopping transitioning from novelty to stability.
3. Commodity: This phase kicks in when the market has stabilized enough that for most companies, building their own version of a product doesn't make economic sense. Instead, there are enough competing products out there that acquiring the product off-the-shelf is simpler and cheaper.
4. Utility: This is where you no longer purchase a product, but you consume it as needed, just as you would with electricity. Shopify, Etsy, and many other e-commerce utility solutions are readily available.

Of these phases, the novelty and utility phases are the most interesting. What makes the novelty phase interesting is obvious—startups make fortunes in this area. However, the utility phase is also fascinating if you're the one providing the utility. Products in the utility phase tend to be high-volume, low-profit systems. Entire industries are built on them. Electricity started out as a novelty and today is a well-established utility with industries such as television, radio, and computing built on top of it. Cars are going through this phase: with the rise of Uber, Lyft, and self-driving cars, the market is facing the prospect of cars becoming utilities. Someone is going to make billions when they figure out how to exploit the new markets built on top of this change.

One characteristic of the novelty phase is the rapid change and uncertainty. This doesn't exist for the utility phase—customers will be reluctant to consume your utility if rapid change and uncertainty is another price they have to pay.

Agile's job: To reduce the cost of change and uncertainty

Once you understand where a product is in its evolution, the appropriate use of agile should become clear. Agile is nothing more than a method of reducing the cost of change and uncertainty.

This is reinforced by the fourth point in the Agile Manifesto: "responding to change over following a plan." In fact, while many have read the Agile Manifesto, few have read the twelve Agile Principles associated with it. Many of the principles reinforce the point that agile is about embracing change and lowering cost. If you think agile is all about standups, short iterations, retrospectives, story cards, and so on, then you've missed the point. You're not alone: many practitioners have been misguided because agile is often taught as a set of behaviors, with little reference to the goal beyond vague mentions of side-effects like improved time to market, customer satisfaction, and lower startup costs. It's like teaching people the moves of chess and not teaching them about checkmate. In this light, scrum, Extreme Programming (XP), Kanban, and other methodologies are tools you use after you've already decided on an agile approach.

So when should you choose agile? When you understand both agile and product evolution, the answer is simple: the newer the product and its market, the better fit with agile.

Agile works best in environments with the expectation of change, when you need to optimize for uncertainty. Products in the novelty phase definitely benefit. However, what if you pretty much do know everything up front? What if there is little change and uncertainty in your environment? One agile mantra is to "fail fast." Do you really want to fail fast if you're building a nuclear reactor? Of course not. Nuclear reactors are one attempt to implement the utility of electricity.

Not for everyone

Many agile practitioners object at this point. They insist that you can simultaneously optimize for change, uncertainty, reliability, and reproducibility. For those people, here's a thought experiment. Imagine you've decided to create a tool to allow job applicants and companies to rate recruiters. Using crowdsourcing, you can start to identify the best recruiters for your needs. Put five excellent, independent agile teams on this project and you'll have five different products at the end. Reproducibility simply isn't something agile was designed for.

Don't get me wrong: I'm a huge fan of agile. I've happily embraced it for years, and I enjoy working in agile environments. But it's time we end the tyranny of agile and recognize that it's merely another tool in the toolbox. Agile is a great hammer, but not everything is a nail.

Note: I originally published this article on TechBecon.