L'organisation

Les développeurs : une équipe autonome et auto-organisée

Dans une Scrum Team, les développeurs sont ceux qui fabriquent le produit, et ce sont eux qui décident comment s'y prendre. Trois patterns d'A Scrum Book décrivent cette petite équipe, son organisation interne et son indépendance vis-à-vis du reste de l'entreprise. Le Guide Scrum de 2020 a depuis changé le vocabulaire en gardant l'idée.

Le planning du lundi matin

Une compagnie d'autocars refait son site de réservation. Cinq personnes y travaillent : deux développeuses, un testeur, une conceptrice d'interfaces et un spécialiste des bases de données. Chaque lundi, le chef de projet, Marc, leur remet un tableau où chaque tâche de la semaine porte un nom.

Le mardi, Inès découvre que le service des horaires renvoie les dates dans un format imprévu. Sa tâche est bloquée. « Je préviens Marc », dit-elle. Marc est en réunion jusqu'au jeudi. En attendant, Inès entame une tâche de la semaine suivante, le testeur n'a rien à tester et, le vendredi, aucune fonction n'est terminée.

Trois mois plus tard, l'organisation a changé. Le lundi, la Product Owner (la personne qui ordonne la liste de ce qu'il faut construire) présente ce qu'elle attend des deux semaines à venir et pourquoi. Les cinq décident ensuite entre eux qui commence quoi. Quand le problème de dates surgit, Inès en parle le lendemain matin à la réunion quotidienne de l'équipe. Thomas, le testeur, lui répond : « J'ai déjà vu ce format sur l'ancien système. On s'y met à deux ce matin. » Personne n'a demandé de permission, et la fonction est terminée le jeudi.

Development Team : cinq personnes autour d'un produit

A Scrum Book (2019) décrit Scrum sous forme de patterns : chacun expose un problème récurrent, les forces qui s'opposent et une solution tirée de l'expérience. Le pattern Development Team (« équipe de développement ») porte deux étoiles, la note que les auteurs réservent aux solutions dont ils pensent qu'une équipe Scrum finira par avoir besoin.

Le problème. Beaucoup de réalisations dépassent ce qu'une personne seule peut accomplir, et c'est le travail d'équipe qui donne à la production sa plus grande force. Il reste à relier des individus pour qu'ils forment un tout sans y perdre leur identité.

Les forces. Un individu brillant peut créer un bon produit, mais il lui manque des regards extérieurs pour repérer ses erreurs, et il est difficile de grandir ensuite à partir d'une seule personne. À l'inverse, un groupe trop nombreux ne parvient à un accord qu'après de longues discussions, et chaque nouvel arrivant ralentit d'abord les autres : le livre donne comme ordre de grandeur, au titre d'une règle empirique de James Coplien, une perte d'environ un quart d'efficacité pendant six mois. Enfin, le travail avec le marché se joue sur des mois, quand la fabrication avance par semaines ou par jours. Confier les deux aux mêmes personnes les met sous tension, ce qui justifie de distinguer le Product Owner de l'équipe qui fabrique.

La solution. L'organisation forme une équipe stable d'environ cinq personnes, installées au même endroit, qui se rassemble autour du produit voulu par le Product Owner et en livre des versions successives. Cette équipe est autonome : ses membres ont choisi d'en faire partie, elle s'organise et se gère elle-même. Le Product Owner peut lui dire en substance que le produit est le sien et qu'il lui revient de le construire.

Le livre appelle tous les membres « développeurs », quel que soit leur métier, pour éviter les étiquettes. Chacun appartient à une seule équipe. L'équipe n'a pas de sous-groupes et ne fonctionne pas comme une chaîne où le travail passerait de poste en poste : il n'existe pas d'équipe de test séparée. Elle réunit les compétences nécessaires pour terminer son travail, ou la volonté de les acquérir. La tradition de Scrum parlait de sept personnes à deux près, mais les auteurs observent que les équipes efficaces sont plus petites et que les meilleures comptent parfois trois développeurs seulement.

Self-Organizing Team : l'équipe décide comment elle travaille

Le pattern Self-Organizing Team (« équipe auto-organisée », deux étoiles) porte sur l'intérieur de l'équipe : qui fait quoi, dans quel ordre et avec qui.

Le problème. Aucune façon d'organiser une équipe et son travail n'est bonne pour toutes les situations ni valable pour toujours.

Les forces. Tout travail à plusieurs demande de la coordination, faute de quoi le désordre s'installe. Pour simplifier, les organisations adoptent des structures standard et des « bonnes pratiques ». Celles-ci sont nées dans un contexte précis, qui n'est pas forcément celui de l'équipe, et elles vieillissent quand la situation change. Beaucoup de personnes trouvent confortable qu'on leur dise quoi faire, mais le livre rappelle que la motivation souffre sous une direction qui contrôle tout et que ceux qui font le travail sont les mieux placés pour l'améliorer. Enfin, si chacun reste dans sa spécialité, des tâches attendent pendant que d'autres personnes sont disponibles.

La solution. Les développeurs s'organisent eux-mêmes pour terminer leur travail, et ils sont seuls responsables de la manière dont ils le font. Ils conduisent leur réunion quotidienne, décident qui travaille sur quoi et dans quel ordre, choisissent de se mettre à deux ou à plusieurs sur un même sujet et tirent parti des compétences de chacun.

