In a previous article, I dismantled the nonsense of Agile-Waterfall-Agile hybrid and argued that Agile is, at its core, a mindset about adaptability, iteration, and learning—not a rigid delivery sequence. But that article stirred a fair question: Can you really apply Agile to infrastructure when it involves physical hardware? Routers, switches, racks, cabling—the stuff you can actually trip over.
Short answer: Yes, you can. But you have to stop thinking like a landlord and start thinking like an architect.
Infrastructure Isn’t Exempt from Agile Thinking
No, you can’t iterate on a router the way you do on a line of code. You’re not replacing a switch mid-sprint just because someone changed their mind. But that’s missing the point.
Agile isn’t about moving fast—it’s about reducing the cost of change, even in high-friction environments like data centres.
You apply the mindset differently, but the principles still hold:
- Deliver in slices: Start with minimal viable infrastructure (MVI)
- Validate assumptions: Run real workloads early to test your architecture
- Adapt based on evidence: Don’t buy 40 switches if 8 will do and scale later
- Automate everything: Provisioning, configs, even firmware updates
If you’re still racking and stacking without version control or reproducibility, you’re not doing modern infrastructure—you’re doing archaeology.
The House Analogy (Revisited)
Yes, you need to pour a foundation. But you don’t need to build the entire house before testing whether the plumbing works.
Physical infrastructure can be phased:
- Phase 1: Minimal power, cooling, and core switch fabric
- Phase 2: Install a single rack and validate baseline workloads
- Phase 3: Expand storage and compute as needed
You test as you go. You adapt. And you don’t wait until the end to discover the HVAC can’t handle the heat output. That’s Agile. Just heavier.
Agile Infrastructure Rollouts in the Real World
Here’s what Agile infrastructure might look like:
- Sprint 1: Validate physical space, power, rack dimensions, delivery timelines
- Sprint 2: Set up core switch and a single test server
- Sprint 3: Install hypervisor, automate provisioning, test networking
- Sprint 4: Expand with storage array, configure monitoring and alerting
Each layer adds value. Each sprint validates assumptions. You’re not waiting until the very end to discover your cabling plan is a rat’s nest.
Where Agile Doesn’t Fit (and That’s Okay)
Some aspects of physical delivery will never be Agile in the purest sense:
- Long lead times on hardware
- Shipping delays
- Physical installation constraints
You don’t iterate on the delivery truck. But what you can do is design your process to absorb change later: modular layouts, extra capacity, flexible power configurations, and—most importantly—documentation that isn’t locked in someone’s head.
Final Thought
If your infrastructure rollout can’t respond to new requirements without weeks of rework, it’s not the hardware that’s inflexible—it’s your thinking.
Agile isn’t about how fast you move. It’s about how easy it is to change direction.
And yes, that applies even when your tech has weight.