L'organisation

Protéger le Sprint des interruptions

Une équipe qui rend service à beaucoup de monde est interrompue par tout le monde. Cinq patterns d'A Scrum Book organisent la réponse : un budget d'interruptions fixé à l'avance, une procédure d'urgence quand le Sprint dérape, un téléphone réservé aux cas critiques, une vélocité stabilisée avant toute amélioration et une place définie pour les managers.

« Juste une petite affiche »

Le service communication d'une mairie compte quatre personnes : une graphiste, une rédactrice, un webmestre et un photographe. Il travaille en Sprints, des périodes de durée fixe qui durent ici deux semaines, et chaque Sprint a un objectif. Celui du moment est d'envoyer le magazine municipal de mars à l'imprimeur.

Le lundi, l'adjoint à la culture passe la tête dans le bureau : « J'ai juste besoin d'une affiche pour le concert de samedi. C'est l'affaire d'une heure. » Le mardi, le directeur des services demande un diaporama pour le conseil municipal du jeudi. Le mercredi, la piscine ferme pour une panne, et il faut des panneaux et une annonce en ligne. Chaque demande, prise seule, est raisonnable. Le vendredi de la seconde semaine, le magazine n'est pas prêt.

Illegitimus Non Interruptus : un budget pour l'imprévu

A Scrum Book (2019) décrit Scrum sous forme de patterns : chacun expose un problème récurrent, les forces en jeu et une solution tirée de l'expérience. Le pattern Illegitimus Non Interruptus, dont le nom en latin de fantaisie évoque les interruptions illégitimes, porte une étoile : les auteurs y voient le cœur d'une bonne solution, sans exclure qu'il en existe d'autres.

Le problème. Les changements de priorité et les incidents interrompent le travail pendant le Sprint. Répétées, ces interruptions font échouer les Sprints les uns après les autres et rendent les dates de livraison intenables.

Les forces. L'équipe est une ressource commune au service de nombreuses parties prenantes. Le livre y voit un cas de « tragédie des communs », décrite par l'écologue Garrett Hardin en 1968 : chacun puise dans la ressource selon son intérêt immédiat, et tous finissent par l'épuiser. Un Product Owner trop faible (le Product Owner est la personne qui ordonne la liste de ce qu'il faut construire) laisse les priorités concurrentes arriver jusqu'à l'équipe. On ne peut pourtant pas supprimer toutes les interruptions, car le livre tient à ce que l'équipe corrige elle-même les défauts de son produit.

La solution. L'équipe réserve explicitement du temps pour les interruptions et n'accepte pas plus de travail imprévu que ce budget. Trois règles suffisent.

• L'équipe dimensionne un tampon d'après son historique. Dans l'exemple du livre, une équipe dont la vélocité moyenne est de 60 points (la vélocité est la quantité de travail terminée par Sprint, estimée en points, une unité relative propre à l'équipe) et dont un tiers du travail arrive sans prévenir réserve 20 points.
• Toute demande qui n'est pas triviale passe par le Product Owner. Il en écarte certaines, en reporte beaucoup à un Sprint ultérieur et place les rares demandes critiques dans le tampon.
• Si le tampon déborde, le Sprint est arrêté d'office et replanifié, et le Product Owner prévient la direction que les dates vont glisser.

Ces règles demandent l'accord préalable de la direction. Selon les auteurs, elles poussent les demandeurs à se discipliner, parce que personne ne veut être celui qui fait échouer le Sprint. Le tampon se remplit alors rarement, et l'équipe peut le réduire au fil des Sprints.

Le Guide Scrum de 2020 ne prévoit pas de tampon. Il indique qu'un Sprint peut être annulé si son objectif devient obsolète et que seul le Product Owner en a l'autorité. L'arrêt d'office du pattern peut se lire comme une décision que le Product Owner annonce à l'avance, mais cette règle appartient au livre et non au Guide.

Emergency Procedure : quand le Sprint dérape

