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.
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.
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.
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.
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.
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.