Les trois principales plaintes que j'entends de la part de mes étudiants et que j'ai constatées dans les équipes que j'ai soutenues :
Dépendances (nous avons abordé ce sujet dans le premier épisode de la série)
Pression exercée par les parties prenantes pour qu'elles prennent en charge le travail sans tenir compte de leurs capacités
Exigences floues
Ces problèmes vous semblent-ils familiers ? Nous allons nous concentrer sur la pression exercée par les parties prenantes
Voyez si cela vous semble familier. Votre Product Owner partage à nouveau la Vision (parce qu'il devrait la partager continuellement) et partage ensuite l'Objectif du Produit. L'équipe est concentrée et prête à réfléchir à la manière de progresser vers la réalisation de l'objectif.
Les développeurs apportent les éléments du Backlog de produit qu'ils peuvent réaliser au cours du Sprint... se mettant au défi d'y aller à fond ! Nous avons un objectif de sprint derrière lequel nous pouvons nous rallier et voir le but derrière le travail que nous entreprenons. Tout est parfait. Nous partons avec un plan génial.
Le lendemain, notre Product Owner arrive avec une partie prenante qui a une "demande urgente". Ce que l'on attend de lui ? Apporter cet élément urgent ET continuer à atteindre notre objectif de sprint, en réalisant tous les PBI planifiés.
Comme la dernière fois, vérifions la réalité. Vous allez avoir des éléments urgents qui vont surgir. Nous connaissons les suspects habituels : problèmes de support de production, cybersécurité, juridique et conformité. Cela vous semble familier ? Toutefois, cela devrait être l'exception, et non la règle.
Les autres types de perturbations que nous observons sont les nouvelles idées, les modifications d'idées et d'autres changements non urgents. Si nous absorbons les changements en fonction des caprices de nos parties prenantes, nous mettons en péril notre objectif ou travaillons à un rythme insoutenable. Si nous ne tenons pas compte des idées et du retour d'information des parties prenantes, nous perdons également sur ce plan. Alors, que faire ?
Rendre les compromis explicites et transparents.
Lorsque cette demande urgente se présente, la première chose que je fais est de prendre du recul et de me demander : ce changement est-il si important que notre objectif de sprint actuel est fondamentalement obsolète ? Nous parlons ici de l'acquisition d'une entreprise, du retrait complet d'un client clé ou de changements réglementaires qui réduisent à néant l'ensemble de l'orientation du produit. C'est rare. Quatre-vingt-dix-neuf fois sur cent, la réponse est non - l'objectif du sprint conserve sa valeur.
Si l'objectif survit (ce qui est généralement le cas), je le transmets directement à l'équipe. Ce sont les personnes qui font le travail qui ont le premier mot à dire sur ce qui pourrait changer. Nous nous réunissons rapidement pendant cinq à dix minutes et examinons le plan sur lequel nous nous sommes engagés. Que pourrions-nous supprimer, reporter ou réduire tout en continuant à produire quelque chose de significatif pour atteindre l'objectif ?
Il ne s'agit pas de faire des heures supplémentaires, de travailler les week-ends ou de "pousser plus fort". Il ne s'agit pas de compromis, mais de recettes d'épuisement. Nous parlons ici d'impacts réels : abandonner un PBI de moindre priorité, réduire la portée d'une fonctionnalité ou reporter un projet agréable à réaliser pour que la valeur principale soit atteinte.
Une fois que l'équipe a fait émerger les options réalistes, le Product Owner en fait part aux parties prenantes. Nous l'exposons clairement : "Pour intégrer cette option, nous supprimons X ou réduisons Y. Voici ce que cela signifie pour l'objectif du sprint et la valeur que nous apportons. Le PO prend la décision finale - c'est sa responsabilité - mais la conversation est transparente. Tout le monde voit le coût. Pas d'hypothèses cachées.
Saisissez le changement directement dans le carnet de sprint pour qu'il soit visible par tout le monde. Mettez à jour les éléments, ajustez la portée et notez ce qui a été abandonné ou reporté. Ensuite, indiquez les raisons de l'échange et l'origine du changement. Un commentaire rapide suffit : "Ajout d'un élément de conformité urgent à la demande du service juridique ; report de l'IBP Z pour maintenir l'objectif". Ainsi, au fil du temps, vous pouvez repérer des schémas.
S'agit-il de la même partie prenante qui dépose des demandes au cours de chaque sprint ? Certains types d'éléments "urgents" l'emportent-ils toujours ? Reportons-nous systématiquement les mêmes types de travaux ? Ces informations transforment des décisions ponctuelles en données qui alimentent de meilleures conversations, des limites plus strictes et peut-être même une modification de la politique en cours de route.
Cette approche donne du sens au sprint, respecte les capacités de l'équipe et permet d'instaurer la confiance avec les parties prenantes. Ils commencent à comprendre que dire "oui" à tout signifie en réalité dire "non" à quelque chose d'autre, et qu'il vaut mieux le choisir ensemble.
La prochaine fois qu'une demande "urgente" vous parviendra, essayez donc ceci. Faites en sorte que les compromis soient d'abord visibles pour l'équipe, puis transparents pour la partie prenante. Voyez ce qui change. Vous pourriez être surpris de constater que plus de choses sont faites... les choses qui comptent vraiment.
Dans la troisième partie, nous nous attaquerons aux exigences floues, le troisième grand obstacle dont j'entends constamment parler. Si vous êtes prêt à vous débloquer sur l'un de ces points, n'hésitez pas à contacter Improving, contactez Improving. Nous avons aidé des équipes à mettre en œuvre ces changements.
