The History Lesson Nobody Wanted: Why Your Team Is Living in 1985

She’d raised it in three consecutive retros. The same point, worded slightly differently each time, the way you rephrase a question when you suspect nobody heard it the first time. The deployment pipeline was brittle — two manual steps, a restart sequence that only worked if you did it before 4 PM Bangkok time, and a Slack message to a person who was usually on leave. The meeting room on level 8 was too warm, the way they always are when twelve people sit in a space designed for eight — that slightly stale mix of Coffee Mate from the kitchen down the hall, someone’s Thai iced tea perspiring onto the vinyl desk, and the faint sweetness of a half-opened bag of Lays that had been doing the rounds since someone came back from a trip to Japan. The scrum master wrote her point on a Post-It, stuck it in the “action items” column, and moved on to the next topic. The Post-It was still there six weeks later, curling at the edges, the adhesive giving up before the process did. She stopped raising it after that. Not loudly — she just stopped. The kind of silence that doesn’t register in any standup or velocity chart but changes the temperature of every meeting it sits in.

That silence is the real cost of ceremony without substance. Not the wasted hours, not the theatre — the moment an engineer decides the process isn’t listening and quietly stops talking. We’ve spent twenty-five years building an industry around the ceremony of Agile while systematically ignoring the substance of it. The manifesto’s own authors have been saying this for over a decade. Most of us just weren’t listening — we were too busy estimating in Fibonacci numbers.

The Forty-Year Loop

There is a peculiar amnesia in the software industry. Every fifteen years or so, a generation of engineers discovers that the way they’re building software doesn’t work — that heavy process produces heavy failures — and they rebel. They write manifestos. They form movements. They invent new names for old ideas. And then, slowly, the rebellion becomes the establishment, the establishment becomes the bureaucracy, and the next generation discovers that the way they’re building software doesn’t work.

As the philosopher George Santayana warned, “Those who cannot remember the past are condemned to repeat it.” He was talking about civilisations. He might as well have been talking about software methodology conferences.

The pattern goes like this: engineers find a pragmatic way of working. Management formalises it. The formalisation kills the thing that worked. Engineers rebel. Repeat.

1970: The Misunderstanding. Winston Royce published “Managing the Development of Large Software Systems.” The paper is famous for its diagram of sequential phases — what we now call waterfall. Here’s the part that almost nobody mentions: Royce presented that diagram as an example of what doesn’t work. He wrote, on page two, that this approach “is risky and invites failure.” He spent the rest of the paper proposing iterative alternatives. The industry read page one and stopped.

The term “waterfall” doesn’t even appear in Royce’s paper. It was coined six years later by Bell and Thayer, referencing the very diagram Royce said was dangerous. We built an entire era of software development on a misreading.

1985: The Mandate. The U.S. Department of Defense published DOD-STD-2167, mandating the waterfall model for military software contractors. The same approach Royce warned against became official government policy. The result was predictable: projects that took years, cost billions, and frequently failed. The Standish Group’s 1994 CHAOS Report found a 16% success rate for software projects — and defence projects were among the worst performers.

Note the mechanism: a pragmatic observation was misread, formalised, mandated, and scaled. The original insight was lost. The ceremony remained.

2001: The Rebellion. By the late 1990s, practitioners were independently developing lightweight methodologies — Kent Beck’s Extreme Programming, Jeff Sutherland and Ken Schwaber’s Scrum, Alistair Cockburn’s Crystal. In February 2001, seventeen of them met at the Snowbird ski resort in Utah. They expected disagreement — as the original history page describes it, a bigger gathering of organisational anarchists would be hard to find. Instead, they found common ground. Over two days, they wrote four value statements and published them as the Manifesto for Agile Software Development.

The manifesto is 68 words long. It takes about thirty seconds to read. It contains no mention of sprints, story points, velocity, Scrum Masters, Product Owners, SAFe, or certifications. It is a statement of values, not a process.

2005–Now: The Cargo Cult. And then the cycle repeated. Again.

The Scrum Alliance was founded. Certifications were created. A two-day course produced a “Certified ScrumMaster.” The Scaled Agile Framework packaged Agile into an enterprise-friendly structure with roles, ceremonies, and governance that looked — to anyone who’d lived through 1985 — remarkably like waterfall with better branding.

The manifesto’s authors watched it happen. Dave Thomas, one of the seventeen signatories, declared in 2014 that the word “agile” had been subverted to the point of meaninglessness and the agile community had become largely an arena for consultants and vendors. Martin Fowler warned in his 2018 Agile Australia keynote about “Faux Agile” — agile in name without practices or values. Robert “Uncle Bob” Martin observed that the agile movement had pushed so many project managers in that they’d pushed the programmers out. Ron Jeffries coined “Dark Scrum.” Ken Schwaber, co-creator of Scrum itself, left the Scrum Alliance in 2009 and later called SAFe “unSAFe at any speed.”

The mechanism was identical to 1985. A pragmatic insight was formalised, certified, mandated, and scaled. The original values were lost. The ceremony remained.

The Bamboo Runway