Les auteurs préviennent que cette auto-organisation demande de la maturité et de la discipline. Le Product Owner et le Scrum Master (la personne qui aide l'équipe à bien pratiquer Scrum) sont tentés d'intervenir quand l'équipe hésite. Or le Scrum Master n'attribue jamais de tâches et ne dit jamais aux développeurs comment travailler. Un autre danger apparaît quand le chef disparaît : un membre de l'équipe prend sa place et impose sa volonté par son charisme, par l'intimidation ou en monopolisant la parole. Le Scrum Master aide alors l'équipe à voir ce qui se passe et à y remédier.

Autonomous Team : l'équipe décide sans contrôle extérieur

Le pattern Autonomous Team (« équipe autonome », deux étoiles) concerne la frontière entre l'équipe et le reste de l'organisation. Le livre lui donne aussi le nom de Self-Managing Team (« équipe autogérée »).

Le problème. En matière de règles et de procédures, une taille unique ne convient pas à tous. Chaque équipe a ses personnes et sa dynamique, et celle qui porte une responsabilité avec les compétences voulues sait mieux que quiconque comment s'y prendre.

Les forces. Les parties prenantes ont un intérêt dans le succès du produit et se sentent plus en sécurité si elles peuvent diriger le détail du travail, qu'elles connaissent pourtant mal. La structure qui entoure l'équipe veut lui imposer des objectifs ou des « bonnes pratiques » communes à toutes les équipes. Chaque intervention envoie à l'équipe le message qu'on ne lui fait pas confiance et installe une opposition entre « eux » et « nous ». Le livre ajoute que les décisions prises sur place sont plus efficaces que celles imposées du dehors.

La solution. La Scrum Team (l'équipe complète, avec son Product Owner et son Scrum Master) prend ses décisions sans contrôle extérieur, tout en restant attentive à ce qui l'entoure. De la même façon, les développeurs se gouvernent eux-mêmes pendant la partie du Sprint consacrée à la production. Le Sprint est la période de travail de durée fixe, d'un mois au plus, qui rythme Scrum.

Cette autonomie a des bornes. Si l'organisation a choisi Scrum, l'équipe suit Scrum, et elle agit dans le cadre des valeurs et des buts de l'organisation. L'autonomie va de pair avec l'obligation de rendre des comptes, puisque l'équipe a l'autorité et la responsabilité d'atteindre l'objectif du Sprint. Elle garde son travail visible et le soumet à des regards extérieurs lors de la Sprint Review, la réunion de fin de Sprint où le résultat est examiné avec les parties prenantes.

Le livre cite à ce sujet une étude d'Ethan Bernstein (2012) : des ouvriers craignaient qu'être vus en train de corriger un défaut n'attire l'intervention de l'encadrement, et la qualité s'améliorait quand ils travaillaient hors du regard. Les auteurs invitent donc à réfléchir avant d'adopter un outil qui permet à la direction de suivre chaque défaut.

Du livre au Guide Scrum 2020

Le livre, paru en 2019, cite l'édition 2016 du Guide Scrum de Ken Schwaber et Jeff Sutherland. L'édition 2020 a modifié plusieurs points qui touchent cet article.

• Le terme « Development Team » a disparu au profit de « Developers ». Le Guide a voulu supprimer l'idée d'une équipe dans l'équipe : il n'y a qu'une Scrum Team, sans sous-équipes ni hiérarchie.
• Les développeurs y sont redevables (ils doivent en rendre compte) de quatre choses : établir le plan du Sprint, appelé Sprint Backlog, assurer la qualité en respectant la Definition of Done (la définition commune d'un travail terminé), adapter leur plan chaque jour en direction de l'objectif du Sprint et se tenir mutuellement responsables en professionnels.
• L'adjectif « self-organizing » des éditions précédentes est devenu « self-managing » (autogérée) : la Scrum Team décide en interne qui fait quoi, quand et comment. Le Guide applique ce mot à l'équipe entière, Product Owner compris, alors que le livre répartit l'idée entre deux patterns.
• Pour la taille, le Guide indique que la Scrum Team compte en général dix personnes au plus, Product Owner et Scrum Master inclus. Il ne dit rien du lieu de travail ni de la façon dont les membres rejoignent l'équipe.
• Sur le fond, l'accord est complet : le Guide précise que la manière de transformer un élément de la liste en résultat utilisable relève des seuls développeurs et que personne d'autre ne la leur dicte.

Limites et pièges

Le premier piège est l'autonomie proclamée et non accordée. L'organisation annonce que les équipes s'organisent seules, mais un responsable continue de distribuer les tâches, parfois par l'intermédiaire du Scrum Master. Les développeurs le comprennent vite et attendent les consignes, comme Inès attendait Marc.

Le piège inverse est l'abandon. Dire à une équipe qu'elle est auto-organisée sans lui donner de but clair ni de Product Owner disponible la laisse livrée à elle-même. Les trois patterns supposent un cadre : une Vision, une liste ordonnée, des règles connues et quelqu'un qui protège l'équipe des interférences. Une équipe débutante a souvent besoin d'être accompagnée de près, et le livre recommande dans ce cas l'aide d'un coach plutôt que le retour d'un chef.

Ce mode de travail ne convient pas à tout le monde et ne supprime pas les contraintes extérieures. Dans un hôpital ou une école, la réglementation ne se négocie pas, et l'autonomie porte sur la manière d'atteindre le but. Une équipe très autonome peut aussi devenir aveugle à ses propres faiblesses, ce que le livre traite avec le pattern Pop the Happy Bubble, présenté dans l'article sur le Scrum Master.

Quant aux preuves, le livre cite quelques travaux de psychologie du travail sur les effets de l'autonomie. Il reprend aussi des écarts de productivité spectaculaires entre équipes, jusqu'à 2 000 pour 1, tirés d'un ouvrage de Jeff Sutherland qui s'appuie lui-même sur des données de Lawrence Putnam et Ware Myers. De tels chiffres sont à prendre avec prudence, et l'article Critiques et état des preuves y revient.