Every enterprise eventually reaches a point where the executive team decides the IT department is moving too slowly. They look at the software development teams—who are happily pushing code to the cloudThe CloudSomeone else's computer that we are now paying a 400% premium to use. multiple times a day—and then they look at the infrastructure engineering team, who just asked for a four-month runway to deploy a new data center core.
To the C-SuiteThe C-SuiteThe people who approve a $5M cloud migration but deny your request for a $50 keyboard., this discrepancy is unacceptable. They conclude that the infrastructure team isn't bound by the laws of physics or supply chains; we are just inefficient.
The mandate is immediately issued: The entire IT department must undergo an Agile TransformationAgile TransformationA multi-million dollar consultant grift that renames all your existing meetings and somehow makes everything slower..
Within a week, a heavily compensated Scrum MasterScrum MasterA meeting coordinator who asks you 'what are your blockers' every morning at 9:00 AM.—who has never actually configured a switch, racked a server, or logged into a firewall Command Line Interface (CLI)—arrives to "coach" the senior network architects. We are told to abandon our ITILITILThe reason it takes 14 approvals to restart a frozen server. processes and our methodical project plans. From now on, the physical network will be managed using strict two-week SprintsSprintsAn endless treadmill of two-week deadlines where the finish line keeps moving..
This is where the corporate fantasy violently collides with physical reality. You cannot manage physical infrastructure with a software development methodology.
The Physics of the Supply Chain
The fundamental premise of Agile is rapid, continuous iteration. A software developer can write a Python script, compile it, test it, find a bug, rewrite it, and deploy it to an AWS container in a matter of hours. The raw material of software is just electricity and thought.
The raw material of network engineering is silicon, copper, and glass.
When the Scrum MasterScrum MasterA meeting coordinator who asks you 'what are your blockers' every morning at 9:00 AM. demands that we break down a massive data center refresh into a two-week sprint, they are ignoring the inescapable reality of the global supply chain. You cannot "iterate" a Cisco Catalyst core switch or a pair of Palo Alto firewalls into existence.
During our Sprint PlanningSprint PlanningA two-hour hostage situation where developers are forced to lie about how much work they can realistically finish in two weeks., the Agile Coach asks what our VelocityVelocityA made-up number weaponized by management to make developers feel bad about their output. will be for deploying the new hardware. I am forced to explain that the hardware is currently sitting on a cargo ship somewhere in the Pacific Ocean because the vendor has a 180-day lead time. The coach frowns, stares at their Jira dashboard, and asks if we can "break the hardware delivery down into smaller, actionableActionableA buzzword used to reject a perfectly good report because the boss didn't want to read it. deliverables to show incremental value."
No, we cannot. You cannot deploy half a router. The vendor does not ship the power supply in Sprint 1, the line cards in Sprint 2, and the chassis in Sprint 3.
We are forced to create a Jira ticket titled "Wait for FedEx," assign it to the active sprint, and flag it as a Blocking Issue for the next twelve weeks.
Pointing the Unpointable (The Backlog GroomingBacklog GroomingStaring at a list of 500 critically broken features that the company has absolutely zero intention of ever fixing. Grift)
Because we are now an Agile organization, we are no longer allowed to just do our jobs. Every single task must be entered into the backlog, aggressively vetted in a Backlog GroomingBacklog GroomingStaring at a list of 500 critically broken features that the company has absolutely zero intention of ever fixing. session, and assigned Story PointsStory PointsCompletely made-up numbers used by project managers to weaponize your productivity against you. using a modified Fibonacci sequence to measure the "complexity" of the work.
This leads to the most excruciating two hours of the week: Planning Poker for Network Engineers.
A room full of senior architects—people who have spent fifteen years mastering BGP route manipulation and IPsec VPN cryptography—are forced to hold up digital cards to vote on how many "points" a physical fiber pull should be.
How many points is troubleshooting a random duplex mismatch on a legacy switch? Is it a 2? Is it an 8? If the physical SFP transceiver is melted, it might take a week to get a replacement. If it’s just a bad cable, it takes five minutes.
Because infrastructure troubleshooting is inherently unpredictable, the story pointsStory PointsCompletely made-up numbers used by project managers to weaponize your productivity against you. are completely fabricated. We just make up numbers to satisfy the Scrum MasterScrum MasterA meeting coordinator who asks you 'what are your blockers' every morning at 9:00 AM.’s Burn-down Chart. We learn that if we estimate a task at 13 points, management leaves us alone. The VelocityVelocityA made-up number weaponized by management to make developers feel bad about their output. metrics the PMO is so proudly displaying to the board are entirely fictional. We are gamifying our own misery.
The Danger of the "MVP" Network
The most terrifying concept Agile introduces to infrastructure is the Minimum Viable ProductMinimum Viable ProductA half-finished, bug-riddled mess that management is forcing us to push to production. (MVP).
In software development, "failing fast" is celebrated. You push an MVP to production. If it has a bug, the users complain, the webpage fails to load, and you patch it in the next sprint. It is a minor inconvenience.
If a Network Architect "fails fast," the entire enterprise ceases to exist.
You cannot deploy a "Minimum Viable Firewall." If you push a half-finished security policy to the edge just to satisfy a sprint deliverableDeliverableThe PowerPoint deck we will present to prove we actually did work this week., you don't get a bug report; you get a ransomware payload that encrypts the corporate SAN.
You cannot deploy a "Minimum Viable Routing Protocol." If you push a sloppy OSPF configuration to meet an arbitrary Friday deadline, you create a routing loop that completely blackholes all Voice over IP (VoIP) traffic across the continent.
Network engineering requires absolute precision, exhaustive testing, and meticulous documentation, because our "bugs" cost the company millions of dollars an hour. Agile treats perfection as the enemy of progress. In infrastructure, perfection is the only thing keeping the company out of the evening news.
The Ceremonial Hemorrhage (The Agile Tax)
The ultimate irony of the Agile TransformationAgile TransformationA multi-million dollar consultant grift that renames all your existing meetings and somehow makes everything slower. is that an initiative designed to make us "faster" actually consumes 25% of our working hours in mandatory administrative ceremonies.
Before Agile, if I needed to update an SD-WAN policy, I tested the code, opened a change request, and did the work.
Now, I am trapped in a ceremonial hemorrhage:
- The Daily Standup: A supposedly 15-minute meeting that always morphs into a 45-minute status report where eight people detail the exact Jira tickets they are looking at.
- Backlog GroomingBacklog GroomingStaring at a list of 500 critically broken features that the company has absolutely zero intention of ever fixing.: Two hours every week aggressively debating the arbitrary point values of physical tasks we already know how to do.
- Sprint PlanningSprint PlanningA two-hour hostage situation where developers are forced to lie about how much work they can realistically finish in two weeks.: Another two hours negotiating with the Scrum MasterScrum MasterA meeting coordinator who asks you 'what are your blockers' every morning at 9:00 AM. about how much work we can "commit" to, despite the fact that a single massive P1 outage will instantly derail the entire sprint.
- Sprint Retrospective: An hour of corporate therapy where we ask, "What went well?" and "What didn't go well?" What didn't go well is that we spent fifteen hours this week talking about Jira instead of configuring hardware.
We are paying premium, senior-level salaries to highly certified engineers, and forcing them to act as administrative assistants for an Agile framework that fundamentally misunderstands their profession. We aren't moving faster. We are just logging our lack of speed in a much more expensive software suite.
You can put a Ferrari engine in a tractor, but it’s still going to plow a field at four miles an hour.
Curious exactly how much capital your company is burning trying to force physical hardware into a software development lifecycle? Stop measuring arbitrary story pointsStory PointsCompletely made-up numbers used by project managers to weaponize your productivity against you. and start measuring the actual meeting waste. Calculate the exact financial damage of your next Sprint PlanningSprint PlanningA two-hour hostage situation where developers are forced to lie about how much work they can realistically finish in two weeks. session with the Corporate Burn Rate Calculator.
