We're hiring experienced Perl developers for full-time remote contracts on a number of projects. If you are interested, email me. We also have one potential role for an experienced Python developer with OpenAPI + ORM experience.
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.
Products tend to evolve through four maturity phases. Each has unique characteristics and should be treated differently. They include:
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.
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.
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.
Please leave a comment below!
Copyright © 2018-2022 by Curtis “Ovid” Poe.