Garder les parties prenantes proches sans les laisser diriger l'équipe
Scrum vit ou meurt selon l'engagement des parties prenantes. Le cadre place délibérément un logiciel fonctionnel sous les yeux de ceux que le résultat intéresse, et leur demande de réagir. Mais un mode de défaillance s'est aggravé lorsque les équipes se sont dispersées dans des bureaux à domicile en 2021 : des parties prenantes, privées de la visibilité de couloir qu'elles avaient autrefois, se sont mises à interpeller directement les développeurs, à rouvrir des décisions réglées et à traiter chaque invitation au Daily Scrum comme une tribune libre. L'engagement est l'objectif. Diriger l'équipe ne l'est pas. Voici comment garder le premier sans glisser vers le second.
Savoir qui décide quoi
Scrum est clair là-dessus, et cette clarté est tout l'enjeu. Le Product Owner est la voix unique et imputable du Product Backlog et de son ordonnancement; les parties prenantes éclairent cette décision, elles ne l'écrasent pas. Les Développeurs décident comment transformer un Sprint Backlog en un Incrément utilisable. Quand une partie prenante tente de réordonner le travail en plein Sprint ou de dicter l'approche technique, la solution n'est pas un « non » plus fort — c'est d'acheminer l'avis vers la bonne personne au bon événement.
Utiliser les événements tels qu'ils sont conçus
Faire de la Revue de Sprint la scène principale. La Revue de Sprint existe précisément pour que les parties prenantes inspectent l'Incrément et adaptent le Product Backlog avec l'équipe. Traitez-la comme le canal principal de leur avis, et non comme un rapport d'avancement. Quand on sait qu'un vrai forum approche, on cesse de tendre des embuscades aux développeurs entre les Sprints.
Protéger le Daily Scrum. Le Daily Scrum sert aux Développeurs à planifier leur prochaine journée de travail vers l'Objectif de Sprint. Les parties prenantes peuvent l'observer dans bien des équipes, mais ce n'est pas à elles de l'animer. Tenez-le en quinze minutes et laissez la parole à ceux qui font le travail.
Canaliser les nouvelles demandes par le Product Owner. Tout « pourrais-tu juste ajouter… » va au Product Owner sous forme d'élément du Product Backlog, à ordonner par rapport au reste — et non glissé à un développeur comme une faveur en coulisse. Cette seule habitude prévient la majeure partie de la dérive de périmètre.
Respecter l'Objectif de Sprint comme un engagement. L'Objectif de Sprint donne à l'équipe une focalisation cohérente. En cours de Sprint, le périmètre peut être renégocié avec le Product Owner à mesure qu'on apprend, mais l'Objectif lui-même ne devrait pas être échangé à la légère. La stabilité sur la durée d'un Sprint est ce qui permet à une équipe d'avancer vite.
Des habitudes d'engagement adaptées aux équipes à distance
La distance supprime les signaux informels qui maintenaient l'alignement; rendez donc l'alignement explicite :
Publier l'Objectif de Sprint et un backlog visible pour que les parties prenantes trouvent elles-mêmes les réponses.
Accorder au Product Owner une fenêtre régulière et courte pour les questions des parties prenantes, distincte du temps de travail de l'équipe.
Apporter du logiciel réel et fonctionnel à la Revue — une démonstration de quelque chose d'utilisable vaut mieux qu'une présentation pour susciter un retour honnête.
Quand vous refusez une demande, dites quand elle sera réexaminée, et pas seulement qu'elle est hors périmètre.
Le but est une relation de confiance, pas un mur. Les parties prenantes qui se sentent écoutées à la Revue de Sprint et voient leur retour façonner le Sprint suivant ressentent rarement le besoin de microgérer entre-temps. Les événements ne sont pas de la bureaucratie; ce sont les soupapes de surpression qui permettent à une équipe de rester à la fois réactive et concentrée. Bien utilisés, ils transforment des parties prenantes anxieuses en partenaires engagés — c'est exactement ce que Scrum est conçu pour faire.
Si vos équipes de réalisation luttent contre l'agitation des parties prenantes et que vous voulez un agile qui reste discipliné sous pression, le conseil en réalisation de programmes et de projets de XNM peut vous aider à établir la cadence et les limites qui font vraiment fonctionner Scrum.