Stop picking an Agile method. Pick a promise size.

Let me start with the argument I no longer believe in: Scrum vs Kanban.

It is a shop-front argument. It sells certifications, it fills conference tracks, it lets people put a tribe in their bio. And it hides something much more useful: these methods are neighbours. On our project we ran three of them across ten months, and here is what actually changed between them —

Nothing. Not the ceremonies. Not the tooling. Not the shape of the project, not its functional scope, not its methodology in any meaningful sense. We ran a daily, a weekly, refinement and a retro from week one to the last day, in all three phases. (Scrum only added two events to that list: planning and the demo — 2020 Scrum Guide.)

One variable moved. One. The size of the promise — how big a thing a single person put their name on.

Phase	The estimation question we asked	Unit of responsibility
Kanban	"How many days for this component?"	a micro-task
Strong ownership	"How many weeks for this page?"	a long task
Scrum	"How many story points?"	a predictable slice

That's it. That's the whole article. Everything below is why that cursor moved, and what set its position: our level of certainty at that moment. Not our maturity, not a coach's advice, not a framework's promise.

The setup

Anonymised, but the shape is banal:

• 4 people, including the lead architect — who was also writing code
• Next.js / React, component library in Storybook, containerised CI/CD
• A UX team working in parallel from day one, still designing in Figma while we were already shipping

Ten months to the end of the evolution phase, and note that the phases below overlap. That matters more than the sequence.

flowchart LR
    subgraph P1["Months 1-3 · certainty = the components"]
        direction TB
        K["KANBAN<br/>3 developers<br/>unit: a component<br/>“how many days?”"]
        S1["STRONG OWNERSHIP<br/>lead architect<br/>unit: the foundations<br/>“how many weeks?”"]
    end
    subgraph P2["Months 4-6 · certainty = the pages"]
        direction TB
        S2["STRONG OWNERSHIP<br/>1 dev = 1 page<br/>unit: a page<br/>“how many weeks?”"]
    end
    subgraph P3["Months 7-10 · certainty = the whole scope"]
        direction TB
        SC1["SCRUM · 3-week sprints<br/>before go-live<br/>functional + quality + security<br/>“how many story points?”"]
        SC2["SCRUM · same cadence<br/>after go-live<br/>post-launch evolutions<br/>“how many story points?”"]
        SC1 --> SC2
    end
    subgraph P4["Month 11+ · no major evolution left"]
        direction TB
        K2["KANBAN AGAIN<br/>maintenance<br/>unit: a ticket<br/>“how many days?”"]
    end
    K --> S2
    S1 --> S2
    S2 --> SC1
    SC2 --> K2

Read that chart again: for the first three months we were running two methods at once. The three developers were pulling components through a Kanban board while the architect was already in strong ownership on the foundations and the deployment pipeline. Nobody found that strange, because nobody was doing "a framework". Each of them was answering the estimation question that fit what they knew.

Months 1–3: Kanban, because we copied Figma

Here is the part I would tattoo on a project charter: we built the code base in the same order UX designed it.

Not by coincidence — by decision. A design system is not drawn page-first. It starts at Typography, then colour and spacing, then the atoms, then Inputs, then Cards, then Table. Pages come last, because a page is an assembly. So the front end followed the same climb: Typography, then the atoms, then Table, then — only then — assembly.

The payoff was scheduling, not elegance. Design and development stopped queuing behind each other and started running side by side; the Gantt compressed instead of stretching. Waiting for finished page designs before writing the first line would have cost us those three months outright.

Kanban fits this moment for a precise reason: it asks you to make your workflow explicit and to limit work in progress (The Kanban Guide) — it never asks you to commit to a scope. We had no scope to commit to. We had certainty about components and nothing else, so we promised in days, and only about components.

Side effect worth the price of admission: those components became a shared vocabulary. When a spec later said "a filterable table with a sticky header", nobody had to guess and nobody had to build it.

Months 4–6: one dev, one page. And no, this is not Extreme Programming.

Then the designs grew into full pages and flows. A ticket stopped being "build Pagination" and became "build the search results page" — days of work across a dozen files. Four people in one Next.js repo, and the cursor had to move: promises in days no longer matched the work.

So each developer owned a page, end to end. Route, data fetching, composition, tests. The architect kept owning the foundations, and reviewed everything. Same board, same dailies, same retro — bigger promise.

I have heard this called Extreme Programming. It is the opposite.

