Fondements

Les patterns de Scrum

Un pattern décrit un problème qui revient souvent, les contraintes qui le rendent difficile et une solution que d'autres ont déjà éprouvée. L'idée vient d'un architecte, Christopher Alexander, et elle a été appliquée aux organisations, puis à Scrum. Cet article explique comment lire un pattern de A Scrum Book et ce que l'on peut en attendre.

Une salle d'attente et un coin goûter

Vous arrivez en avance à un rendez-vous et l'on vous fait patienter dans un couloir, sur une chaise, sans rien à faire et sans savoir pour combien de temps. Dans un livre de 1977, A Pattern Language, l'architecte Christopher Alexander et ses coauteurs décrivent ce problème sous le nom « A Place to Wait » (un endroit où attendre). Ils proposent une solution générale : là où des gens doivent attendre, il faut aménager le lieu pour que l'attente devienne un moment positif.

Une quarantaine d'années plus tard, des praticiens de Scrum décrivent un problème voisin. Une équipe travaille bien, sa réputation grandit, et de plus en plus de collègues viennent lui demander un avis ou un coup de main. Chaque visite interrompt quelqu'un. Leur solution porte un nom japonais, Oyatsu Jinja (« sanctuaire du goûter ») : on installe près de l'équipe, mais pas trop près, une table avec du café et de quoi grignoter. Le visiteur s'y installe et attend qu'un membre de l'équipe fasse une pause. Les auteurs précisent que leur croquis s'inspire du pattern d'Alexander.

Ces deux textes ont la même forme : chacun décrit un problème dans sa situation et propose une solution observée à plusieurs endroits. C'est ce que l'on appelle un pattern, mot que l'on traduit parfois par « patron » ou « motif » et que ce site garde en anglais.

De l'architecture aux organisations

Christopher Alexander (1936-2022), professeur d'architecture à l'université de Californie à Berkeley, publie en 1977 avec Sara Ishikawa et Murray Silverstein A Pattern Language, un recueil de 253 patterns qui vont de l'échelle d'une région à celle d'une pièce. Deux ans plus tard, The Timeless Way of Building en expose la théorie. Son idée est que les lieux où l'on se sent bien partagent des formes récurrentes, et que les habitants peuvent apprendre à les reconnaître et à les composer sans s'en remettre entièrement aux spécialistes.

Au début des années 1990, des informaticiens reprennent cette forme pour décrire des solutions de conception de programmes. Un groupe qui prendra le nom de Hillside Group se réunit pour la première fois en août 1993 dans le Colorado, et la première conférence PLoP (Pattern Languages of Programs) a lieu en août 1994 dans l'Illinois. Dès cette époque, James Coplien écrit des patterns qui ne portent pas sur le code mais sur l'organisation des équipes. Avec Neil Harrison, il les rassemble en 2004 dans Organizational Patterns of Agile Software Development.

Scrum et les patterns se croisent tôt. Jeff Sutherland a souvent dit que ces patterns d'organisation avaient compté parmi les sources du premier Scrum. Avec Mike Beedle et d'autres, il présente dès 1998 une collection de « patterns Scrum » dans une conférence de patterns. Une conférence annuelle, ScrumPLoP, se tient à partir de mai 2010. Chaque pattern y est relu et critiqué par d'autres auteurs, parfois une douzaine. Le livre qui en résulte, A Scrum Book: The Spirit of the Game, paraît en 2019 chez Pragmatic Bookshelf sous les noms de Jeff Sutherland, James Coplien et du Scrum Patterns Group, dont dix-huit membres sont nommés. Lachlan Heasman, Mark den Hollander et Cesário Ramos en ont formé l'équipe éditoriale avec Coplien.

Ce groupe a résumé son but en 2011 : le Guide Scrum donne les règles sans leurs raisons, et les patterns servent à mettre ces raisons par écrit pour qu'elles puissent se transmettre.

Comment lire un pattern

Tous les patterns du livre suivent le même plan, repris d'Alexander. Le tableau le détaille avec l'exemple d'Oyatsu Jinja.

Les forces sont la partie la plus instructive. Les auteurs précisent qu'il faut y ranger les contraintes matérielles, mais aussi les instincts, les aspirations et les peurs des personnes. Elles expliquent pourquoi le problème ne se règle pas tout seul, et elles permettent au lecteur de vérifier si sa propre situation ressemble à celle du pattern. Quand vos forces sont différentes, la solution proposée n'est probablement pas la bonne pour vous.

Deux conventions aident à s'orienter. Chaque pattern porte un numéro précédé du signe ¶ (The Spirit of the Game est le ¶1). Son nom est aussi suivi de zéro, une ou deux étoiles, qui indiquent la confiance des auteurs. Deux étoiles signifient qu'ils pensent que toute équipe Scrum finira par avoir besoin de cette solution. Une étoile signifie que le pattern est au cœur d'une bonne solution sans être la seule possible. L'absence d'étoile signifie que la solution fonctionne souvent, mais que d'autres existent.

Un pattern ne s'applique pas seul

