When the Going Gets Tough

Every team I’ve ever watched practice Scrum has, at some point, said the same sentence out loud. The wording varies; the meaning never does:

“Okay, let’s drop the Scrum stuff for now and just fix this.“

Listen to that sentence, because it’s the most honest thing the framework ever produces. It is said at the exact moment the work gets hard: the production incident, the deadline that turned real, the launch week, the discovery that the half-built feature is wrong. And what the team is announcing, in a tone of relief, is that the process and the work are two different things — that Scrum is a fair-weather garment, worn while things are calm and removed the instant they’re not. Standups suspended. Board ignored. Points forgotten. Everyone just... works. And the part that should stop you cold: it usually helps. The team moves faster, talks more, ships the fix. The crisis gets solved in the absence of the method designed to manage crises.

That sentence was the end of my faith. Because a method that gets taken off when things get serious is not a method for serious things. It’s a method for calm Tuesdays. The whole point of a way of working is to hold up under load — anyone can ship in good weather; the storm is when you need the structure most. A bridge you have to dismantle before the flood is not a bridge. And I watched team after team, sincerely, repeatedly, dismantle the bridge at the first rain and feel better for it — never once asking why the thing they’d built for this moment was the first thing to go.

The last chapter prosecuted the ceremonies on cost. This chapter prosecutes the whole framework on the only test that finally matters: what does it do under load? And the answer, demonstrated four ways, is: it gets in the way, and then it gets removed. And then, at the end of the chapter, a fifth thing happens — the one that turned the whole trial around for me.

The red sprint#

Before the case study, the antipattern that names the failure. My notes call it the red sprint: the sprint that ends in failure — committed work unfinished, the burndown bent the wrong way, the demo half-empty — and what the framework does about it, which is the tell.

By the Guide, a missed sprint is a learning signal: inspect, adapt, adjust the forecast, improve. Humble, empirical, fine. By the gravity of every real organization, a red sprint is a failure with a number attached, and the number goes upward, and now there’s a conversation that is not humble and not empirical. Why didn’t we hit the commitment? The team, being made of people who’d like to keep their weekends, learns the only available lesson — not “estimate better,” which is impossible, but “never go red again.” And so the next planning is an exercise in defensive forecasting: commit to less, pad everything, keep a secret buffer, never let the burndown embarrass anyone. The estimates, already fiction, now become protective fiction.

Watch what just happened. A practice meant to surface reality has trained the team to hide it. The red sprint was supposed to be a smoke detector; under organizational gravity it became a thing to prevent from going off — and the way you do it is by unplugging it. By the third defensive planning, velocity is a number the team manufactures to look smooth, and the framework’s central feedback loop is running in reverse, optimizing for the appearance of predictability on top of work that is inherently unpredictable. The red sprint isn’t a bug in how teams use Scrum. It’s what Scrum does when you attach its honest signal to a culture that punishes honest signals — which is every culture, eventually, because that’s what gravity is.

Now let me show you the gravity at work, on a single, ordinary feature.

The feature was login. Specifically, the permissions behind it — who can see what, once they’re in. It was on the roadmap, sized, sprinted, committed. It was not exotic. And I watched some version of it die four different ways, on four occasions, across the kind of multi-team environment Ariadne was. Four scenarios, call them A through D, and the point of telling all four is that they have nothing in common except this: in every one, the framework had no answer, and the team’s salvation was the sentence at the top of this chapter.

Scenario A — the dependency the sprint couldn’t see. The permissions work depended on an endpoint owned by another team. At planning, this was a line item, sized a tidy 5. In reality it was a queue: the other team had their own sprint, their own commitments, their own product owner with different priorities, and our “5” sat in their backlog behind three things that mattered more to them than our login did. Our sprint marched on around an empty socket. Mid-sprint the framework offered two moves: raise it as an “impediment” (logged; nothing happened, because the scrum master had no authority over another team’s backlog) or carry the ticket to next sprint (where the same socket would be just as empty). The sprint went red for a reason no estimate could have caught and no ceremony could resolve, because the cause lived in a different room the method couldn’t reach into.

