Choosing and Adapting: Fit the Method to Your Context

You now have the three main ways of working in hand. Plan-Then-Build vs Iterate-and-Adapt drew the fundamental fork. Scrum gave you a rhythm for fuzzy, feedback-driven work. Kanban gave you a way to manage a steady stream of varied requests. This closing chapter of the part answers the question every reader is now sitting with: which one should we use — and how do we keep it from becoming a cage?

The honest answer is that none of them is “the right way.” Each is a tool shaped for a certain kind of work. The skill isn’t picking the trendiest method; it’s diagnosing your context, choosing what fits, and then adapting it — keeping the parts that earn their keep and quietly dropping the parts that don’t. This page gives you a decision guide and, more importantly, a defense against the most common failure in this whole subject: copying a process you don’t understand.

The principle: the method serves the outcome, never the reverse

Go back to the throughline of the book — turning a group of people and a goal into reliable outcomes without chaos, burnout, or politics. A way of working is just a means to that end. It’s scaffolding. The moment you find yourself protecting the scaffolding for its own sake — running a ceremony because “that’s the process,” not because it helps — you’ve inverted the relationship. The outcome is the master; the method is the servant.

This sounds obvious, and yet teams invert it constantly. They measure their success by how faithfully they follow the ritual instead of by what the ritual produces. A good rule to keep close: every practice you run should be traceable to a real problem it solves for you. If you can’t name the problem, you’re not doing the method — you’re performing it.

A decision guide: matching the method to the work

Start not with the method but with the nature of the work. Three questions do most of the sorting.

1. How well do you understand the goal up front? Can you specify what “done” looks like in detail, or will you only learn it by building and showing people?
2. How costly and how late is change? In some work, changing your mind halfway is cheap. In others, it means pouring the concrete twice.
3. What’s the shape of the demand? One big defined deliverable? Or a continuous stream of smaller, varied requests arriving at unpredictable times?

Here’s the rough mapping those questions produce.

If the work is...                          Lean toward...
------------------------------------------ -----------------------
Well-defined, fixed scope, change is        Waterfall / plan-then-build
costly or dangerous (a bridge, a
regulatory filing, a physical build)

