L'organisation

La Scrum Team

Une Scrum Team est une petite équipe qui réunit tout ce qu'il faut pour fabriquer un produit et le remettre à ses utilisateurs, sans dépendre d'un autre service. Quatre patterns de A Scrum Book expliquent ce choix : Scrum Team, Conway's Law, Small Teams et Cross-Functional Team.

Six semaines pour changer une phrase

Une mutuelle veut modifier une phrase de son formulaire d'adhésion en ligne, parce qu'elle induit les adhérents en erreur sur la date d'effet du contrat. La demande part du service juridique vers l'équipe chargée des spécifications, qui rédige une fiche. L'équipe des écrans modifie la page, l'équipe des données ajoute un champ, l'équipe de test vérifie l'ensemble trois semaines plus tard, et l'équipe d'exploitation met en ligne à la date prévue pour le lot suivant. Il s'est écoulé six semaines, et chacun a fait son travail correctement.

Le temps s'est perdu entre les équipes, à chaque passage de relais. La demande a attendu son tour dans cinq files, et chaque équipe a dû comprendre de nouveau ce que la précédente savait déjà.

Scrum Team : une petite entreprise dans l'entreprise

Le pattern Scrum Team (« équipe Scrum », deux étoiles) a pour contexte une personne qui a la Vision d'un produit et quelques idées notées, sans savoir encore comment le fabriquer ni si ces idées sont justes. Son problème est qu'une grande Vision dépasse ce qu'une personne seule peut faire : il faut construire un produit complexe, le mettre entre les mains de ses utilisateurs et tirer parti de leurs retours.

Le pattern décrit plusieurs forces.

• Trop de spécialisation prive l'équipe d'une compétence au moment où elle en a besoin, parce que les besoins varient d'une livraison à l'autre.
• Séparer ceux qui connaissent le besoin de ceux qui fabriquent crée un passage de relais. Les premiers passent commande, souvent avec une échéance fixée sans savoir ce qui est faisable, et il ne reste aux seconds qu'à aller plus vite.
• Celui qui ne fabrique qu'une petite partie, comme sur une chaîne de montage, perd de vue le produit entier.
• On apprend mieux avec des retours rapides et des regards différents, et ceux qui sont pris par la fabrication n'ont guère le temps de réfléchir à leur manière de travailler.

La solution est de former une équipe qui possède toutes les compétences nécessaires : ceux qui savent fabriquer et livrer le produit (la Development Team), un Product Owner qui en oriente la direction et un ScrumMaster (le livre l'écrit en un mot) qui aide l'équipe à apprendre et à s'améliorer. L'équipe fonctionne comme une petite entreprise au sein de l'organisation, capable de prendre seule les décisions qui répondent à ses clients. Le pattern précise que c'est en général le Product Owner qui fait naître l'équipe, et que le Product Owner et les développeurs choisissent ensemble le ScrumMaster.

Selon le livre, Jeff Sutherland a tiré cette forme de la cellule de travail du système de production Toyota, en partageant le rôle de son ingénieur en chef entre le Product Owner, pour le souci du client, et le ScrumMaster, pour celui du processus.

Conway's Law : l'organisation se retrouve dans le produit

En 1968, l'informaticien Melvin Conway publie dans la revue Datamation un article intitulé « How Do Committees Invent? ». Il y soutient qu'une organisation qui conçoit un système produit une conception calquée sur sa propre structure de communication. Fred Brooks a donné à cette observation le nom de « loi de Conway » dans The Mythical Man-Month (1975). Le formulaire de la mutuelle en est une illustration : il est découpé en couches (écrans, données et tests) parce que l'entreprise l'est.

Le pattern Conway's Law (« loi de Conway », deux étoiles) en tire une règle pour concevoir les organisations. Son problème est que la communication et les retours sont au centre du développement d'un système complexe, et que la structure de l'organisation devrait donc favoriser les chemins de communication les plus importants.

Les forces tirent dans des sens opposés. On communique le mieux avec ceux que l'on côtoie, et les petites équipes sont les plus efficaces, ce qui oblige à découper le travail. Une équipe développe cependant une identité et accorde moins d'importance à ce qui vient de l'extérieur, de sorte qu'un découpage unique étouffe les idées qui traversent les frontières.

La solution est d'organiser les personnes en petites équipes d'environ cinq membres, découpées selon ce qui compte le plus pour la création de valeur, et de compléter cette structure par quelques groupes transversaux pour les préoccupations secondaires. Ce qui compte le plus est en général le marché. Les équipes Scrum se forment donc autour de ce qui est livré aux utilisateurs, et non autour des composants internes ou des métiers. Le pattern prend l'exemple d'un fabricant de téléphones, avec une équipe pour le carnet d'adresses, une pour l'agenda et une pour les fonctions d'appel. Des groupes transversaux fixent les règles communes, comme l'apparence des écrans (pattern Birds of a Feather, voir Des équipes stables et réunies).

Le pattern déconseille l'organisation inverse, où chaque équipe possède une partie du produit. La moindre évolution demande alors de coordonner plusieurs équipes, les décisions ne se prennent plus sur place et les retours arrivent tard.

Small Teams : pourquoi cinq personnes plutôt que quinze

Le pattern Small Teams (« petites équipes », deux étoiles) part d'une tentation : devant une montagne de travail, on voudrait y affecter le plus de monde possible. Son problème est que le travail complexe, comme la conception d'un produit, demande beaucoup de connaissances partagées et de coordination, et qu'il résiste à cette approche.

Certaines forces poussent à grossir : plusieurs regards corrigent les biais d'un seul, les échéances incitent à ajouter du monde, et le prestige d'un responsable se mesure parfois à la taille de son équipe. D'autres s'y opposent. Plus un groupe grandit, plus la communication coûte cher, et certains en font moins qu'ils n'en feraient seuls, ce que les psychologues appellent la paresse sociale. Le pattern cite Ivan Steiner (1972), pour qui la productivité réelle d'un groupe est sa productivité potentielle diminuée des pertes dues à la coordination.

Un calcul simple montre l'ampleur du phénomène. Dans un groupe de n personnes, le nombre de relations deux à deux est n × (n − 1) / 2. Cinq personnes ont 10 relations à entretenir, sept en ont 21, dix en ont 45 et quinze en ont 105. Fred Brooks en avait tiré en 1975 une formule restée célèbre : ajouter des personnes à un projet logiciel en retard le retarde davantage.

La solution est d'employer de petites équipes qui traitent le travail en série, plutôt que de rechercher un faux parallélisme. Le pattern parle d'environ cinq personnes sans fixer de nombre, et il conseille d'expérimenter. Parmi les études qu'il cite, une expérience de Tatsuya Kameda et de ses collègues (1992) sur des groupes de deux, quatre, six et douze personnes trouve la meilleure performance par membre dans les groupes de quatre, et une étude de 2012 sur des projets logiciels trouve une productivité plus faible à partir de neuf personnes. Si l'équipe grossit malgré tout, le pattern Mitosis décrit comment la scinder (voir Passer à l'échelle).

