Customer experience and the choice between Lean/Agile and waterfall
By Mark Hurst • Aug 14, 2014
Agile agile agile. As companies in every industry move to create digital products and services (and customer experiences!), every team I talk to has some comment on Agile. This is, of course, today's preferred development method for all things digital - much like its counterpart, Lean, takes much the same approach from more of a product management perspective.
But many teams are still grappling with basic questions: what exactly qualifies as Agile? And is it better than "waterfall" (the older development method) at creating the all-important good customer experience?
I spoke recently at the Agile Executive Forum alongside some very skilled executives who have lived the "Agile transformation" that so many companies are talking about. It got me thinking about how to describe Agile, and answer those questions, in a simpler way.
- - -
In some parallel universe, there's New York and there's San Francisco, but no way to travel between those cities. Lots of people want to travel the NYC-to-SF route and are willing to pay. Two project teams start out: one builds a train, and one builds a car.
Waterfall is building a train, and Agile is building a car.
The railroad gets built, and the first train starts rolling from NYC to SF. Halfway across the country, the customers say, "Actually, we've changed our minds - we want to go to Los Angeles." The train drops them off in San Francisco and people say, "You dummies, we said we wanted to go to Los Angeles and you still dropped us off in San Francisco!" The train - representing "waterfall" development - had no way of rapidly responding to changing customer needs. And so the railroad begins laboriously building a new train line to Los Angeles (but when that's done, customers will have changed their minds and want to go to Seattle instead).
The second team, building a car, represents the Agile approach: it's able, in theory, to allow for course corrections in the middle of the journey, based on data that comes in after the trip starts.
What's common across both methods, and perhaps more important than the choice between Agile and waterfall, is the basic foundation of good engineering practices. (Plenty of teams run around shouting "agile," like they want to build a car instead of a train, but have no idea how to assemble a transmission!) If you have a choice between a well-engineered waterfall project and a slipshod Agile project, you'll do better with waterfall.
So let's suppose you do the "right" thing and build a car factory, allowing customers to drive cars from NYC to to whatever west coast city they want to visit. But then the business still fails. Why? No one buys a single car, because customers are suddenly flocking to your new competitor, which is named JetBlue. It turns out customers do want to get from NYC to LA, but they don't want to drive such a long distance. Wrong customer experience. The Agile car project is a flop because it didn't take into consideration the full business context.
Lessons for any team considering Lean-Agile processes:
• Make sure you understand the business case, and that it's informed by strong customer insight. (This is the piece that Creative Good consulting can help with, and which most teams skip over.)
• Be sure that your fundamentals of project management and development are sound. This is more important than following a particular method.
• If you've done all of the above, then consider whether to dive into Agile, waterfall, or some other method. If the market could change quickly, probably use Agile. If it's a static, well-known challenge - perhaps an infrastructure or re-platforming project - choose whichever method (and it could be waterfall!) will get the milestones achieved with the lowest cost and highest quality.
And whatever you do, make sure you include the customer.