XP explicitly prescribes collective code ownership: "the explicit convention that every team member is not only allowed, but in fact has a positive duty, to make changes to any code file as necessary" (Agile Alliance) — renamed "Shared Code" in the second edition of Beck's book. What we did sits in a different box in Martin Fowler's taxonomy of code ownership: strong ownership (only the owner changes the module), softened into weak ownership (others may, but consult the owner). Fowler openly dislikes strong ownership, and his reason is sound: a trivial change crossing a boundary becomes a negotiation.

Two things made ours cheap:

• The shared layer stayed collective. Components, tokens, utilities — anyone, anytime. Ownership applied to pages, which shared components but not logic.
• Phase 1 paid for phase 2. Pages were independent because three months of Kanban had already extracted everything shareable. Try strong ownership over pages that share business logic and it will hurt you.

If you go there, make ownership executable rather than social: a CODEOWNERS file has GitHub auto-request review from the owner of the touched paths (GitHub Docs). And treat it as a rotation, not a title.

Months 7–10: Scrum, because "done" finally meant something

Two months before go-live, the remaining work changed nature, not size: cross-page functional gaps, accessibility, error states, performance, security review. The boring 20% that is 80% of perceived quality.

That work has a property the earlier work lacked: it is finishable. A Sprint is a fixed-length container with a Sprint Goal and a Definition of Done (Scrum Guide) — an inventory-clearing device, not a productivity device. In Kanban we would have kept pulling improvements forever, because there is always one more.

We ran 3-week Sprints. Deliberately longer than the usual two: security and quality items slice badly into fortnights without producing half-hardened features, and at four people the ceremony overhead of a 2-week cadence was disproportionate. Our Definition of Done grew teeth here — security items became explicit exit criteria rather than good intentions, which is the practical version of what OWASP means by embedding security in the pipeline instead of bolting it on (OWASP DevSecOps Guideline).

One provocation while we are here: we started answering in story points, and story points appear nowhere in the Scrum Guide. The framework asks that items be sized; the currency is our invention. Which rather makes the point — what we adopted was a unit of promise, not a religion.

Then we went live — and kept Sprinting for two more months. The post-launch backlog was made of real evolutions: features deferred to get the launch out, and the first round of changes asked for by actual users. Same cadence, same Definition of Done, same three-week promises.

The honest objections

"Strong ownership created knowledge silos." It is the standard critique and it is the right one to raise — but on our project it did not bite. Holidays came, people covered for each other, and nothing stalled. The reason is unglamorous: the code base was properly declared and documented, the code was readable, and everything went through peer review. Silos are a symptom of unreadable code plus unreviewed merges. Fix those and ownership stops being a fiefdom.

"Switching methods three times must have cost you." Less than you would think, and here is the mechanism: JIRA epics and a refinement ritual for story points existed very early in the project — long before Scrum, and strictly speaking they belong to neither Kanban nor strong ownership. The work was already categorised and already discussed collectively. So each transition changed one number, not a system. That is the practical argument for keeping ceremonies stable and letting only the promise move.

Where the XP crowd still has a point: pair programming, trunk-based development and continuous integration attack merge collisions head-on without drawing organisational boundaries at all, and they distribute knowledge as a side effect rather than as a discipline you must maintain. If your team already pairs well, try that first — you may never need the cursor to leave "days".

One last thing: go-live is not a methodological event

Look at the timeline again. The most-watched date of the whole project — the launch — is the one moment where nothing about our way of working changed. Same Scrum, same three-week Sprints, same board, straight through it. We had shipped to production, and the promise size stayed exactly where it was.

The cursor came back down two months later, and for a completely different reason: the evolutions ran out. What was left was small, independent, unpredictable and free of any scope to commit to — a bug, a content fix, a dependency bump. Sizing that in story points and boxing it into three-week promises adds ceremony to work that has no batch to clear. So maintenance went back to Kanban, and answering in days again.

That is the tell that the certainty rules and the calendar does not. Deadlines, launches and steering committees feel like they should move your method. They don't. What moves it is how much you know — and after launch, on a stable product, you know less about what next week holds than you did during the Sprint. The cursor is a dial, not a ladder. Ours went up for ten months and came back down, and that is not a regression.

What I would tell my past self

Stop asking "which Agile method is right for this project". Ask "how big a promise can we honestly make this month" — the framework name falls out of the answer, and it will be someone else's argument.

Have you moved that cursor mid-project? What told you it was time?

---

Sources: Agile Manifesto · Open Guide to Kanban · Agile Alliance — Collective Code Ownership · Martin Fowler — Code Ownership · GitHub Docs — About code owners · 2020 Scrum Guide · OWASP DevSecOps Guideline