Scrum sans empirisme: pourquoi ça échoue

Le Scrum Guide repose sur l'empirisme, trois piliers et cinq valeurs. Comprendre ces fondements évite le piège du Scrum mécanique, réduit aux rituels.

Beaucoup d’équipes adoptent Scrum en commençant par ses mécanismes: les sprints de deux semaines, le daily de quinze minutes, le product backlog. Elles reproduisent les cérémonies avec discipline, renomment leurs chefs de projet en Scrum Masters, puis constatent après quelques mois que rien n’a fondamentalement changé. Les réunions s’accumulent, les livrables restent en retard et la promesse d’agilité ressemble de plus en plus à une couche administrative supplémentaire.

Ce phénomène porte un nom dans la communauté Scrum: le “Zombie Scrum”, un cadre dont on exécute la forme sans en habiter la logique. Pour comprendre pourquoi ces implémentations échouent, il faut revenir à ce que le Scrum Guide pose comme fondement, bien avant les rôles et les événements: l’empirisme.

L’empirisme, une réponse à la complexité

L’empirisme, dans le contexte Scrum, désigne un mode de prise de décision fondé sur l’observation et l’expérience plutôt que sur des hypothèses formulées en amont. Le Scrum Guide 2020 l’affirme dès ses premières lignes: Scrum est conçu pour des problèmes “complexes”, c’est-à-dire des situations où les exigences évoluent, où les solutions ne sont pas connues d’avance et où l’information disponible au démarrage est structurellement insuffisante pour planifier l’ensemble du projet.

Face à cette complexité, deux philosophies s’opposent: l’approche prédictive consiste à investir un effort considérable dans la planification initiale, puis à exécuter le plan tel quel, tandis que l’approche empirique reconnaît que cette planification détaillée repose sur des hypothèses qui seront en partie invalidées par la réalité, et préfère créer des cycles courts d’observation, d’évaluation et de correction.

Scrum choisit résolument la seconde voie, en y ajoutant les principes de la pensée lean (lean thinking), qui vise à éliminer les activités ne créant pas de valeur pour concentrer les efforts sur l’essentiel. Ce choix n’est ni idéologique ni dogmatique: c’est une réponse pragmatique à un constat que tout chef de projet expérimenté reconnaîtra, à savoir qu’un plan détaillé à douze mois est une fiction confortable, pas un outil de pilotage fiable.

Trois piliers qui forment une séquence

Les trois piliers de Scrum, souvent présentés comme une triade équivalente, forment en réalité une séquence causale où chaque pilier dépend du précédent.

Transparence: rendre visible ce qui compte

La transparence exige que tout ce qui influence le travail soit visible pour ceux qui le réalisent et ceux qui le reçoivent. Cela va au-delà d’un tableau Kanban à jour ou d’un burndown chart affiché dans un couloir. La transparence suppose un langage commun, des définitions partagées comme la Definition of Done (les critères qu’un incrément doit remplir pour être considéré comme terminé), et surtout l’honnêteté sur l’état réel de l’avancement. Quand une équipe masque ses difficultés pour paraître performante, la transparence est rompue et tout ce qui suit perd sa valeur.

Inspection: observer à intervalles réguliers

Scrum organise l’inspection à travers ses événements. Le Daily Scrum examine la progression vers le Sprint Goal (l’objectif que l’équipe s’est fixé pour le sprint en cours). La Sprint Review inspecte l’incrément livré en présence des parties prenantes. La Sprint Retrospective porte sur les méthodes de travail de l’équipe elle-même. La cadence fixe des sprints garantit que ces inspections ont lieu régulièrement, indépendamment de la pression du moment, car c’est précisément quand la pression est forte que l’envie de sauter une inspection est la plus grande.

Adaptation: corriger sans attendre

Si l’inspection révèle un écart entre ce qui est observé et ce qui est attendu, l’équipe doit ajuster son approche au plus tôt. Le Scrum Guide insiste sur la rapidité de cette réaction, car plus on tarde à corriger une déviation, plus le coût de correction augmente. Cette capacité d’adaptation suppose que l’équipe dispose d’une autonomie suffisante pour modifier son plan de sprint ou ses pratiques sans escalader chaque décision à un comité de pilotage.

Le point crucial est l’interdépendance de ces trois piliers. Une transparence sans inspection n’est que de la documentation que personne ne consulte. Une inspection sans adaptation réelle n’est qu’un rite formel où l’on constate les problèmes sans les résoudre. Et une adaptation sans transparence préalable revient à improviser dans le brouillard.

Les cinq valeurs: rendre l’empirisme humainement possible

Les cinq valeurs Scrum, à savoir engagement, focalisation, ouverture, respect et courage, ressemblent à première vue à un catalogue de bonnes intentions. Elles remplissent pourtant une fonction très concrète: créer les conditions humaines sans lesquelles l’empirisme ne peut pas fonctionner.

L’ouverture est la condition comportementale de la transparence. Si un développeur n’ose pas dire qu’il est en difficulté par peur d’être jugé, la transparence est impossible, quel que soit le nombre d’outils de reporting déployés. Le courage prolonge cette logique: il faut pouvoir remettre en question un Sprint Goal irréaliste, signaler un obstacle que personne ne veut voir ou admettre qu’une fonctionnalité livrée ne répond pas aux attentes.

L’engagement s’entend ici comme un engagement collectif envers les objectifs de l’équipe, pas comme une obligation individuelle de respecter une estimation. La focalisation protège la capacité de l’équipe à livrer un incrément réellement terminé en limitant le multitâche et les interruptions extérieures. Le respect, enfin, garantit que les décisions se prennent sur la base de ce qui est observé plutôt qu’en vertu d’une position hiérarchique.

Le Scrum Guide le formule clairement: “quand ces valeurs sont incarnées par l’équipe Scrum et les personnes avec qui elle travaille, les piliers empiriques prennent vie et instaurent la confiance.”

Reconnaître le Scrum mécanique

La question la plus utile qu’un chef de projet puisse se poser face à son implémentation Scrum n’est pas “est-ce qu’on fait tous les événements?” mais “est-ce que nos événements produisent de l’apprentissage?”. Des daily scrums réduits à des tours de table rituels, des sprint reviews conçues comme des démonstrations où l’on ne montre que ce qui fonctionne, des rétrospectives qui produisent des listes d’améliorations jamais mises en oeuvre: ces pratiques ont l’apparence de Scrum, mais elles ne génèrent ni feedback exploitable ni adaptation réelle, comme le souligne un article de scrum.org sur la crise de maturité de l’agilité.

Quand Scrum est réduit à ses rituels sans la philosophie empirique qui les justifie, le résultat est souvent pire que l’absence de méthode: une bureaucratie agile qui consomme du temps et de l’énergie sans créer les boucles d’apprentissage qui sont sa raison d’être.