Fondements

L'empirisme : transparence, inspection et adaptation

Le Guide Scrum résume sa théorie en une phrase : la connaissance vient de l'expérience, et l'on décide d'après ce que l'on observe. Cet article explique ce que cela implique, pourquoi Scrum distingue trois piliers (la transparence, l'inspection et l'adaptation) et comment chaque événement du cadre les met en œuvre.

Suivre la recette ou goûter le plat

Un cuisinier qui prépare pour la centième fois une pâte à crêpes suit sa recette sans y penser : les mêmes quantités et les mêmes gestes donnent le même résultat. Le même cuisinier qui met au point un nouveau plat procède autrement. Il essaie, goûte, corrige l'assaisonnement et goûte encore. Il ne peut pas écrire la recette avant d'avoir cuisiné, parce qu'il ne sait pas encore ce qui conviendra.

Les spécialistes du contrôle des procédés industriels distinguent ces deux situations. Un procédé est dit « défini » quand on le connaît assez bien pour qu'en répétant les mêmes étapes on obtienne le même résultat. Quand le procédé est trop complexe pour être décrit ainsi, on le pilote de façon « empirique » : on mesure fréquemment ce qui en sort, et l'on ajuste. Ken Schwaber raconte dans ses livres qu'il a soumis, au milieu des années 1990, les méthodes de développement de logiciel de l'époque à des chercheurs de l'entreprise chimique DuPont, dont Babatunde Ogunnaike, coauteur d'un manuel sur le contrôle des procédés. Leur avis, tel qu'il le rapporte, était que le développement de logiciel était géré comme un procédé défini alors qu'il relevait du pilotage empirique.

Scrum est construit sur cette idée. Le Guide de 2020 le dit fondé sur l'empirisme et sur la pensée Lean. En philosophie, l'empirisme désigne les doctrines qui font venir la connaissance de l'expérience, comme celles de John Locke ou de David Hume. Le Guide emploie le mot dans un sens pratique : il désigne une façon de conduire un travail dont on ne peut pas connaître l'issue à l'avance.

Quand un plan détaillé ne suffit plus

Le Guide destine Scrum aux problèmes complexes. Les auteurs de A Scrum Book en donnent un critère simple : un problème est complexe quand on ne le comprend vraiment qu'en voyant sa solution, et que l'on ne peut pas déduire cette solution à l'avance. La mise au point d'un nouveau produit en est l'exemple type. On explique facilement pourquoi un produit a réussi une fois qu'il a réussi, mais personne ne pouvait en être certain avant.

Dans ce cas, un plan long et détaillé donne une impression de maîtrise qu'il ne procure pas. Le Guide l'écrit ainsi dans sa traduction française : « Seul ce qui s'est déjà passé peut être utilisé pour une prise de décision à venir. » Scrum en tire une approche itérative et incrémentale. L'équipe avance par petits pas, produit à chaque pas quelque chose que l'on peut examiner, et décide du pas suivant d'après ce qu'elle a vu. Le Guide y voit un moyen d'améliorer la prévisibilité et de limiter le risque, puisqu'une erreur de direction se découvre au plus tard à la fin du Sprint.

Trois piliers qui se tiennent

La transparence

Le travail et la façon de le faire doivent être visibles pour ceux qui l'effectuent et pour ceux qui le reçoivent. Dans Scrum, les décisions importantes reposent sur l'état perçu des trois artefacts : le Product Backlog, le Sprint Backlog et l'Increment. Si ces artefacts donnent une image fausse, les décisions prises d'après eux diminuent la valeur et augmentent le risque. C'est pourquoi le Guide attache à chaque artefact un engagement, qui indique par rapport à quoi le lire : le Product Goal pour le premier, le Sprint Goal pour le deuxième et la Definition of Done pour le troisième.

L'inspection

Les artefacts et la progression vers les objectifs doivent être examinés souvent et avec soin, afin de repérer les écarts et les problèmes. Les cinq événements de Scrum donnent sa cadence à cet examen.

L'adaptation

Si un aspect du processus sort des limites acceptables, ou si le produit obtenu ne convient pas, il faut ajuster ce que l'on fait ou ce que l'on produit, et le faire le plus tôt possible pour que l'écart ne se creuse pas. Le Guide précise que l'adaptation devient plus difficile quand les personnes concernées n'ont pas les moyens de décider. C'est l'une des raisons pour lesquelles il veut une équipe autogérée.

Le Guide relie les trois notions par deux phrases : « La transparence permet l'inspection » et « L'inspection permet l'adaptation ». Il ajoute qu'une inspection sans transparence est trompeuse, et qu'une inspection sans adaptation est « infructueuse ». Les trois piliers dépendent donc l'un de l'autre, comme le montre l'exemple qui suit.

