Javier Castro

Posted on Aug 19

The Agile Consultant Left the Building. The POS System Is Still Running Windows 7.

#softwareinsidenontechindu

Retail's internal software teams aren't failing because they lack Agile ceremonies. They're failing because those ceremonies were imposed on organizations that never agreed software was their actual business.

Picture a sprint retrospective at a mid-sized regional grocery chain. The Scrum Master — brought in eighteen months ago from a healthcare IT consultancy — is asking the team what went well in the last two weeks. Around the table: two developers who maintain a point-of-sale system that has been running on the same vendor-supplied monolith since 2014, a business analyst who used to be a store operations manager, and a "product owner" whose actual job title is still "IT Project Coordinator." The retro wraps up in twenty-two minutes. The action items from the previous retro are still open. Nobody mentions the three production incidents from the last sprint because those are tracked in a different system owned by a different team that doesn't attend the retro.

This is not an edge case. It's Tuesday.

Here is the uncomfortable claim worth making plainly: most Agile transformations inside retail IT departments aren't failing because the teams don't understand Agile. They're failing because Agile was never the real problem. The real problem is that retail IT has been structurally organized to resist the one thing Agile requires — genuine authority to make decisions about what gets built and when. You can't sprint your way out of a vendor contract.

The Monolith in Aisle Seven

Retailers are often trapped by legacy-led monolithic POS systems from large vendors, and the trap is more elegant than it looks. These systems arrive as end-to-end solutions — hardware units, peripherals, and a monolith software stack — that severely limit the retailer's ability to ship new features. Vendor lock-in creates a dependency on the vendor's roadmap, and the licensing costs deliver little visible return. The internal development team, if one exists at all, is left maintaining integrations, writing workarounds for edge cases the vendor's support team considers "working as intended," and pleading with procurement to approve a middleware license renewal.

The vendor owns the roadmap. The retailer writes the checks.

Traditional retail IT infrastructures tend to be monolithic, built on vertically integrated customized hardware — and modernizing them isn't a matter of courage or methodology. It's a matter of organizational gravity. Retailers have often spent ninety years building process and bureaucracy in hierarchical organizations that are very difficult to change. That's not an exaggeration for dramatic effect. Legacy here means something deeper than old code. It means the organizational assumptions baked into the system: that IT exists to support the business, not to be part of it.

Maintaining legacy technology consumes as much as 80% of some organizations' IT budgets. In retail, where margins are already brutally thin, that figure has a particular cruelty. Most of what the internal team does isn't building anything; it's keeping the lights on. And the budget structure tends to treat that as confirmation that the team is indeed a cost center, not a strategic function — which then makes it harder to justify the investment to escape the trap. It's a loop, and it closes quickly.

When IT Is a Cost Center, "Agile" Becomes a Measurement Tool

A cost center's performance is typically measured on adherence to plans and budget. Efficiency and compliance matter. Effectiveness and value generation, less so. That framing explains why Agile sprints feel performative in retail IT: the organization isn't measuring delivery speed or customer impact. It's measuring whether the team stayed on budget. Under those conditions, a sprint becomes a reporting period, not a learning loop.

The deeper dysfunction is structural. Businesses that treat IT as equal to other business functions — as a critical enabler of strategic outcomes rather than a managed expense — are the ones actually getting value from iterative delivery. Most traditional retailers don't operate that way. The CIO in a major grocery chain typically reports to the CFO, not the CEO. The IT budget is approved by the same committee that approves janitorial contracts. The internal dev team competes for resources against store renovation projects and negotiates the same quarterly budget cycles as the meat department.

Into this environment, someone decided to send a cohort of developers to a two-day Certified Scrum Master course and declare a transformation underway.

The Theater Problem

Most organizations approach Agile as a process replacement, swapping waterfall artifacts for Scrum events. Teams now have daily standups instead of status meetings, product backlogs instead of requirements documents, sprint reviews instead of milestone presentations. This superficial adoption creates the illusion of transformation while preserving the underlying coordination logic entirely intact.