Scenario B — the requirement that was never a requirement. “Users should see only what they’re allowed to see” — one sentence, sized, committed. It detonated into questions the moment a developer touched it: allowed by what — role, team, ownership, hierarchy, some matrix of all four? What about an admin acting for a user? A user on two teams? The product owner, asked, didn’t know — not from negligence, but because the business didn’t know; nobody had decided, because deciding required understanding the domain at a depth the one-sentence ticket had flattened. The sprint had committed to building an answer to a question no one had finished asking. The framework’s structures (refine it, score it, commit it) had manufactured false confidence around a genuine unknown, and the timebox was now ticking on a discovery problem that looked like a delivery problem.

Scenario C — the architect’s veto, arriving late. Permissions got built, demoed, nearly done. Then an architect (not on the team, not in the planning, watching from above) looked at the design and canceled it: wrong layer, wouldn’t scale, must route through a central authorization service still being designed elsewhere. Possibly correct! But the input arrived at review, after two weeks of building (the objection at review prices instead of whiteboard prices), and the framework had no slot for it: architects aren’t a Scrum role, “the developers own how” until quietly they don’t, and authority that lives outside the team can override the team at any moment with no ceremony to catch it earlier. The sprint went red because the real decision-making structure of the organization ran on lines the framework pretended weren’t there. And this was the project’s metabolism, not a fluke: we finished sprints and discarded them to a rhythm, rewriting completed, demoed work because the deciding kept arriving after the building instead of before it — the reddest sprints were often the ones that had looked green right up until review.

Scenario D — the cross-team collision on one screen. Two teams, by Conway’s bad luck, both needed the same settings screen — ours for permissions, theirs for billing. Both sized their piece in isolation; both committed; both started; and they met in the middle of the same files, in the same sprint, with no shared owner of the whole. Whose model wins? Whose sprint yields? Two product owners, equal rank, different priorities, and Scrum, a single-team framework to its bones, offered nothing for the space between teams, where the actual conflict lived. And the seam only widened the year two more teams joined Ariadne from a second city: now the two halves of one screen were being built by teams in different cities, coordinating through the same ceremonies that already couldn’t see the space between teams when everyone shared a floor — never mind when they shared nothing but a video call. The sprints didn’t fail at planning or at execution. They failed at a seam the method doesn’t believe in.

What the four deaths have in common#

Lay the four side by side. A blocked dependency. An undefined requirement. An external veto. A cross-team collision. Different causes, different rooms, different weeks, and one shared verdict: none of these failures was a failure to do Scrum properly, and none of them had a Scrum solution.

That’s the finding I want you to sit with, because the defense from the last chapter will rush in here — ScrumBut! you estimated badly, you refined poorly, your PO was weak. But run it honestly against the four. Better estimation doesn’t conjure another team’s capacity (A). More refinement doesn’t decide a question the business hasn’t decided (B). No ceremony summons an absent architect into the planning he chose to skip (C). And nothing in a single-team framework governs two teams in one file (D). In every case the cause lived outside what Scrum models — in dependencies, in domain knowledge, in the org’s real decision lines, in the seams between teams, which is to say, in the subjects the rest of this part is about. Scrum didn’t cause these failures. It just confidently occupied the team’s attention while having no relationship to any of the things that actually determined the outcome. It was the wrong map, drawn in great detail.

And in all four, what saved the team was the sentence: drop the Scrum stuff, let’s just fix this. They stopped pretending the timebox mattered, found the other team’s lead and traded directly, cornered the PO until the business actually decided, pulled the architect into a room, got the two teams to draw the screen together on one whiteboard. Human, direct, un-ceremonied. The method’s removal was the precondition for the solution every time — and every time, the team filed the lesson under “we had a rough sprint” instead of “the method is absent precisely when the work is present.”

Waiting for the retro is waiting in the wrong room#

Here’s a further cruelty. When something is broken in how a scrum team works, the framework has an answer for where you fix it: the retrospective. Raise it there. Inspect and adapt.