Richard Feynman described cargo cults in his 1974 Caltech commencement speech: Pacific islanders who’d seen military planes bring supplies during World War II built runways from bamboo and lit signal fires, mimicking the form of technology without understanding the substance. The planes never came.

You might be standing on a bamboo runway right now.

The manifesto says “Individuals and interactions over processes and tools.” Your organisation has a mandatory standup format, a mandatory retro format, and a mandatory planning poker tool. Deviation from the format is treated as a process failure.

The manifesto says “Working software over comprehensive documentation.” Your “Definition of Done” requires updating Confluence, Jira, and a release tracking spreadsheet. Nobody reads any of them.

The manifesto says “Customer collaboration over contract negotiation.” Requirements arrive as Jira tickets from a product committee. Engineers never talk to customers.

The manifesto says “Responding to change over following a plan.” Changing scope mid-sprint requires a “sprint change request.” Velocity is tracked as a performance metric.

Here’s the deeper test: look at who attends your Agile ceremonies. If the answer is “mostly non-engineers,” you’ve recreated 1985. The meetings exist for management visibility, not for the team building software.

And here’s an even simpler one: watch your engineers’ eyes during standup. Who do they look at when they talk? If it’s each other — trading context, flagging dependencies, offering help — you’ve got a team synchronisation. If every engineer turns to face the Product Owner or the manager when it’s their turn to speak, you don’t have a standup. You have a status update with better furniture.

The irony burns. We’ve taken a manifesto that explicitly values “responding to change over following a plan” and turned it into a rigid process where questioning the process is itself treated as a problem. That’s not Agile. That’s religion.

“But, But… My Points!”

I want to tell you about a conversation I had with one of my engineers. We were discussing a small change to how the team handled sprint carry-over. Nothing dramatic — just a suggestion that if a story isn’t 100% done, we shouldn’t count the percentage complete toward sprint completion. My reasoning was simple: optimise for done, not half-done. Finishing things matters more than starting them.

The engineer went quiet. You could see the calculation happening behind his eyes. Then, with genuine distress in his voice: “But, but… my points!”

He wasn’t being unreasonable. He was being perfectly rational within a broken system. We’d taught him — through months of velocity-driven conversations, through dashboards that tracked story points like a stock ticker, through sprint reviews where completion percentage was the headline number — that points were what mattered. Points were the scorecard. Points were his team’s identity.

The economist Charles Goodhart captured this decades before Scrum existed: “When a measure becomes a target, it ceases to be a good measure.” Story points were invented to help teams estimate complexity. The moment someone put them on a dashboard and started tracking velocity trends, they stopped being about estimation and started being about self-worth.

That engineer’s team had become a feature factory. They’d stopped caring about business outcomes entirely — the Product Owner measured success of ideas, and the team was there to do implementation. They’d lost ownership of results and replaced it with ownership of points. The output looked healthy. The outcome was invisible.

This is what ceremony without substance produces. Not failure — something worse. The appearance of success that prevents anyone from asking whether anything actually improved.

Why the Cycle Repeats

It’s easy to blame the certification industry. And to be fair, when a two-day Certified ScrumMaster course costs $1,500 per person and the Scrum Alliance has certified over a million professionals, there’s a self-perpetuating economy that has every incentive to defend the framework. Questioning Scrum threatens careers, certifications, and consultancies. The result is an immune system that attacks criticism.

But the real reasons go deeper.

Management needs visibility, and process provides it. Tim Ottinger once described Scrum as “the box that XP comes in.” Allen Holub was more blunt in a conversation on Dave Farley’s Engineering Room: Scrum started out as a lightweight wrapper around Extreme Programming to make it palatable to management. That’s a perfect summary of what happened. Schwaber and Sutherland purposefully omitted XP’s technical practices — test-driven development, pair programming, continuous integration — to simplify organisational adoption. The engineering substance was stripped out so the process could be sold upward. And it worked — spectacularly well, from a sales perspective. The State of Agile survey found 66% of teams using Scrum but just 1% using XP. We kept the management wrapper and threw away the engineering practices it was supposed to protect.

Organisations copy structure, not culture. When companies hear about Amazon’s two-pizza teams, they create small teams. When they hear about Spotify’s squads, they rename teams accordingly. But they don’t give those teams autonomy, because autonomy requires trust. They don’t invest in technical excellence, because that takes longer than renaming roles. They copy the visible structure and leave the invisible culture unchanged.

Bas Vodde put it brilliantly when discussing what happens when organisations try to scale Scrum: when you start to scale, some people have fear, and so they hire for positions like release train engineers to feel “safe.” That last word — safe — carries deliberate weight if you know what framework those roles come from.

The practices that matter can’t be certified. Test-driven development, continuous integration, refactoring, pair programming, small batch delivery — these are the technical practices the manifesto authors identified as producing results. None of them require certification. None of them scale as consulting products. They require disciplined application over time. There’s no two-day course for TDD. Just years of practice.

This is why the cycle repeats: the things that work can’t be packaged. The things that can be packaged don’t work. The industry sells packages — and would you like a Jira subscription bundled with that?

What the Successful Companies Actually Do

Here’s the part that should frustrate you: the companies that ship at scale aren’t post-Agile. They’re pre-Agile. They’re doing what the manifesto described before anyone turned it into a product.