Les auteurs mettent en garde contre la tentation de choisir un pattern isolé pour régler un problème isolé. Ils prennent l'exemple d'une organisation qui décide de rendre ses équipes autonomes, parce que l'autonomie lui paraît centrale. Elle constate bientôt que les équipes ne peuvent pas l'être : il leur manque des compétences, et elles dépendent sans cesse de personnes extérieures. Il fallait d'abord s'engager à réunir dans l'équipe toutes les compétences nécessaires (le pattern Cross-Functional Team), et ensuite seulement viser l'autonomie (Autonomous Team).

C'est pourquoi les patterns sont organisés en langages de patterns. Un langage a une grammaire, qui indique quelles combinaisons ont un sens. Dans un langage de patterns, chaque pattern indique ceux qu'il suppose déjà en place et ceux qui peuvent le compléter. Le livre contient deux langages, l'un pour l'organisation et l'autre pour le flux de valeur, que présente l'article sur le cœur de Scrum en patterns.

Une séquence est un chemin dans un langage, c'est-à-dire la liste ordonnée des patterns qu'une équipe décide d'appliquer. Le livre en donne cinq en exemple, et il invite chaque équipe à composer la sienne. La règle d'usage est d'appliquer un seul pattern à la fois, afin de pouvoir juger de son effet, et de revenir en arrière s'il ne convient pas. Un pattern du livre, One Step at a Time (« un pas à la fois »), porte sur ce point.

Pour s'y retrouver parmi les 94 patterns du livre, une annexe en donne les patlets, des résumés d'une ou deux phrases qui tiennent en une paire problème-solution. Le patlet de Small Teams dit par exemple, en substance, que beaucoup de personnes sur un même travail font gonfler le coût de la communication, et qu'il vaut donc mieux de petites équipes qui traitent le travail en série.

Écrire ses propres patterns

Les auteurs considèrent leur recueil comme un point de départ. Ils invitent chaque organisation à écrire les patterns qui lui manquent, et ils rappellent qu'un critère sépare un pattern d'une bonne idée : la solution doit avoir été observée plusieurs fois, dans des lieux qui ne se sont pas copiés. Le livre raconte que Coplien a rédigé en 1993 l'un de ses premiers patterns d'organisation, sur le travail en binôme, après une discussion avec Paul Chisholm et Ward Cunningham où ils en avaient repéré trois usages indépendants. Les auteurs disent aussi avoir écarté des dizaines de candidats qui ne reposaient que sur des anecdotes.

Cet exemple montre ce qu'un pattern apporte de plus qu'une consigne. La consigne dirait « relève à 12 h 50 ». Le pattern dit dans quelle situation la solution vaut, ce qu'elle coûte et ce qu'elle entraîne.

Guide et patterns : deux statuts différents

Le Guide Scrum énonce des règles et se dit « immuable ». Les patterns ont un autre statut. Le livre compare le Guide au livret de règles des échecs, qu'il faut connaître mais qui ne fait pas un bon joueur, et il présente ses patterns comme des stratégies que l'on peut adapter ou refuser. Il écrit qu'il est risqué de les ignorer, et que seule une organisation qui ne réfléchit pas les suivrait à la lettre. L'édition 2020 du Guide reconnaît d'ailleurs cette répartition : elle indique que des patterns et des pratiques complètent le cadre, et que leur description relève d'autres sources parce qu'ils dépendent du contexte.

Il faut aussi savoir que le livre a été écrit avant l'édition 2020 du Guide, et que ses références citent celle de 2016. Son vocabulaire est donc plus ancien : il parle de « Development Team » et non de « Developers », écrit « ScrumMaster » en un mot, compte trois « rôles » et ne connaît pas le Product Goal. Sur un point, il a devancé le Guide. Son introduction explique que le Daily Scrum sert à replanifier le Sprint et que les trois questions habituelles n'en sont qu'un moyen. L'édition 2020 du Guide a retiré ces trois questions.

Limites et pièges

Un pattern est de l'expérience mise en forme. Les patterns de Scrum ont été observés par des praticiens dans de nombreuses équipes, puis relus par leurs pairs. Ce ne sont pas pour autant des résultats d'essais contrôlés. Quand le livre parle de validation empirique, il s'agit d'observations répétées par la communauté des auteurs, dont plusieurs vivent de la formation et du conseil en Scrum. Les équipes où une solution a échoué sans que personne ne l'écrive n'apparaissent pas dans le recueil. L'article Critiques et état des preuves revient sur cette différence.

Les étoiles ne mesurent rien d'autre que la conviction des auteurs. Le vocabulaire hérité d'Alexander, qui parle de « qualité sans nom » et de « tout » avec une majuscule, peut séduire ou agacer, mais il ne se prête pas à la vérification.

Deux mésusages sont fréquents. Le premier consiste à piocher une solution sans lire son contexte ni ses forces, comme dans l'exemple de la machine à café. Le second consiste à transformer le recueil en liste de contrôle et à compter les patterns « mis en place », ce qui revient à refaire avec les patterns l'erreur que le livre reproche à ceux qui appliquent le Guide mécaniquement.