Has 'Agile' Become A Leadership Cop-Out?

Agile. Fast. Lean. In a nano-second economy with real-time data and instant updates now being superseded by AI-driven predictions, leaders understandably believe the 'move fast and break things' mantra is the strategy their customers, investors and board members will reward. 

But successful leadership is not about following the buzzword-du-jour. While five year plans and annual reviews are not quick enough to capture the changes necessary to prevail against technologically sophisticated global competition, planning still has an important role in determining the optimal course for an enterprise, its people, products/services and customers. The efficacy/speed trade off requires that leaders lead. JL

Colin Bryar and Bill Carr report in Harvard Business Review :

Agile is a powerful process for product development, but many organizations are taking it too far and using it to avoid careful planning and preparation. The idea of “agile” thinking  has spread to budgeting, talent management, or running a family. The fundamental problem with agile is that its pace biases developers. They want to get a minimum viable product in weeks, so skimp on what the product should accomplish. There’s no time for the careful thinking that breakthroughs require. They go with skills they currently have, accepting existing constraints and tend toward incremental improvements on existing offerings. Speed isn’t everything. Don’t confuse writing code with making progress.

The idea of “agile” thinking or innovation, along with its close cousin “lean,” has spread far beyond its product development and manufacturing roots. It’s not uncommon now to hear about the agile approach to budgeting, talent management, or even running a family meeting.

Agile is a powerful process for product development, but many organizations are taking it too far and using it to avoid careful planning and preparation. They’ll get a better result if they combine it with a different approach that we learned working as executives at Amazon. “Working backwards” can make up for agile’s shortcomings in the crucial early stages.

How Agile Companies Get Ahead of Themselves

Agile might seem perfectly suited for when a company is developing a product or service that doesn’t exist and is looking to move quickly. In these cases, it’s difficult to simply interview customers or watch them in action, because they can’t respond to a hypothetical product.

The solution is to develop a prototype, or minimum viable product. Through a series of sprints, typically lasting two weeks, a product team puts together something that’s good enough to show customers and get their reaction. If the idea bombs, well at least the team got that information quickly and with only a small investment — and maybe they’ll uncover a better idea in the process. If it gets traction, then the team can quickly iterate to create an even better product.

Contrast that with the working backwards approach, which is all about planning. Working backwards emerged in 2004: Amazon’s e-commerce strategies had proven successful, and the company was aggressively seeking new opportunities with a large potential market. Where should it look?

Rather than jumping into developing a plausible product — what an agile mindset might encourage — the company preached going slow to go fast. CEO Jeff Bezos often called himself the “chief slowdown officer,” and he got involved when he thought teams were moving quickly into coding without clearly defining the customer problem and an elegant product solution.

The working backwards approach requires a fully realized vision of a proposed product, embodied in a written press release for the product’s launch. This felt wrong, even unnatural, to software developers and product managers who wanted to get going on coding already. Teams typically spent weeks, if not months, hashing out this press release — along with an FAQ that explained to colleagues, customers, and senior management how Amazon could create this wonderful offering at an affordable yet profitable price. Only when the executives were satisfied with these documents could anyone start writing code and actually assemble the product.

The practice has stuck: To this day Amazon works backwards from what it thinks will delight customers, even if it currently lacks the capabilities to make that product. The Kindle e-reader, AWS cloud computing services, and the Echo voice assistant with Alexa all came from working backwards, at a time when Amazon had little experience in making devices or hosting other companies’ activities on its servers. Yet all three of these offerings became hit products. Over time each has attracted competitors, but they continue to hold the largest market share.

Speed Isn’t Everything

The fundamental problem with agile, as many companies use it, is that its relentless pace biases developers. They want to get out a minimum viable product in only a few weeks, so they skimp on scoping out just what the product should accomplish. Or worse, in our experience, they make two kinds of compromises.

First, rather than take the time and uncertainty to develop a new capability, they go with the skills they currently have. They accept their existing constraints, which automatically limits the potential for a high-growth offering.

Second, they curtail their ambitions on the product. Instead of a major breakthrough, they tend toward only incremental improvements on existing offerings. Or if they do go bold, their minimum viable product isn’t really viable at all, so customers can’t give realistic feedback. The developers haven’t had time to do their homework and prepare something that’s sustainable.

The team tells itself that whatever information they get is still valuable toward some future breakthrough product. But that future rarely comes. Too often, the process of two-week sprints becomes the thing, and the team never gets the time and space to step back and obsess over what is needed to truly delight customers. Teams think in bite-sized chunks based on the resources that they already have — there’s no time for the careful thinking that breakthroughs require.

Agile proponents worry that a working backwards approach takes the authority and urgency away from teams to launch new code, get feedback from customers, and iterate rapidly. But speed isn’t everything, especially when it comes to breakthrough products. Don’t confuse writing code with making progress per se. By working backwards, you can actually get a successful product to market faster.

How to Make Agile Work Better

We’re not arguing that companies should throw agile out the window. It’s still a highly effective tool for product development, especially software-driven offerings. Many of its principles and processes have been used successfully by Amazon and other companies. After all, most product development involves only incremental changes. You don’t need a lot of thought around these improvements. Just put together two rough alternatives and try them out in the real world, where you’ll get vital feedback.

Teams with breakthrough products can benefit from agile as well, once they’ve done the kind of advance work involved with the working backwards approach. When you’re in the coding and product construction phase, you want to move quickly and avoid getting bogged down. Sprints keep you on track and ensure that you actually get something to market.

The best solution, then, is to combine agile with something like working backwards. Amazon, for example, has learned to use the working backwards process for idea development, but then follow agile to build and ship the product. If a giant like Amazon can switch course like that, then even startup companies can follow suit.