Amazon’s two-pizza teams own services end-to-end — from ideation to production operation. They don’t need another team’s permission to deploy. They don’t need a Scrum Master to facilitate communication. They choose their own practices. Notice what’s present: small teams, autonomy, ownership, accountability for outcomes. Notice what’s absent: mandated standups, story points, sprint ceremonies, certifications.

In 2012, Henrik Kniberg published a whitepaper describing how Spotify organised into squads, tribes, chapters, and guilds. The industry adopted it as a prescriptive framework. Companies worldwide renamed their teams “squads” and expected the results to follow. The irony is stunning: Spotify’s own Director of Engineering has said the model described in the whitepaper no longer reflects how Spotify works. They evolved past it. The whitepaper explicitly states that squads choose their own methodology. There is no mandated Scrum. The “Spotify model” is, at its core, an anti-model. The industry turned it into the very thing it was designed to prevent.

The common thread across these companies isn’t a framework. It’s a set of principles that were already in the Agile Manifesto: small autonomous cross-functional teams, technical excellence as non-negotiable, short feedback loops with real users, and ownership of outcomes rather than tickets. The manifesto authors would recognise it immediately. It’s what they were doing in 2001, before the certifications arrived.

So Is Scrum the Problem?

Let me be clear: Scrum isn’t fundamentally broken. I’ve seen it work. I’ve seen teams use it as a genuine tool for coordination, reflection, and incremental improvement. The framework itself — short iterations, inspect and adapt, cross-functional teams — embodies the manifesto’s spirit well enough.

The problem is how it’s sold. As a religion, not a tool. As a prescription, not a starting point. When your Scrum implementation has become a set of meetings with a two-week cadence where the standups don’t synchronise the team, the retros don’t produce change, and the velocity charts measure activity rather than achievement — you’re not doing Scrum badly. You’re doing Scrum theatre.

There’s a fascinating YouTube video from LEGO’s engineering team titled “Is SAFe Evil?” Their conclusion wasn’t that SAFe is inherently terrible — for them, it kind of worked. But it required careful adaptation, deep understanding of why the practices existed, and a willingness to throw out the parts that didn’t fit. In other words, they treated it as a framework to be adapted, not scripture to be followed. Which is, ironically, exactly what the Agile Manifesto asks you to do.

The critical distinction isn’t Scrum vs. Kanban vs. XP vs. nothing. It’s whether your process exists to serve the team or whether your team exists to serve the process. If you’ve ever heard someone justify a ceremony with “because we do Scrum,” you know which side of that line you’re standing on.

The Blind Spot Nobody Talks About

Here’s where Scrum genuinely fails, by design rather than implementation: it has no built-in mechanism for prioritising technical health.

When you put a Product Owner — typically a business person — in sole charge of the backlog, technical improvements compete directly with features. And they lose. Every time. Not because POs are malicious, but because the incentive structure makes it rational to defer technical work in favour of visible output. As I’ve written before, this is how you end up with codebases where deployment takes three days and nobody remembers why that one service needs to be restarted in a specific order on Tuesdays.

Here at Agoda, we’ve addressed this with guidance rather than mandate: 30% of engineering time should go toward technical improvements. It’s not a law of the land — it’s a health check. We measure it at the end of the quarter, and if it’s lower or higher we ask why. Sometimes there’s a good reason, and that’s fine. The point isn’t rigid enforcement. The point is that someone is asking the question. That alone changes behaviour more than any mandate could.

Breaking the Cycle

The answer isn’t another manifesto. It isn’t another framework. It isn’t renaming Agile to something that hasn’t been corrupted yet — Dave Thomas tried with “agility” and the industry will co-opt that too.

The answer is recognising that the split between “process” and “engineering” was always the problem. Agile tried to fix the process. It didn’t address the engineering. The result was a process movement that progressively excluded engineers — until, as Robert Martin observed, the programmers who started the movement no longer attended its conferences.

What comes next is what some of us have started calling product engineering. Not because the name matters — give it five years and someone will certify it — but because the concept matters. It treats engineering teams as product teams. Engineers don’t receive requirements — they discover problems. They don’t estimate stories — they measure outcomes. They don’t follow a process — they own a product.

There wasn’t a eureka moment for this. It was more of a slow recognition: this is what we do. It kind of works. It’s not perfect, but it works. And when we look at the companies that are genuinely successful, they’re doing similar things. The critical difference is that this isn’t something a process guide can give you. It’s a culture and mindset shift. It requires trust, autonomy, technical discipline, and a willingness to measure outcomes instead of velocity. You can’t buy that in a two-day course.

The Agile Manifesto was 68 words. It took thirty seconds to read. It took the industry twenty-five years and billions of dollars to misunderstand.

The practices that work haven’t changed: small teams, short feedback loops, technical excellence, customer focus, ownership. The manifesto got it right the first time. We just built a bamboo runway over the top of it and wondered why the planes never came.

Now, if you’ll excuse me, I need to go cancel a meeting that exists solely to discuss the outcomes of another meeting. But at least it’s in the Scrum Guide, so it must be working.