Beaucoup d’équipes affirment pratiquer Scrum tout en ayant modifié certaines règles du cadre, parfois dès les premières semaines d’adoption. Elles ont des sprints, un backlog, un Scrum Master, le vocabulaire est en place, mais certains ajustements, souvent présentés comme du pragmatisme, portent un nom: le ScrumBut.
Qu’est-ce que le ScrumBut?
Le terme, documenté par Scrum.org, désigne toute modification du cadre Scrum qui sert à éviter un inconfort plutôt qu’à le résoudre. Il suit une formule caractéristique: (Nous utilisons Scrum, mais)(Raison)(Contournement). Par exemple: “Nous utilisons Scrum, mais nos sprints sont trop courts pour tout finir, donc nous les avons allongés à six semaines.” La raison semble valable, le contournement semble logique, mais le problème de fond (un découpage du travail inadapté, des priorités mal définies) reste intact.
Ce qui distingue le ScrumBut d’une adaptation légitime, c’est que la modification supprime un mécanisme sans traiter la cause qui le rendait inconfortable. Le Scrum Guide définit chaque événement comme un moment formel d’inspection et d’adaptation: retirer l’un d’eux revient à désactiver un capteur dans un système conçu pour l’autorégulation.
Les ScrumButs les plus fréquents
Certaines dérives reviennent avec une régularité remarquable, comme l’a montré une étude empirique publiée dans Information and Software Technology (Mathew, Pillai et Pakenham-Walsh, 2015), qui a analysé les pratiques de 18 équipes dans 11 organisations.
Le daily scrum (mêlée quotidienne) réduit ou supprimé. L’argument typique est que “ça prend trop de temps” ou que “tout le monde sait déjà ce que font les autres”. En réalité, un daily scrum qui dure trop longtemps indique généralement que l’équipe est trop grande, que les sujets abordés dépassent le cadre de la synchronisation quotidienne ou que la facilitation fait défaut. La solution n’est pas de supprimer la réunion, mais de comprendre pourquoi elle déborde.
La rétrospective abandonnée. C’est l’un des ScrumButs les plus répandus et les plus coûteux. Les raisons invoquées vont de “on n’a pas le temps” à “ça ne change jamais rien”. Une analyse des dysfonctionnements de rétrospective publiée par Scrum.org identifie cinq causes récurrentes, dont l’absence de suivi des actions décidées et la tendance à accumuler trop d’éléments sans prioriser. Le problème n’est pas l’événement lui-même, c’est sa facilitation.
Les sprints de durée variable ou excessive. Scrum recommande des sprints d’un mois maximum. Des sprints de six semaines ou plus traduisent souvent une difficulté à définir des objectifs de sprint atteignables, ou une pression organisationnelle à livrer des lots volumineux plutôt que des incréments réguliers.
Le Product Owner absent ou remplacé par le management. Dans certaines équipes, le backlog est géré directement par un responsable hiérarchique qui n’assiste ni à la planification de sprint ni à la revue. Le Product Owner, quand il existe formellement, n’a aucune autorité réelle sur les priorités. Ce ScrumBut est particulièrement difficile à corriger parce qu’il touche à la gouvernance de l’organisation, pas seulement aux pratiques de l’équipe.
ScrumBut ou ScrumAnd: la distinction essentielle
Toute modification de Scrum n’est pas un ScrumBut. Le terme ScrumAnd désigne l’ajout de pratiques complémentaires au cadre de base, par exemple l’intégration d’un tableau Kanban pour visualiser le flux de travail ou l’adoption du TDD (Test-Driven Development, développement piloté par les tests) pour améliorer la qualité du code.
La différence tient à la direction du changement: le ScrumAnd enrichit le cadre en ajoutant des pratiques une fois que l’équipe maîtrise les fondamentaux, tandis que le ScrumBut l’appauvrit en retirant des éléments avant même que l’équipe ait eu l’occasion d’en tirer les bénéfices. Concrètement, une équipe qui ajoute des métriques de flux à son sprint review fait du ScrumAnd; une équipe qui supprime la sprint review parce qu’elle “prend trop de temps” fait du ScrumBut. Le premier signe traduit une maturité croissante, le second un évitement.
Comment diagnostiquer un ScrumBut dans votre équipe
Un exercice simple consiste à lister chaque événement et artefact du cadre Scrum tel que défini dans le Scrum Guide, puis à vérifier si votre équipe les pratique réellement. Pour chaque écart, appliquez la formule ScrumBut: identifiez la raison invoquée et le contournement adopté. Si la raison pointe vers un problème organisationnel (manque de temps, conflit d’équipe, pression hiérarchique) et que le contournement consiste à supprimer ou diluer l’événement, vous êtes en présence d’un ScrumBut.
La question révélatrice à poser lors de cet exercice est la suivante: “Quel problème cet événement rendait-il visible, et pourquoi avons-nous préféré ne plus le voir?” Si la réponse met en lumière un dysfonctionnement que l’équipe a choisi de contourner plutôt que de résoudre, le diagnostic est posé.
La correction ne passe pas par un retour brutal aux pratiques complètes, ce qui risquerait de renforcer la résistance. Elle demande d’abord de nommer le problème sous-jacent ouvertement, puis de réintroduire progressivement l’événement modifié en traitant sa cause réelle. Si les rétrospectives ont été supprimées parce qu’elles ne produisaient aucun changement, la priorité est de garantir le suivi des actions, pas de rétablir la réunion en espérant un résultat différent.
Le vrai test de maturité
La capacité d’une équipe à pratiquer Scrum sans ScrumBut n’est pas une question de rigueur méthodologique, c’est une question de culture. Les trois piliers de Scrum (transparence, inspection, adaptation) exigent un environnement où il est possible de rendre les problèmes visibles sans conséquences négatives. Tant que cette condition n’est pas remplie, le ScrumBut restera la réponse naturelle d’équipes qui préfèrent le confort d’un cadre dégradé à l’inconfort d’un diagnostic honnête.