Quatre occasions d'inspecter dans chaque Sprint

Le Guide présente chaque événement comme une occasion formelle d'inspecter et d'adapter les artefacts. Le Sprint sert de conteneur aux quatre autres.

Deux objets sont donc examinés à chaque Sprint : le produit, lors de la Sprint Review, et la manière de travailler, lors de la Sprint Retrospective. Les auteurs de A Scrum Book insistent sur le second. Pour eux, le Sprint est en premier lieu un cycle d'amélioration du processus, et en second lieu un cycle de livraison.

Les trois piliers se reconnaissent dans cet exemple. La transparence vient de ce que la séance a réellement eu lieu et que tous regardent les mêmes enregistrements, au lieu de discuter d'un document. L'inspection est régulière et porte sur ce que font les élèves. L'adaptation est immédiate, puisque la grille change dès le cycle suivant. Si les quatre professeurs avaient rédigé tout le parcours avant de l'essayer, ils auraient découvert ces problèmes en janvier, devant toutes les classes à la fois.

Empirisme, PDCA et pensée Lean

L'introduction de A Scrum Book rapproche le couple « inspecter et adapter » de deux autres cycles. Le premier est le PDCA (planifier, faire, vérifier, agir), attaché au nom de W. Edwards Deming, qui préférait dire PDSA en remplaçant « vérifier » par « étudier ». Le second est ce que l'architecte Christopher Alexander appelle le processus fondamental. Dans les trois cas, on agit, on regarde le résultat et l'on corrige. L'histoire exacte du PDCA est racontée dans l'article Le PDCA et le rapport A3 du corpus Lean.

On peut lire un Sprint comme un tour de cette roue. Le Sprint Planning correspond à la planification, le travail du Sprint à la réalisation, la Sprint Review et la Sprint Retrospective à l'étude des résultats, et les décisions qui en sortent à l'ajustement. Scrum y ajoute une cadence fixe et courte, d'un mois au plus, et un second tour plus rapide, celui du Daily Scrum, qui se fait chaque jour.

La pensée Lean, seconde source nommée par le Guide, apporte le souci de réduire le gaspillage et de se concentrer sur l'essentiel. Les deux sources se rejoignent : un travail que personne n'a examiné pendant six mois et qui se révèle inutile est un gaspillage qu'un cycle court permet de limiter.

Les patterns eux-mêmes sont à appliquer de façon empirique. Le livre recommande de n'introduire qu'un changement à la fois (pattern One Step at a Time, « un pas à la fois »), afin de savoir à quoi attribuer une amélioration, et de revenir en arrière quand le changement ne donne rien.

Limites et pièges

La transparence se retourne facilement en surveillance. Quand ce qui est rendu visible sert à juger les individus, chacun apprend à présenter un tableau rassurant, et la transparence recule. Le Guide lie d'ailleurs les piliers aux valeurs de Scrum : sans respect et sans courage, personne ne montre un travail en difficulté (voir L'esprit du jeu).

L'inspection sans adaptation est le piège le plus courant. Une Sprint Review réduite à une démonstration que l'on applaudit et une Sprint Retrospective qui relève les mêmes problèmes d'un Sprint à l'autre respectent le calendrier et ne changent rien.

Les mesures peuvent tromper. Une équipe dont on fait de la vélocité un objectif apprend à gonfler ses estimations, et le chiffre cesse de renseigner sur le travail (voir La loi de Goodhart).

Un Sprint n'a pas la rigueur d'une expérience scientifique. Il n'y a pas de groupe témoin, plusieurs choses changent en même temps, et l'on attribue volontiers une amélioration à la dernière décision prise. L'empirisme de Scrum est une discipline d'observation régulière, utile pour corriger une trajectoire. Il ne permet pas d'établir solidement des relations de cause à effet.

L'empirisme ne dispense pas non plus de prévoir. Scrum planifie beaucoup, à chaque Sprint et chaque jour, et il renonce seulement à tenir un plan lointain pour acquis. Certains travaux se prêtent mal à ce fonctionnement, parce que l'on ne peut pas y produire en un mois un résultat partiel qui vaille d'être examiné, ou parce qu'une erreur y est irréversible.

Enfin, l'idée qu'un pilotage empirique convient mieux qu'un plan détaillé à un travail complexe est cohérente avec la théorie du contrôle des procédés. L'efficacité de Scrum lui-même reste cependant peu établie par des études indépendantes, comme l'explique l'article Critiques et état des preuves.