{
  "id": 4652061,
  "title": "Arrêtez de choisir une méthode Agile. Choisissez une taille de promesse.",
  "url": "https://urgent.news/2026/08/31/arretez-de-choisir-une-methode-agile-choisissez-une-taille-de-promesse",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-31T14:05:51.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/karkael/arretez-de-choisir-une-methode-agile-choisissez-une-taille-de-promesse-195g"
  },
  "original_language": "fr",
  "account": "The debate between Scrum and Kanban is a marketing ploy, promising certifications, conference tracks, and tribe branding. Yet, at its core, it obscures a more valuable truth: these methodologies are quite similar. On our project, we experimented with three different methods over ten months, and the only change was the size of the promise – the scope of what one person took responsibility for.\n\nThroughout the project, we held daily, weekly, refinement, and retro meetings from the first to the last day, regardless of the methodology. Scrum added only two events: planning and demo. The variable that changed was the size of the promise – the amount of work a person committed to. The estimation unit shifted from Kanban's \"how many days for this component?\" to Scrum's \"how many story points?\" and back again.\n\nOur certainty in the estimation changed throughout the project. It wasn't maturity, a coach's advice, or a framework's promise that shifted the needle. Instead, it was the level of certainty we had in the moment. Anonymous, but the configuration was straightforward: four people, including the lead architect who also coded in Next.js and React, a parallel UX team from day one, and containerized CI/CD.\n\nThe first three months saw a blend of Kanban and Strong Ownership. Developers pulled components from a Kanban board, while the lead architect took strong ownership of the core and deployment pipeline. No one found this peculiar, as no one was pretending to follow a strict framework. Each person answered the estimation question that matched their understanding. From months 1 to 3, Kanban was used because we mirrored the UX designer's workflow. A design system wasn't drafted page by page but followed a logical progression: Typography, colors and spacing, atoms, basic components, and finally, complex pages. The front-end developers followed the same path, leading to a compressed schedule rather than an elongated one.\n\nWaiting for finished mockups before starting coding would have cost us those three months. Kanban helped by making the flow explicit and limiting work in progress – it never demanded engagement with a scope. We had certainty about the components and nothing else, so we promised in days, focusing solely on components. This component vocabulary became a common ground for everyone. When a spec later mentioned a \"collapsible header table,\" no one had to guess or build it themselves.",
  "summary": "Version originale en anglais : https://dev.to/karkael/stop-picking-a-method-pick-a-promise-size-3956 Commençons par le débat auquel je ne crois plus : Scrum contre Kanban. C'est un débat de vitrine. Il vend des certifications, il remplit des tracks de conférence, il permet de mettre une tribu dans sa bio. Et il masque quelque chose de bien plus utile : ces méthodes sont voisines . Sur notre…",
  "key_points": [
    "Experimented with Scrum, Kanban, and Strong Ownership methods",
    "Changed only the size of the promise, not methodology",
    "Four-person team with lead architect and parallel UX team"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}