We all have goals we wish to achieve yet limited resources to realise them.
While we might have a clear picture of what success looks like — be it a certain number of digits on a financial statement, or a sleek new product in the hands of thousands — knowing how to achieve it is far from obvious in today’s rapidly changing, complex world.
In a world of seemingly unlimited unknowns, repeated success does not come from pedantic planning and exhaustive environmental analyses. Instead, it’s a result of approaching the world scientifically and remaining adaptable.
Agile is a methodological framework for building solutions that embody these principles and is celebrated for its ability to rapidly and efficiently produce working solutions.
If you’re in the tech world, there’s a solid chance you’re sick of hearing about Agile methods. Fair enough.
You may still get some value from this post, however, if only for the reason that it could help you explain why Agile is a superior method for building solutions compared to the traditional, linear method known as Waterfall.
The Standard Plan — Waterfall
“Man plans; God laughs.”
— Yiddish Proverb
If you’ve ever sat down and planned something out, like a road trip or a blog post, it probably looked something like a Waterfall project plan.
Waterfall is a linear approach to planning; the process largely flows in one direction. You identify what you need, design it, build it, install it, and maintain it.
Here’s what the ideal waterfall project looks like:
There are two problems with this method:
- Complex undertakings rely on assumptions. The larger a plan gets, the more assumptions are made.
- Even if every assumption is accurate at the time of planning, many things can change by the time a plan is executed.
Here’s what it looks like in practice.
As the nimble Mike Tyson once said:
“Everyone has a plan until they get punched in the mouth.”
Punches can take many forms, delivered by the arms of regulatory bodies, competitors, collaborators and Mother Nature. We can anticipate these as best we can based on the present and the past, but projects are safest when they are designed to adapt to future circumstances.
When executing a Waterfall plan you generally don’t get any feedback until the implementation or testing stage. These are discrete phases at the tail of a Waterfall project, rather than bite-sized experiments distributed from start to finish.
This means that a significant amount of resources could be used, and potentially wasted, before you have any indication of whether or not the solution being built is going to work.
You might say: “Well, at least we learned what didn’t work.”
Exactly, you learned from your mistakes. The point is, how much time and money did you waste learning that lesson?
The focus of an alternative method, Agile, is building a solution and getting feedback ASAP in order to conserve resources and get to the desired outcome as quickly and efficiently as possible.
Agile — What actually works?
The Agile method is an iterative approach to developing solutions.
Instead of making a linear plan and executing it sequence, Agile organisations identify the minimum requirements of a solution and then loop through cycles of building, measuring and learning to get there.
Agile organisations minimise the amount of up-front planning, focusing on testing something in the real world as fast as possible.
Agile’s Epistemic Superiority
When we have an idea for a potential solution, it’s just that — an idea.
Plans, by definition, exist in the ideas space. While this conceptual world may reflect reality, it’s still a gross misrepresentation; a caricature. So long as humans are planning without the aid of perfect simulations, we will never know what the solution will look like in reality until we build it and test it.
The reason for the success of Agile as a method is that it is inherently scientific. By building something and testing it in the real world, we can get data that reflects the world as it is, rather than what we assume it to be.
Constantly testing our assumptions allows us to course-correct more frequently, helping us get to where we want to go faster, or making it apparent when we should consider cutting our losses. This makes Agile organisations more adaptable — a powerful trait in a time marked by disruption and uncertainty.
In the context of Agile, there’s no such thing as failure. There is only feedback.
Agile vs Waterfall — Visualised
Here’s what the two approaches might look like compared in graphical form for a single project:
It’s possible that Agile could be less efficient than Waterfall if everything goes according to plan. However, across a number of projects, this just won’t be the case.
Development across time
A business can be thought of a series of projects run across time. When you take this long-term view, it Agile’s superiority becomes evident.
When you compare the two approaches and sum up total expenditure across projects (as seen below) Agile comes out on top as more resource efficient as feedback is gathered faster.
The following graph represents the same projects expressed as return on investment, rather than expenditure.
This is where Agile’s supremacy becomes all too obvious. When you add up the arrows, Agile comes out on top by a substantial margin.
While this is a gross simplification of the comparison between the two approaches, it helps get the point across.
Over time, Agile proves to not only be the more resource efficient approach for realising complex ambitions but the more profitable one as well. It enables us to identify faults in our plans before we commit too many resources, giving us more to work with across time.
The Arrow of Agile
It’s important to note that many Agile projects are somewhat Waterfallian in nature. Agile organisations don’t build for the sake of building; there is some goal in mind.
Once we have a set of requirement or goals that we wish to achieve (something which some people describe as a North Star), the means by which we get there are there to be explored.
While Waterfall has its place in project planning, it works more like a train than a car. If you’re sure you’re heading in the right direction, that’s fine — full steam ahead. However, if the landscape is going to be constantly shifting — which in this age of digital disruption, it will be — your vehicle should be built to change direction than derail.