But my note from the trenches stands: waiting for the retro to change something is futile. Two reasons, both visible in the case study. First, timing: the retro is at sprint’s end, so the framework asks you to hold a problem you discovered on Tuesday until a ceremony two weeks away — to queue the fix behind the calendar. The dependency in Scenario A needed a conversation that hour, not a sticky note that fortnight. Second, and worse, power: the retro can only change what the team controls, and every one of the four deaths had its cause outside the team — another team’s backlog, the business’s indecision, an architect’s authority, a second team’s product owner. You can retrospect about those until the room is papered in sticky notes; you cannot fix them there, because the retro is a single-team room and the problems are not single-team problems. The framework points you at the one room guaranteed not to contain the lever. That’s not a process for improvement. It’s a containment field for frustration: a place to feel heard about things you’re structurally unable to change.

The fix for all four lived in the same place: not in a ceremony, but in someone with the authority and the position to decide and to reach across the lines. That someone gets a chapter of his own, and I’ll walk through that door soon. First, the meeting that changed what I thought this trial was about.

The word that meant five things#

On Project Ariadne, the word “done” meant five different things to five different teams, and nobody had ever noticed, because everyone was certain it meant the obvious thing — theirs.

I found this out the way you find out everything important on a failing project: too late, in a meeting convened because something had gone wrong. A feature was “done“: our team had said so, in a review, with a demo. Another team (one of the two that had arrived from another city that year, and had started working inside our code without a word to us) had built against our “done” and theirs had broken. In the post-mortem the word came apart in our hands. To us, “done” meant merged and passing tests. To the team downstream, it meant deployed to staging. To the product owner, it meant the stakeholder had seen it and nodded. To the QA function, it meant signed off. To the architect, it meant conforming to a design document half of us had never read. Five sincere definitions, five teams each running flawless Scrum internally, and between them a chasm that no ceremony spanned, because the ceremonies all happened inside the teams and the misunderstanding lived between them.

We had a definition of done. It was on a wiki. It had been agreed in a meeting. And it had quietly speciated into five dialects the moment five groups of humans started using it under pressure, each filling its ambiguity with their own context — the same speciation as “everybody knows Scrum,” one level down. The framework had given us the artifact “definition of done” and none of the thing the artifact was supposed to produce: actual shared understanding, which is not a document but a relationship, and relationships were what we didn’t have across those team boundaries. We tried to mend it, later (a few initiatives, sincerely meant), and they died quietly, because mending it would have taken more cooperation than anyone was willing to give.

That meeting is where the verdict of this trial turns. I had been prosecuting the framework — its costs, its collapse under load. But standing in that room, watching one word fracture into five, I understood that I’d been prosecuting the wrong defendant. The framework didn’t cause this. People caused this — or rather, the framework had simply failed to account for what people unavoidably are. Scrum doesn’t work in production for a reason deeper than any ceremony: the reason is people, and people don’t pause for the sprint.

The assumption buried under all of Scrum, and under most process frameworks ever sold: that if you get the mechanics right (the right events, the right roles, the right cadence), the human variables will sort themselves out. Set up the board correctly and the people will flow through it correctly. It is the most natural engineering instinct in the world, and it is exactly wrong, because the humans are not tokens moving through a workflow. They are the entire system, and they bring to the board everything a framework wishes they wouldn’t: ego, politics, fear, ambition, misunderstanding, the need to look competent, the instinct to protect themselves, the thousand small frictions of people who have to depend on each other and don’t always want to. The chimp doesn’t check the sprint calendar before it fires. No ceremony un-silences an unsafe team. Whether people connect decides more than any process, and Scrum has no opinion on connection at all. The framework models the work. It does not model the workers, and software is made by the workers.

And here is the thing process frameworks fundamentally misunderstand: the tensions and conflicts aren’t obstacles to the work that a good process removes. They are the work. Deciding what “done” means across five teams is the work. Reconciling two product owners' priorities on one screen is the work. Getting an architect and a team to actually talk before the veto is the work. Surfacing the requirement the business hasn’t decided is the work. A framework that schedules ceremonies around these tensions while leaving the tensions themselves untouched has automated the easy part and gift-wrapped the hard part as someone else’s problem — usually the team’s, at 6 p.m., after the method has been dropped so the real work can finally start. My raw note for this whole part was three words long: tensions, conflicts, human nature. That’s the material software is actually made of, and it’s the material no process models.

