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.
Agile isn't scrum, XP, or Kanban. Agile is merely a way of reducing the cost of uncertainty and change. If your project is close to the novelty phase of its market evolution, you'll have a lot of uncertainty and change. In this situation, agile (reducing the cost of change) is a great choice. But if your product falls into the stability and commodity phases, consider switching to a lean methodology (minimum viable feature set with rapid development, reducing the cost of waste). Finally, if your products are commodities that are perhaps evolving into utilities, consider techniques such as Six Sigma (reducing the cost of inconsistency). Why? Because they focus on reliability and reproducibility. Optimizing to lower the cost of change and uncertainty doesn't make sense when you already have little change or uncertainty.
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.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
