Bonjour les agilistes ! Cet article est une traduction enrichie d’un article de Willem-Jan Ageling auquel j’ajoute quelques ressources qui pour moi, font sens.
Je vous invite aussi à (re) découvrir la série d’article connexe de Claude : Déconstruction du guide Scrum 2020.
La semaine dernière, j’ai terminé ma série “Scrum résiste-t-il à une analyse critique ?“. Je voulais évaluer chaque ligne et chaque mot du Guide Scrum 2020 pour voir s’ils ont du sens pour moi. Globalement, je peux confirmer que le Guide Scrum est solide et cohérent. Je l’aime bien.
Cependant, il y a des passages dans le Guide Scrum qui m’ont fait froncer les sourcils. Des choses qui n’avaient pas de sens pour moi ou qui n’étaient pas en ligne avec la prémisse de Scrum. Voici 8 des choses les plus problématiques pour moi dans le Guide Scrum.
Les valeurs Scrum
Les valeurs : l’engagement, le focus , l’ouverture, le respect et le courage sont clés dans Scrum. Ils donnent vie aux piliers de l’empirisme (transparence, inspection, adaptation). Tout dans Scrum implique l’empirisme.
Mais à quel point est-il réaliste pour l’équipe et les parties prenantes de respecter les valeurs Scrum ? Dès que l’équipe Scrum doit faire face (pour ne citer que quelques exemples) au micro-management, aux silos, à l’évitement des conflits ou à la politique : que reste-t-il des valeurs Scrum ? Et dans une plus large mesure, que reste-t-il de Scrum ?
Pas de hiérarchies
Les équipes Scrum ne devraient pas avoir de hiérarchies. Mais à quel point cela est-il réaliste ? Parmi les trois responsabilités de Scrum (Développeurs, Product Owner, Scrum Master), deux ont un aspect de leadership.
Le Scrum Master est “un véritable leader” de l’équipe Scrum, responsable de l’efficacité de l’équipe. Le Product Owner décide de l’ordre du Product Backlog. Je peux voir comment ces responsabilités peuvent entrer en conflit avec l’idée de “pas de hiérarchies”. Cela peut entraîner des problèmes dans les équipes Scrum.
Je ne dis pas qu’un rôle de leadership mène automatiquement à des hiérarchies. Mais avec un Scrum Master responsable de l’efficacité et un Product Owner pour maximiser la valeur, il est facile pour moi de voir comment cela peut conduire à des hiérarchies.
Le Product Owner est uniquement responsable du travail lié à Scrum
Un Product Owner est responsable du travail effectué par l’équipe Scrum. À première vue, cela semble logique… comme nous parlons de Scrum. Mais lorsque une grande partie ou même la majorité du travail sur un produit est effectué par d’autres que l’équipe Scrum, que reste-t-il du Product Owner ? Le nom n’est-il pas très trompeur dans ces cas ?
Un produit est généralement plus que la fonctionnalité de base seule. Pensez à des aspects tels que le support produit, les ventes ou les systèmes de support externes. Dans presque toutes les situations que j’ai observées, ces responsabilités étaient en dehors des équipes Scrum. Cela signifie que des parties importantes de ce qui fait le produit ne font pas partie des responsabilités du Product Owner. Comment le Product Owner peut-il maximiser la valeur du produit sans avoir une compréhension globale du produit ?
Le Product Owner est une seule personne
Pourquoi un Product Owner devrait-il toujours être une seule personne ? Quel est le problème à avoir une équipe de Product Owner ou une équipe Scrum qui a absorbé les responsabilités du Product Owner et n’a donc personne pour assumer ce rôle ?
Je comprends que le Product Owner a été introduit pour avoir “une seule paire de cordes vocales” (Alistair Cockburn). La raison était de protéger l’équipe Scrum de la réception de différentes demandes de différentes personnes. Je peux confirmer que c’est non seulement ennuyeux et déroutant, mais peut-être même nuisible pour la santé des personnes de l’équipe.
Mais je pense qu’il y a de meilleures façons de résoudre le problème d’une équipe qui est bousculée. Pour commencer, respectons l’autonomie de l’équipe Scrum pour déterminer ce qu’elle va faire, comment elle va le faire et quand. Reconnaissons que l’équipe Scrum est autogérée. Avec cela en place, la règle de la personne unique n’est plus nécessaire. Tant que l’équipe Scrum indique clairement comment elle assume la responsabilité du Product Owner.
Le Scrum Master est une seule personne
Comme le Product Owner, le Guide Scrum stipule qu’il ne devrait y avoir qu’un seul Scrum Master. Je ne vois pas pourquoi cela devrait toujours être le cas. Il y a tellement à faire pour un Scrum Master et cela nécessite tellement de compétences, il est difficile et peut-être même utopique de trouver tout cela en une seule personne.
Je ne vois pas pourquoi Scrum doit être aussi prescriptif. Ils ne peuvent pas me convaincre qu’une équipe Scrum qui fait tout selon la lettre et l’intention de Scrum mais qui a deux Scrum Masters ne fait pas de Scrum.
Le rôle du Product Owner et du Scrum Master lors du Daily Scrum
Le Daily Scrum est pour les Développeurs pour replanifier leurs efforts afin d’atteindre l’objectif du Sprint. La section donne l’impression que le Product Owner et le Scrum Master n’ont pas de rôle à jouer. Je suis d’accord qu’ils ne devraient pas diriger la discussion et que les Développeurs possèdent le Sprint Backlog.
Mais un Scrum Master peut aider les Développeurs à rester dans les 15 minutes et à assurer un suivi positif et quotidien. Je pense que cela mérite une certaine attention. Il en va de même pour le Product Owner, qui peut aider à discuter et -si nécessaire- à ajuster la portée du Sprint Backlog.
Pourquoi le Guide Scrum n’exprime-t-il pas le rôle potentiel du Product Owner et du Scrum Master dans le Daily Scrum ? Comme il est maintenant, la section Daily Scrum du Guide Scrum est quelque peu déroutante et même apparemment contradictoire.
Présenter le résultat du Sprint lors de la Revue de Sprint
Les précédents Guides Scrum indiquaient que l’équipe Scrum et les parties prenantes inspecteraient l’Incrément lors de la Revue de Sprint. Maintenant, c’est changé en “résultat du Sprint” et “résultats de leur travail”. Je pense que c’est un changement pour le pire.
Je comprends que les rédacteurs voulaient éviter la confusion lorsqu’une équipe peut terminer et libérer plusieurs incréments dans un Sprint. Mais les incréments sont “additifs à tous les incréments précédents” (Guide Scrum 2020). Ainsi, l’équipe Scrum peut toujours présenter un incrément lors de la Revue de Sprint : la somme de tous les incréments d’avant le Sprint et tous les incréments (Fait) du Sprint. Ils pourraient appeler cela quelque chose comme “la somme de tous les incréments”.
Maintenant, le Guide Scrum ne fait que créer de la confusion en parlant du résultat du Sprint ou des résultats de leur travail. Cela pose la question : une présentation Powerpoint est-elle un résultat du Sprint ? Je dirais non à cela.
Scrum a toujours consisté à inspecter l’incrément lors de la Revue de Sprint. Je ne comprends pas pourquoi cette ligne a disparu. À d’autres endroits du Guide Scrum, vous pouvez encore trouver cette information, mais pourquoi manque-t-elle dans la section Revue de Sprint ? Cela me laisse perplexe. Et, à mon humble avis, je pense que cela nuit à la compréhension des gens de ce qu’une Revue de Sprint devrait être.
Les développeurs négocient avec le Product Owner pour modifier le Backlog de Sprint
Les développeurs sont propriétaires du Backlog de Sprint. Dans la section Planification de Sprint, nous pouvons lire que les développeurs sélectionnent les éléments du Backlog de produit qui les mèneront à l’Objectif du Sprint. Ils déterminent également comment le travail sera effectué. C’est un changement par rapport au précédent Guide Scrum, où les développeurs se contentaient de déterminer combien d’éléments ils sélectionneraient du Backlog de Sprint. J’ai été à la fois surpris et heureux des changements.
Alors, pourquoi est-ce différent pendant le Sprint ? Lorsque les développeurs apprennent de nouvelles choses pendant le Sprint, ce qui les oblige à changer le Backlog de Sprint (pour atteindre encore l’Objectif du Sprint), ils doivent d’abord négocier avec le Product Owner. Tout d’un coup, les développeurs ne sont plus propriétaires du Backlog de Sprint ?
Je pense que les développeurs ne devraient pas négocier avec le Product Owner. Ils devraient plutôt le consulter ou l’informer. De cette façon, ils incluent toujours le Product Owner dans l’équation tout en étant propriétaires du Backlog de Sprint.
Note de fin
J’aime beaucoup de choses dans le Guide Scrum, mais je lutte aussi avec certaines parties. Êtes-vous d’accord ? Pensez-vous que Scrum est bon tel qu’il est ? Avez-vous d’autres problèmes ? Je suis certainement intéressé à apprendre de vous !.. alors n’hésitez pas à laisser un commentaire !
Bonjour,
J’ai apprécié votre analyse sur ce qui a changé par rapport au guide scrum.
Cependant, il y a des points sur lesquels, il est important d’en tenir compte c’est la notion de valeur, à qui appartient le produit et la vision client final, Je me permets de vous faire ce retour :
– Le backlog produit est le cadrage par le product Owner, des besoins client (partiesprenantes) avec comme objectifs metier, business et interdependances avec des valeurs additionnelles pour créer le produit final. Le Product Owner représente les parties prenantes or les développeurs ne peuvent pas quant leur rôle représenter les métiers (marketing, commerciaux, communication…), leur rôle comme dans une équipe de développement est de développer ces produits conformément à la priorité des besoins des valeurs métiers …, bien sûr ils doivent identifier, l’impact technique et la faisabilité des solutions. Ils sont autonomes pour faire leurs tâches, ils ne sont pas propriétaires du ou des des produits qu’ils developpent, mais ils developpent conformément aux priorités des clients (parties prenantes) et du bisiness.
MD
Bonjour,
D’ordre général, j’ai apprécié votre réflexion sur le Guide Scrum.
Mais, j’aimerais revenir sur les points ou vous parlez des « Product Owner » et « Scrum Masters ». Pour ma part, je suis d’accord avec les auteurs du Guide Scrum de mettre cette responsabilité sur une personne par rôle.
Mais, dans le même esprit que vous apportez, avec un angle légèrement différent. Je suis d’accord que c’est des rôles complexes et qui sont difficiles à occuper par une seule personne. Mais, au lieu de mettre plusieurs personnes qui répondent à l’équipe, avec possiblement tous les problèmes de communication que cela pourrait introduire.
La variante que je vous proposerais. C’est de laisser comme dit le guide Scrum, la responsabilité à une seule personne. Mais, lui apporter un réseau, voir une équipe pour l’aider dans cette charge. La personne à charge est responsable d’emmener l’équipe dans la bonne direction et d’être le porteur de l’information.
En tant que Coach Agile, Scrum Master, j’aimerais bien avoir réponse à toutes les questions de mon équipe, d’identifier tous les problèmes avant qu’ils soient soulevés. Mais, c’est impossible, même avec une équipe Scrum mature. Avoir d’autres yeux, d’autres cerveaux qui « inspecte » le travail, l’équipe, le produit, etc., afin d’apporter encore plus de transparence à ces rôles si importants et biens d’améliorer cette adaptation vers de meilleurs résultats, c’est super.
Parfois, mon miroir n’a pas toujours la réponse que je cherche. Souvent, poser une question à une personne, c’est de trouver des pistes de réponses sans même que l’autre personne a répondu. Donc, oui, le Scrum Master et le Procduct Owner doivent être incarnés par une seule personne. Mais, ces deux leaders peuvent avoir des équipes pour les supporter dans ce travail si essentiel. Les trois piliers de Scrum « Transparence, Inspection et l’Adaptation » prendrait encore plus de force, si ces deux rôles « Scrum Masters » et « Product Owner » était appuyer par une équipe, dans une approche plus globale dans leurs Rôle sans individuellement, perde leur rôle de leader.
P.S. Vous, les « Amigos » de Scrum Life, vous avez donné réponses à mes questions, sans même que je vous les aie posées !
Merci de partager vos réflexions, de nous apporter à réfléchir encore plus et surtout continuez.
Bruno Larouche