Scrum Master Academy – Règles de crise

Les règles de crise ne sont à utiliser qu’en situation exceptionnelle. Leur objectif est d’amener un effet choc et de ne pas traîner pour prendre les décisions qui s’imposent. En effet, en situation de crise, plus vous trainez pour prendre des mesures radicales, plus la situation devient irréversible. Ce sont bien souvent des situations où la confiance est entachée et la difficulté pour restaurer la confiance est proportionnelle à la durée de la crise. Parfois, même en ayant rétabli une situation compliquée, l’échec n’est pas évitable. Initialement, les règles de crise étaient numérotées de 40 à 45, mais avec le temps et quelques remarques pertinentes, j’ai transformé une règle principale en règle de crise car elle ne méritait pas une attention continue.

Règle n°17 : Transparence et pas indécence

En situation de crise, assurez vous que les informations transmises par l’équipe sont formulées d’une façon qui ne porte pas offense au mandat de vos parties-prenantes. Parcourez votre affichage visuel avec les yeux de votre ennemi (cf règle 22) et assurez-vous que la formulation n’apporte pas une ambiguité qui pourrait être interprétée en votre défaveur. L’idée n’est pas ici de réduire la transparence mais plutôt de vérifier la bonne formulation des informations qui émanent de l’équipe. Je me suis déjà personnellement fait épingler sur un postit du tableau d’obstacles qui mentionnait "Manque de maîtrise de la base de données". Quelques semaines après, à l’occasion d’une réunion de crise avec le DSI, j’essuyais la réflexion que mon équipe ne maîtrisait pas la base de données et que c’était affiché ostensiblement. En réalité l’obstacle était le suivant: la base de données manquait de documentation et les nouveaux arrivants dans l’équipe ne maîtrisaient pas encore suffisamment le modèle.

Règle n°40 : Les points de story sont une fourchette de jours/hommes et un % de certitude

Dans les situations conflictuelles il arrive que le story point ait une signification tellement obscure pour les néophytes qu’il contribue à maintenir un savant brouillard autour de la capacité de l’équipe. Ca c’est si vous faites bien votre travail, si au contraire vous êtes tombé dans le travers de compter des points partiels pour les stories non terminées et que vous finissez systématiquement vos sprints à moins de 80% de prédictibilité, c’est vous qui entretenez un flou artistique sur la capacité de l’équipe. Si vous êtes amenés à traduire vos estimations en j/h, utilisez toujours des fourchettes d’estimation accompagnées d’un pourcentage de certitude.

Règle n°41 : Gère les pollueurs en démo

La revue de sprint est une étape important de collaboration entre développeurs et business. Elle peut avoir une effet extrèmement positif sur les équipes mais également se révéler très démotivantes si vous ne prenez pas un minimum de précautions. Dans les situations de crise, n’autorisez que les personnes qui ont participé au sprint planning à venir à la démo pour ne pas dégrader la confiance entre le PO et l’équipe.

Règle n°42 : Range ton désordre

L’agilité et Scrum laissent une certaine marge de manœuvre à l’expérimentation et la gestion des échecs. En revanche, en situation de crise il faut faire face à la réalité du business et parfois faire l’effort nécessaire pour revenir à une situation propre: absorbtion de dette technique, livraison de stories indispensables, nettoyage des bureaux, automatisation des tests et des déploiements, …. Une surcharge temporaire de travail ne remet pas en cause la notion de rythme soutenable.

Règle n°43 : Pas de sprint entier de refactoring

Les sprints entier de refactoring font passer un mauvais message auprès des donneurs d’ordre. En situation de crise, c’est l’aveu que vous avez perdu le contrôle de votre produit. Si votre dette technique est trop importante, essayez d’identifier au moins 2 sujets fonctionnels qui pourraient être adressés avec de la dette technique.

Règle n°44 : Si vous êtes en Scrum distribué, tout le monde sur le même site

Il n’y a pas à hésiter une seule seconde, les objections financières ne sont que des détails à régler. L’argent que l’organisation perd avec un projet à la dérive vaut le prix des voyages pour mettre tout le monde ensemble. Il n’y a pas de limite à cette règle, si ce n’est l’atmosphère terrestre car cela va vous couter un peu cher, mais l’offshore Lunaire n’a pas encore été inventé. Si la dépense est jugée trop chère pour rassembler une équipe distribuée c’est qu’il vaut mieux arrêter le projet.

Règle n°45 : A la rétrospective, 2 actions d’amélioration maximum

Les situations de crise ont cette caractéristique surprenante qu’elles génèrent un nombre de problèmes incalculables. Je fais du cynisme mal placé, ce n’est pas étonnant à vrai dire. La crise est exothermique, si vous ne trouvez pas un moyen de la contenir elle va devenir hors de contrôle, c’est un réacteur nucléaire en fusion dont vous n’imaginez pas les réactions en chaîne. Dans ces situations, on a une tendance naturelle à passer beaucoup de temps en rétrospective: il y a des ressentis forts qui se créent et ont besoin de s’exprimer, le nombre de problèmes à résoudre est énorme. Allonger le temps de ses rétrospectives ou bien prendre un grand nombre d’actions est exactement la bonne façon de prolonger la crise. Quand vous êtes dans le réacteur nucléaire vous avez plutôt intérêt à consacrer tout le temps possible à stopper la fusion plutôt qu’à réfléchir comment résoudre les problèmes de sécurité des centrales atomiques face au tsunami. Limitez la durée de la rétrospective à 1h et prenez 2 actions d’amélioration sur les problèmes les plus graves.

Prochainement :

  • Vos règles du jeu

Billets sur le même thème :

Laisser un commentaire