Cross-Functional Team : toutes les compétences dans l'équipe

Le pattern Cross-Functional Team (« équipe pluridisciplinaire », deux étoiles) a pour problème une équipe qui ne peut pas travailler de façon autonome parce qu'il lui manque des compétences. Quand elle dépend de personnes extérieures, elle ne maîtrise ni ses délais ni la qualité du résultat, et elle ne peut pas se sentir responsable de terminer.

Du côté des forces, un produit complexe demande des talents variés, que l'on trouve rarement dans une seule équipe. Les organisations regroupent volontiers les personnes par métier, ce qui rend chaque métier efficace chez lui et la coordination entre groupes coûteuse : on rédige des « contrats » entre services, avec formulaires de demande et délais de réponse, et le produit entier ralentit pendant que chaque service s'améliore. À l'inverse, ajouter à l'équipe une personne par compétence manquante la ferait trop grossir, et apprendre une compétence nouvelle prend du temps.

La solution est que chaque Scrum Team réunisse toutes les compétences nécessaires pour livrer un travail terminé au sens de sa Definition of Done. L'exigence porte sur l'équipe prise comme un tout, et elle ne demande pas que chaque membre sache tout faire. Pour constituer l'équipe, le pattern conseille de regarder les compétences, et plus encore l'adhésion à la Vision et l'habitude d'apprendre, parce que les besoins changeront.

Avec le temps, les membres se forment les uns les autres, ce qui permet à l'un de remplacer l'autre et à plusieurs de travailler ensemble sur un même élément (voir Le swarming). Quand une compétence manque malgré tout, le pattern s'en remet au bon sens : l'équipe demande de l'aide à une autre équipe ou sous-traite un lot. Si ce recours devient fréquent, il faut le traiter comme un obstacle et y remédier par la formation, la réorganisation ou le recrutement.

Ce que dit le Guide Scrum 2020

Le Guide de 2020 reprend l'essentiel de ces patterns en quelques phrases. La Scrum Team, unité fondamentale de Scrum, se compose d'un Scrum Master, d'un Product Owner et de Developers. Elle est pluridisciplinaire, c'est-à-dire que ses membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint, et elle est autogérée. Trois écarts avec le livre sont à connaître.

• La taille. Le Guide parle de dix personnes au plus pour toute la Scrum Team. Le livre vise plus petit : environ cinq personnes, et pas plus de sept développeurs environ.
• L'équipe dans l'équipe. Dans le livre, les développeurs forment une Development Team qui a sa propre identité au sein de la Scrum Team. Le Guide de 2020 a supprimé cette notion et écrit qu'il n'y a « pas d'équipe dans l'équipe ni de hiérarchies ».
• La croissance. Quand l'équipe devient trop grande, le Guide demande de la réorganiser en plusieurs Scrum Teams qui partagent le même Product Goal, le même Product Backlog et le même Product Owner. Le livre traite ce cas par les patterns Mitosis et Scrum of Scrums.

Limites et pièges

« Pluridisciplinaire » est souvent compris comme « chacun sait tout faire ». Le pattern ne dit pas cela : les spécialistes restent nécessaires, et la formation croisée prend du temps, pendant lequel l'équipe produit moins.

Le chiffre de cinq n'a rien de magique. Les études citées vont dans le même sens, mais plusieurs portent sur des tâches de laboratoire courtes, loin du travail d'une équipe pendant des mois.

L'organisation par fonctions livrées a un coût. Quand plusieurs équipes touchent aux mêmes parties du produit, la cohérence technique ne se maintient pas toute seule. C'est la raison d'être des groupes transversaux.

L'image de la petite entreprise dans l'entreprise se heurte à la réalité de beaucoup d'organisations, où le budget, le recrutement et le droit de mettre en service restent ailleurs. Le livre renvoie alors à d'autres patterns, dont Involve the Managers (voir Protéger le Sprint des interruptions).

Enfin, la loi de Conway est l'observation d'un praticien. Des travaux ultérieurs, comme ceux d'Alan MacCormack, John Rusnak et Carliss Baldwin (2012) sur des logiciels issus d'organisations différentes, vont dans son sens sans en faire une loi au sens scientifique. Aucune de ces études ne mesure l'efficacité de Scrum lui-même (voir Critiques et état des preuves).