Le pattern Emergency Procedure (« procédure d'urgence »), aussi appelé Stop the Line, ne porte pas d'étoile : c'est pour les auteurs une bonne solution parmi d'autres.

Le problème. Des difficultés surgissent en cours de Sprint, qu'il s'agisse d'exigences nouvelles, d'un obstacle technique ou de la perte d'une personne clé. À mi-parcours, le graphique du travail restant montre que l'objectif du Sprint ne sera pas atteint au rythme actuel. Attendre la fin pour le constater fait perdre le Sprint entier.

Les forces. Réagir vite suppose de rendre les problèmes visibles tôt. Or les équipes, surtout les jeunes, n'aiment pas arrêter le travail et s'exposer à la critique. Le livre rappelle l'histoire de l'usine NUMMI, que Toyota exploitait avec General Motors en Californie : les ouvriers n'osaient pas tirer la corde qui signale un problème et peut arrêter la chaîne, et les dirigeants japonais l'ont tirée eux-mêmes pour montrer que cette réticence était le principal obstacle. L'article du corpus Lean sur l'andon décrit ce dispositif.

La solution. Comme un pilote face à une panne, l'équipe applique sans tarder une procédure préparée à l'avance. Le Scrum Master (la personne qui aide l'équipe à bien pratiquer Scrum) veille à ce qu'elle soit déclenchée, de préférence avant la moitié du Sprint. Les étapes se suivent, et l'équipe n'en fait pas plus que nécessaire :

• changer la manière de faire le travail ;
• obtenir de l'aide, en général en confiant une partie du travail à quelqu'un d'autre ;
• réduire le périmètre ;
• arrêter le Sprint et replanifier ;
• informer la direction des conséquences sur les dates.

Seul le Product Owner décide d'arrêter un Sprint, comme dans le Guide Scrum. Le Guide admet aussi que le périmètre soit clarifié et renégocié avec le Product Owner à mesure que l'équipe apprend, ce qui correspond à la troisième étape. L'arrêt y reste réservé au cas où l'objectif est devenu obsolète, alors que le livre en fait aussi un signal adressé à l'organisation.

Les auteurs réservent ce pattern aux équipes disciplinées. Une équipe qui y recourt plus d'une fois tous les quatre Sprints sans progresser a un problème plus profond. Ils conseillent aux équipes débutantes d'aller au bout du Sprint, puis d'en analyser l'échec lors de la rétrospective, la réunion où l'équipe examine sa façon de travailler.

Small Red Phone : joindre à coup sûr les personnes clés

Une équipe protégée peut aussi se trouver bloquée faute de réponse. Le pattern Small Red Phone (« petit téléphone rouge », sans étoile) traite ce cas.

Le problème. Scrum repose sur des retours rapides. Si le Product Owner ou le Scrum Master sont injoignables au moment où l'équipe découvre, par exemple, qu'elle a mal compris un élément, quelques heures d'attente peuvent la faire dérailler.

Les forces. Ces personnes travaillent souvent ailleurs, à bon droit, pour le compte de l'équipe. Donner leur numéro habituel les exposerait à des dérangements continuels.

La solution. Chaque personne clé reçoit un téléphone rouge, avec un numéro propre connu de l'équipe et réservé aux situations critiques. Une petite contrepartie humoristique dissuade d'en abuser, et chaque appel est rediscuté à la rétrospective. Aujourd'hui, un numéro ou un canal de messagerie réservé joue le même rôle.

Le livre limite lui-même la portée du pattern. Il s'agit d'une communication par interruption, moins bonne que le lieu de rencontre décrit dans l'article Des équipes stables et réunies. Si le téléphone sonne souvent, il compense une organisation défaillante, et il ne remplacera pas durablement la proximité.

Kaizen Pulse : stabiliser avant d'améliorer

Les interruptions font varier la vélocité d'un Sprint à l'autre. Or le tampon se calcule sur l'historique, et une amélioration ne se juge que par rapport à une référence. Le pattern Kaizen Pulse (« pouls du kaizen », une étoile) porte sur ce point. Kaizen désigne en japonais l'amélioration continue.

Le problème. Il est difficile de montrer une amélioration d'un Sprint à l'autre, parce qu'une référence fiable demande du temps et que toute mesure isolée subit les aléas du processus.

Les forces. Si la vélocité varie beaucoup, on ne peut pas savoir si un changement a aidé ou nui. Si plusieurs changements sont introduits ensemble, on ne sait pas lequel a compté. Les personnes ont en outre besoin de temps pour absorber un changement et en faire une habitude.

La solution. L'équipe alterne des périodes de vélocité maîtrisée et des poussées d'amélioration. Elle établit d'abord une référence stable, avec pour repère des variations contenues dans une marge de 20 %. Elle introduit ensuite une seule amélioration, la pratique jusqu'à ce qu'elle devienne une routine, et en juge l'effet sur plusieurs Sprints avant de la conserver ou de l'abandonner.

Le livre cite l'ingérence de la direction dans la production parmi les causes les plus fréquentes de variation. Protéger le Sprint fait donc partie des premières améliorations à mener. L'article sur la rétrospective et l'amélioration continue reprend ce pattern en détail.

Involve the Managers : une place pour les managers

Beaucoup d'interruptions viennent de managers qui veulent aider. Le pattern Involve the Managers (« impliquer les managers », une étoile) leur cherche une place utile.

Le problème. Scrum ne prévoit pas de managers : les développeurs se gèrent eux-mêmes et le Product Owner décide du produit. Les managers en place cherchent leur rôle, et certains s'immiscent dans le travail de l'équipe, jusqu'à dire aux développeurs comment faire.

Les forces. Les managers détiennent des pouvoirs que les rôles de Scrum n'ont pas : engager juridiquement l'entreprise, la réorganiser ou gérer un contrat qui concerne plusieurs produits. Les équipes pratiquent l'amélioration par petits pas, mais une organisation a parfois besoin d'un changement radical (kaikaku), par exemple arrêter un produit, qu'un Product Owner ne décidera pas contre son propre produit.

La solution. L'organisation conserve une fonction de management réduite, capable de lancer et d'assumer des changements radicaux, et de traiter les obstacles trop lourds pour le Scrum Master ou le Product Owner. Les équipes se gèrent elles-mêmes. Les managers les rencontrent à un rendez-vous régulier, le MetaScrum, en général à travers les Product Owners, et ne participent à aucune autre réunion de Scrum. L'article Passer à l'échelle décrit ce rendez-vous.

Les managers disposent ainsi d'un canal légitime pour peser sur les priorités, ce qui retire sa raison d'être à l'interruption en cours de Sprint. Le Guide Scrum ne mentionne pas les managers et demande que toute l'organisation respecte les décisions du Product Owner.

Limites et pièges

Le tampon peut devenir une seconde liste par laquelle tout finit par passer, surtout si sa taille n'est jamais revue. Il ne fonctionne que si la menace d'arrêter le Sprint est crédible, donc si la direction a réellement accepté la règle. Le livre estime lui-même que dépasser le tampon fait perdre au moins la moitié de la vélocité : l'arrêt coûte cher et ne doit pas devenir une habitude.

Le mot « illégitime » peut tromper. Une interruption est parfois ce que l'équipe a de plus utile à faire, par exemple quand un défaut grave touche les utilisateurs. Le tri appartient au Product Owner, et l'article sur la Definition of Done et la qualité explique pourquoi les défauts se corrigent sans attendre.

Ces patterns reposent sur l'expérience de leurs auteurs et sur des récits d'entreprise. Le livre ne s'appuie sur aucune mesure indépendante pour dire quelle taille de tampon convient ni à quelle fréquence la procédure d'urgence est profitable. L'article Critiques et état des preuves revient sur le statut de ces recommandations.