Fuzzy goal, real uncertainty, cheap to      Agile / Scrum
change, needs frequent feedback (a new
product, a service no one's built before)

A steady stream of varied, arriving         Kanban
requests with no natural "project"
(IT support, a hospital intake desk,
a marketing team's request queue)

Read the table as a lean, not a law. Most real teams blend. A hospital ward runs strict, checklist-driven procedures for surgery (plan-then-build — you do not “iterate” on an incision) while its equipment-maintenance team runs a Kanban board of repair tickets. A software team might build a brand-new feature in Scrum sprints, then move it to a Kanban flow once it’s live and the work becomes a stream of small fixes. The unit of choice is the work, not the company.

In practice — the same team, two modes

A small architecture firm designs custom homes and also handles a constant trickle of small permit-and-revision requests from past clients. For the custom homes — big, defined, expensive to change once construction starts — they work plan-then-build: detailed drawings signed off before anyone breaks ground. For the trickle of small requests, they run a simple Kanban board: a card per request, a limit on how many are in progress at once, first-in-first-out. One firm, two ways of working, each chosen because it fits that work. Nobody insists the whole office use one method.

When you genuinely don’t know, bias toward feedback

If you’re unsure which bucket you’re in, notice which way the risk points. When the biggest risk is “we might build the wrong thing,” you want frequent feedback — lean iterative. When the biggest risk is “we might build it wrong” (safety, compliance, irreversibility), you want up-front rigor — lean plan-then-build. Uncertainty about the goal pushes you toward agile; uncertainty about execution consequences pushes you toward planning.

Cargo-culting: doing the ceremonies, getting none of the benefit

Now the central danger. The most common way teams ruin a good method is by cargo-culting it — copying another company’s rituals without their context, performing the ceremonies while getting none of the benefit.

The term comes from a striking real episode. During and after World War II, some remote Pacific island communities had watched Allied forces build airstrips, and cargo planes full of supplies would land. When the forces left, the planes stopped coming. Some islanders, understandably, tried to bring them back by faithfully recreating what they’d seen: clearing runway-shaped strips, lighting signal fires, fashioning wooden headsets and control towers, going through the motions of directing aircraft. The form was reproduced with great care. But the form was never what made the planes come — the vast supply chain behind it was. No planes landed. The physicist Richard Feynman later borrowed the phrase “cargo cult” to describe any activity that copies the visible rituals of something successful while missing the substance that actually made it work.

Teams do exactly this. A company reads that a famous tech firm holds a fifteen-minute daily stand-up, so they hold one — but theirs runs forty minutes, everyone reports to the manager instead of coordinating with each other, and nothing changes as a result. They cleared the runway and lit the fires. The planes don’t come, because the stand-up was never the source of the value; a team that actually coordinates and unblocks each other was.

The common trap — the tell of cargo-culting

Here is the single sharpest test. Walk up to someone mid-ritual — stand-up, retro, sprint planning, a status report — and ask, gently: “What problem does this solve for us? What would break if we stopped?” In a healthy practice, people can answer immediately: “It’s how we catch blockers before they cost us a day.” In a cargo-cult practice, you get a different answer: “I don’t know — we’re supposed to do it,” or “That’s just our process,” or “The other team does it.” When nobody can explain why a practice exists — only that they’re required to do it — you’ve found ceremony masquerading as method. That’s your signal to fix it or drop it.

The evidence — process without purpose

Studies of “agile transformations” generally find a large gap between teams that adopt the practices and teams that get the benefits, and the difference is rarely the practices themselves. Organizations frequently install the visible artifacts — boards, stand-ups, sprint names, story points — while leaving the underlying conditions untouched: managers still dictate scope, feedback still doesn’t reach the people doing the work, “iterations” still can’t change anything already decided. The consistent lesson is qualitative and worth stating plainly: rituals copied without their enabling context produce the costs of the method and few of its gains.

Adapt deliberately: keep what works, drop the ceremony

If cargo-culting is the disease, deliberate adaptation is the cure. Adapting a method is not the same as being sloppy or “not doing it properly.” It’s the point. Every good way of working expects to be tuned to the team using it.

The move is simple to state and takes discipline to do:

• Keep the practices that solve a real problem for you. If your retrospective genuinely surfaces changes the team then makes, guard it fiercely.
• Drop or reshape the practices that are pure ceremony. If your stand-up has become a status report to the boss that no one uses, either fix it (make it about coordination, not reporting) or stop it.
• Change it when it stops earning its keep. A ritual that helped last quarter can go stale. Methods aren’t sacred; they’re experiments you keep or discard based on results.

The safeguard against adapting yourself into chaos is to change one thing at a time, on purpose, and watch what happens. Don’t quietly let practices erode; that’s just decay. Decide, as a team: “We’re dropping the Friday demo for a month because attendance shows no one values it — and we’ll check whether anything we relied on it for suffers.” That’s an experiment. Erosion is what happens when nobody’s steering.

Case study — Toyota’s andon cord, borrowed without the culture

On Toyota’s production lines, any worker can pull the andon cord to stop the line when they spot a defect. It’s famous, and countless companies copied the visible artifact — a cord, a button, a “stop-the-line” policy. Many got nothing from it. The reason is instructive: at Toyota the cord worked because it sat inside a culture where stopping the line to fix a problem was genuinely welcomed and rewarded, not punished. Copy the cord into a workplace where stopping work gets you blamed, and no one ever pulls it. The lesson isn’t “don’t use andon cords.” It’s that a practice is inseparable from the conditions that make it safe and sensible to use. Adapt the conditions, or the ritual is theater.

A practical way to run the adaptation

Once or twice a quarter, take an inventory of every recurring practice your team runs — every standing meeting, report, board ceremony, and ritual. For each one, force an answer to two questions: What problem does this solve? and What would we lose if we stopped? Anything that can’t earn a clear answer is a candidate to cut or redesign. Then change one thing, tell the team why, and review it at the next inventory. Over time this keeps your way of working lean, owned, and honest — a method you run, rather than one that runs you.

How it connects

This closes the same loop the part overview opened: a way of working exists to turn effort into outcomes, and it’s worth exactly as much as the outcomes it produces. The habit of asking “what problem does this solve?” is the same muscle you’ll use everywhere else in the book — in meetings, in reporting, in how you run reviews. For a compact recap of the whole part, see the Revision page.

Try this

This week, run a five-minute version of the practice inventory on your own team. List every recurring ritual you take part in — stand-ups, status reports, planning sessions, weekly meetings. Beside each, write in one sentence the real problem it solves. For any where you find yourself writing “we’re supposed to” or drawing a blank, flag it and raise it with your team: “What would break if we stopped doing this?” You’re not trying to abolish process — you’re testing which of it is actually load-bearing.

Reflect

1. Look at the main work your team does. Using the three questions in the decision guide, which method does it most naturally lean toward — and does that match what you actually do today?
2. Which of your current rituals could you not explain the purpose of if someone asked you right now? What does that tell you?
3. Where in your organization has a practice been copied from somewhere else — a famous company, a former employer, a book — without the context that made it work there?
4. Think of a ceremony that has gone stale. What’s stopping the team from changing or dropping it, and is that reason about outcomes or about habit?
5. If the method truly serves the outcome, how would you know your current way of working is earning its keep? What would you measure or watch?

Show reflections

1. The aim is to separate the work’s nature from the method’s label. Many teams discover a mismatch — running rigid sprints on a pure request-stream that wants Kanban, or “iterating” on work whose scope is actually fixed and safety-critical. Naming the mismatch is the first repair.
2. This is the cargo-cult tell turned inward. A ritual you can’t justify isn’t automatically bad — but it’s a candidate for scrutiny. The useful reframe: you’re allowed to keep it only once you can say what it’s for.
3. Borrowing is fine; borrowing without the context is the trap. Strong answers spot the missing condition — the culture, the feedback loop, the authority to change scope — that made the practice work at its source and is absent here.
4. Most stale ceremonies survive on inertia and fear of “not doing it properly,” not on value. If the reason to keep it is habit rather than outcome, that’s your permission to run a deliberate experiment: change one thing, watch, review.
5. This is the whole page in one question. Good answers tie the method back to real signals — are we shipping the right things, is change cheap when we need it, is the team unblocked, is anyone burning out — rather than to how faithfully the ritual is performed.