I once worked with a chap who proudly described his delivery method as: “We do an Agile, then we Waterfall into another Agile, and then Waterfall into another Agile…” I’m sorry, what? That’s like saying We’re vegetarian, with occasional steaks between the tofu. It sounds clever until you realise it’s complete nonsense. Worse, it betrays a total misunderstanding of what Agile actually is. It’s not Agile. It’s what some call fake Agile — a broken hybrid that pretends to be flexible, but delivers none of the benefits.
Why Fake Agile Isn’t Real Delivery
Agile is not a set of ceremonies. It’s not just daily stand-ups or Jira boards. It’s a mindset, a way of thinking about work and value:
- Responding to change over following a plan
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
What he described was not a delivery strategy. It was a chain of gated, mini-Waterfalls in Agile costume. Each “Agile chunk” was a safety bubble before the next over-planned tunnel. And when you build like that, you’re not being Agile. You’re just doing Waterfall with commitment issues.
So What Happens When Fake Agile X Was Wrong?
Here’s the fatal flaw in Waterfall into Agile into Waterfall into Agile: What if you realise, halfway through, that a previously delivered Agile X was based on the wrong assumption?
In real Agile, you’d inspect, adapt, course-correct. But in the Waterfall mindset, you draft a change request, go through governance, and hope nobody gets fired. If your only way to change course is to go back two waterfalls, you’re not being Agile.
Agile embraces change. Waterfall punishes it.
Agile Architecture Is About Planning for Change
Real Agile architecture isn’t afraid of change—it plans for it:
- Build loosely coupled modules
- Prototype to expose risk early
- Automate to make change safe and fast
- Validate assumptions incrementally
The Agile architect asks: How can I make the cost of change cheap later? That’s not just technical; it’s strategic.
You Don’t Have to Ship a Final Product Every Sprint
Another common myth:
Agile means shipping a shippable product every two weeks
Wrong. Agile means delivering value every sprint. That might be a testable stub, an integrated API, or a validated assumption. You might be building a larger feature across multiple sprints—that’s fine, as long as you’re learning and improving with every slice.
Yes, You Can Do Agile for Infrastructure
Another classic line:
You can’t do Agile when delivering infrastructure. We need IAM, DNS, servers, and pipelines all in place before development starts.
No. That’s not a law of physics. That’s a legacy habit.
- Infrastructure is work. It belongs in the backlog.
- Infrastructure today is code. Use IaC. Use pipelines. Version everything.
- You don’t need it all upfront. You build the minimum to support your next iteration, then evolve.
Real Agile infrastructure might look like:
- Sprint 1: Basic IAM, dev environment
- Sprint 2: Pipeline scaffolding, network layer
- Sprint 3: Monitoring and logging
You’re not moving the family into a construction site. But you’re testing the boiler, running power to sockets, and validating your design before the roof goes on.
The House Analogy—and Why It Still Supports Agile Thinking
Yes, building infrastructure is a bit like building a house. You can’t live in it without floors and plumbing. But that doesn’t mean you build the entire mansion end-to-end before testing if the taps work.
You build in layers:
- Foundation
- Frame
- Electrical
- Plumbing
- Walls
And at each stage, you can test and adapt. Maybe the walls need extra insulation. Maybe the wiring needs rerouting. Agile doesn’t mean skipping essential steps. It means building just enough to add value, getting feedback, and adjusting continuously. Agile architecture asks: Can I swap the kitchen later? Can I convert the attic? Can I extend the deck? You plan for growth. You avoid rigid decisions early. And you build flexibility into the structure.
Final Thought
If you find yourself saying things like “Agile, then Waterfall, then Agile again,” stop. You’re not describing a clever hybrid. You’re describing a broken process. Agile isn’t about speed. It’s about adaptability. It’s about learning fast and adjusting without drama.
And if your infrastructure or architecture can’t handle change without fear, then no matter what you call it, you’re not being Agile. You’re just sprinting in a straightjacket.
Leave a Reply