Which is why the rest of this part is not about a better calendar. It’s about people: arranged so they can actually work, with someone who can actually decide, led by someone who actually understands the work. The reason is people. So the answer has to be about people too.

The honest counterargument

The defense’s best reframe is genuinely strong: suspension is a feature, not a bug. Scrum (the argument goes) is a steady-state cadence, never meant to govern a production fire — of course you drop the standup during an incident; you’d drop a regular meeting too. The framework organizes normal flow and gracefully yields to crisis management when crisis comes. Fair. But notice how much of software is the exception: the blocked dependency, the fuzzy requirement, the late veto, the collision are not rare storms; on the teams I lived through they were most Tuesdays. A method that governs only the calm intervals between the hard parts is governing the part that didn’t need governing. If you must remove your process for everything that’s actually difficult, ask what fraction of real work that leaves it managing.

Second, fairly: not every red sprint is Scrum’s fault, and I must not let the framework become the universal scapegoat. Sometimes the team genuinely under-delivered. Sometimes the estimate was lazy rather than impossible. Sometimes the dependency was foreseeable and someone dropped it. Blaming the process for human and organizational failures is its own evasion, and worse, it’s convenient, because “the process failed” indicts no one in the room. Several of this chapter’s four deaths were also leadership failures, ownership failures, communication failures. That’s my point, though, turned around: those are the failures that decide outcomes, and they are the failures Scrum is silent about. The framework isn’t guilty of causing them. It’s guilty of drawing the team’s eyes elsewhere — of being a detailed, busy, certified answer to questions nobody was failing on, while the questions that sank the work went unnamed because the map had no symbol for them.

Third, and sharpest: if the reason is people, isn’t your whole critique just “hire good people, and any process works“? I have to concede the core of it: a great team will succeed in spite of almost any process, and a broken team will fail inside the best one. People dominate. Always. But follow the concession one step further, because it doesn’t acquit the framework — it reframes the charge. If people decide outcomes, then the value of a process is how much it helps the people do the human work: surface the real requirement, resolve the cross-team conflict, grow the shared understanding, put decisions where the knowledge is. Judged by that standard, Scrum scores poorly, because it spends the team’s scarcest hours on ceremonies that organize the mechanical work while leaving every human tension exactly where it found it. A process can’t replace good people. But it can get out of their way and even amplify them, or it can tax them and misdirect them. That’s a real axis, and Scrum sits on the wrong end of it. For a junior team with no instinct for any of this, its mechanics can be a scaffold while the human skills grow; the trouble is the scaffold that’s never removed: teams that needed the human skills were sold a calendar instead, and everyone was certified in the calendar.

Practicing it#

Catch the sentence, and treat it as data. The next time your team says “let’s drop the process and just fix this,” don’t just feel the relief — write it down. What got dropped? Did dropping it help? What were you suddenly free to do? You’re collecting evidence about which parts of your method serve the calm and obstruct the storm. The dropped parts are the suspects.

Post-mortem the red sprint on the system, and name the tension. When a sprint goes red, run the five-whys one level past the technology: where did the cause actually live? If the honest answer keeps landing outside the team — a dependency, an indecision, a veto, a seam — that’s not an estimation problem to fix with better pointing. Then ban process-tweak items from the next retro for one session and ask only: which decision didn’t get made, which understanding wasn’t shared, which conflict did we route around? That list is your real backlog. It always was.

Hunt your speciated words. Pick the three terms your teams use most — “done,” “ready,” “blocked,” “MVP” — and ask three people on three teams to define each, separately, in writing. The gaps you find are Ariadne’s “done” in miniature, and they’re costing you more than any estimate ever did. Shared vocabulary is a relationship; audit it like one.

The thread

A method is what it does under load, and Scrum’s most honest output is the sentence every team eventually says — drop the process, let’s just fix this — uttered with relief at the exact moment the work turns serious. Then one word meant five things to five teams, and I saw I’d been prosecuting the wrong defendant. The reason is people, and people don’t pause for the sprint. The tensions aren’t obstacles to the work. They are the work.