In retail specifically, that underlying coordination logic is deeply physical: seasonal buying cycles, planogram resets, promotional calendars locked in six months out, store operations that run 365 days a year and tolerate exactly zero downtime at the POS. When organizations install Scrum without changing how decisions are made, how feedback flows, or how learning occurs, they deny themselves its core benefits. The result is what practitioners call "Agile Theatre" — performing agility for the show, without substance.

The signs are easy to spot once you've seen them once. The daily standup is a status report. Sprint planning confirms decisions a smaller circle of people made last week without the team. The retrospective surfaces the same three issues it surfaced six months ago. The sprint review is a demo followed by polite applause, after which everyone leaves to do something that actually matters.

A survey found that 42% of respondents cited company culture at odds with core Agile values as the leading cause of failed Agile projects. In retail, that culture mismatch isn't incidental — it's structural. Senior managers in large organizations tend to think of agility as executing projects more quickly and cheaply. In practice, Agile is about gaining empirical process control in a complex and uncertain environment. A retailer trying to squeeze Agile into a quarterly budget-approval hierarchy and a vendor-locked POS isn't going to find that empirical control. They'll find Jira tickets.

The Counterargument Deserves an Honest Hearing

The counterpoint is real, and it's worth stating cleanly: some retailers have made meaningful progress precisely by adopting structured iterative delivery inside their messy organizational realities. Falabella, the Latin American retail conglomerate, recognized store modernization was fundamental to maintaining its leadership position and approached it as a tech-forward retailer with a strong digital foundation. The result: the business transformation accelerated time-to-market, enabling Falabella to launch features six times faster.

But notice what made that work. It wasn't a Scrum Master managing a backlog. It was a deliberate architectural decision — a cloud-native, multi-tenant, API-driven, scalable platform built using domain-driven design principles, hosted on Google Cloud on a microservices-driven architecture running Kubernetes. The Agile ceremonies that followed that investment had something real to operate on: decoupled systems, deployable increments, actual autonomy. Without the architectural preconditions, the ceremonies are theater by design.

A common tipping point — the moment organizations finally decide to tackle legacy — is when desired business changes start costing far more than any anticipated benefit. An early warning sign: spending weeks and hundreds of thousands of dollars to make a change to a website that moves the needle by almost nothing. For retailers still running a monolith POS, every sprint is already at that tipping point. Scrum doesn't fix that. Architecture does.

The Real Failure Mode

Organizational gravity pulls at a transformation attempt until everything gets molded to the organization's current shape. Agile vocabulary gets co-opted: new words used to describe unchanged roles, unchanged artifacts, unchanged events. The project manager becomes the product owner. The status meeting becomes the daily standup. The year-end big-bang release becomes a "program increment." Nothing actually changes about how decisions get made or what the team is authorized to do.

About 59% of organizations report using frameworks like SAFe or LeSS, with larger enterprises especially reliant on them. Yet 61% of large organizations are dissatisfied with the results of their Agile transformations. For retail IT, that dissatisfaction is predictable. The ceremonies are adopted; the authority structures are not. In a poorly planned Agile transformation, it's not unusual for there to be genuine enthusiasm at the team level and general support at the executive level, leaving project and program managers trapped in a messy change sandwich. In retail, that middle layer — typically store operations management — has every incentive to preserve the existing approval chain, because their jobs depend on it.

The worst outcome isn't a failed Agile transformation. It's a half-finished one. Cargo cult Agile doesn't just fail to help — it actively harms. It teaches people that process is something to endure. It immunizes organizations against agility by leading them to believe they've already tried it. A retail IT team that went through a SAFe rollout three years ago, saw no meaningful improvement in delivery speed, and watched the Agile coaches quietly disappear from the org chart — that team is now structurally harder to help than one that never tried at all.

The honest diagnosis for most retail IT shops isn't that they need better Scrum Masters or more rigorous sprint ceremonies. They need the organizational permission to treat software as a core competency rather than a managed expense — and they need the architectural foundation to make continuous delivery physically possible before asking teams to behave as if it already is.

The consultants who sell Agile transformations without those prerequisites aren't wrong about the destination. They're just selling the map without mentioning that the road hasn't been built yet. And in the meantime, the POS system is still running on a vendor's five-year-old release, the licensing renewal just landed on the CFO's desk for approval, and the retrospective starts in ten minutes.

Nobody's going to bring it up.

DEV Community