Michaël a lancé la bataille avec un billet dans lequel il met en avant les biais de cette pratique. Mais Jean-Pierre n’est pas d’accord. Alors, est-ce une question de contexte ?
Est-ce une différence de compréhension du concept de vélocité ?
Est-ce une question de DOD ?
Et si c’était juste une question d’adhérer aux valeurs agiles, je veux dire pour de vrai..?
Comment on gère les différences de niveau entre développeurs ?
Quel est le rôle du SCRUM Master ou du Tech Lead ?
Viens écouter les points de vue qui s’affrontent dans cet épisode spécial Battle #1 !
La vision de Jean-Pierre : https://www.youtube.com/watch?v=NZxcqei5qIE
Le point de vue de Michaël : https://medium.com/wealcomecompany/le-poker-planning-une-bonne-chose-hold-on-b35531a61e7b
Bonjour,
Je suis sincèrement désolé pour la longueur de mon commentaire, mais j’ai l’impression qu’il y a beaucoup de confusions introduites dans ce podcast…
Pour commencer, j’aimerais rappeler qu’XP – dont fait partie le Planning Poker – et Scrum sont deux frameworks indépendants, qu’il est possible d’utiliser l’un sans l’autre. Si j’ai bien saisi les propos de Michaël Azerhad, il s’agit de remettre en cause le Planning Poker dans un contexte Scrum, et c’est finalement autre chose que de bannir purement et simplement le Planning Poker.
Introduire le Planning Poker comme le « sacro-saint » de Scrum dès le démarrage du podcast est donc vraiment dommage, car en réalité il s’agit vraiment de concepts très différents et il est tout à fait possible d’utiliser Scrum (ET XP d’ailleurs), sans Planning Poker.
Ensuite, il faut à mon sens faire très attention à décorréler les contextes projet des frameworks. La plupart des arguments avancés par Mickaël sont, me semble-t-il, conditionnés par une culture d’entreprise, des valeurs, ou une compréhension du framework qui sont incompatibles avec la mise en place de Scrum. C’est un peu la conclusion du podcast, mais il serait injuste de faire une généralité en bannissant absolument une pratique Agile simplement parce qu’elle induit des dérives dans une organisation qui n’est pas Agile.
J’ai un avis assez tranché sur la question, mais on devrait (d’après moi donc), transformer les valeurs de l’organisation avant de se lancer tête baissé dans l’application d’un framework. Tenter d’utiliser un framework Agile dans une entreprise dont les valeurs ne sont pas compatibles avec l’Agilité est dangereux (pour le projet comme pour les personnes) et même souvent contre-productif (échec des projets, développement de l’agilo-scepticisme des développeurs et des managers, etc.).
Enfin, j’aimerais essayer de vous convaincre de certaines notions qui me semblent cruciales pour bien appréhender Scrum.
1/ Le sprint planning se passe en 2 parties: que va-t-on réaliser dans le prochain sprint (le « QUOI ») et le plan pour y arriver (le « COMMENT »), chacune pouvant représenter une demi-journée et traitant de 2 sujets différents. L’estimation (donc le Planning Poker) tient place dans la première partie (le « QUOI »): on essaie de remplir le sprint avec suffisamment d’US pour occuper l’équipe durant l’itération à venir, en se basant sur la célérité de l’équipe. Les éléments suivant en découlent:
a) On ne parle pas de tâches puisque les tâches sont le « COMMENT ». D’ailleurs, la notion de tâche n’existe pas dans Scrum, c’est un moyen de définir le « COMMENT » comme un autre. Dans le Scrum Guide, il est bien indiqué que l’équipe estime les « Product Backlog Items ». On estime donc les « Stories » et non les tâches (ni les features d’ailleurs, utilisé par abus de langage dans le podcast).
b) L’équipe s’engage sur un sprint goal (un périmètre défini par « on sera content si on arrive à… ») et pas sur une estimation. Contractualiser un nombre d’heures ou de points de complexité est une hérésie en Scrum, car c’est une manière détournée de contractualiser un périmètre figé, et il s’agit alors de cycle en v déguisé, plus d’un projet Agile. C’est également une méthode de micro-management incompatible avec les valeurs de l’Agilité, qui prônent la confiance et la responsabilisation de l’équipe (au sens large, on met autant la pression au PO qu’aux développeurs dans l’affaire, sinon).
e) Comme le souligne Jean-Pierre, le sprint planning se fait en présence exclusive de l’équipe Scrum, c’est à dire le PO, le SM et l’équipe de développement. Il n’y a pas de « manager » autorisé à cette réunion, du moins dans la mesure où l’indépendance et la pertinence de l’équipe en serait dégradée.
d) Si une story est estimée comme faisant l’objet de trop d’inconnues, elle doit être reportée. Une story qui ne correspond pas à la DoR, qui n’est pas « SMART »/ »INVEST »/6D/etc., ne doit pas faire être choisie pour le Sprint Backlog. Soyez fermes et ne vous engagez que ce sur quoi vous êtes en mesure de le faire, vous vous éviterez pas mal de soucis! 😉
e) Le chiffrage des US se fait justement de manière à ce que la diversité entre les membres de l’équipe de développement soit absorbée. Cette estimation permet également d’absorber les incertitudes (une sorte de « gestion des risques » en somme) et les besoins en formation, comme le souligne là encore Jean-Pierre.
2/ Scrum précise bien qu’il est nécessaire de réaliser une phase d’avant-projet. On ne démarre jamais un projet (Agile ou autre d’ailleurs) par la réunion de Kick-off, comme la situation qu’expose Michaël. Cela permet entre autres de découvrir le fonctionnel, construire une équipe pluridisciplinaire, définir le niveau de qualité attendu (la DoD ou autre), mettre en place l’intégration continue, choisir les méthodes et processus (parce que Scrum n’est qu’un cadre, il faut bien à un moment choisir ses méthodes !!!), etc.
a) La phase d’avant-projet est essentielle. Le problème auquel Michaël a été confronté lorsqu’il parle de manque de connaissances lors du chiffrage initial, a été principalement généré (à mon sens) par l’absence de préparation de la pluridisciplinarité de l’équipe, c’est-à-dire sa capacité à réaliser les incréments de produit (et plus précisément sa capacité à respecter les critères de qualité attendus).
b) Scrum fixe un temps et un coût (c’est souvent lié) et ne fait qu’estimer le périmètre. Si on demande aux développeurs de déterminer un temps/un coût par rapport à un périmètre, on fait en fait, encore une fois, un cycle en v déguisé.
3/ Les séances d’affinage (Refinement) sont planifiées suffisamment régulièrement pour que l’ensemble de l’équipe puisse appréhender les Stories. Cette activité peut, d’après le Scrum Guide, représenter jusqu’à 5% du temps de l’équipe de développement, soit 2h par semaine ! Il est important d’exploiter ces séances pour définir les règles de gestion qui seront utilisées, identifier les « US de découverte » nécessaires, et s’assurer que toute l’équipe ait bien compris ce que cachait chaque US.
a) Aucun développeur ne devrait donc dans l’idéal découvrir une US le jour du sprint planning.
b) Scrum précise que le framework ne se substitue pas aux pratiques d’ingénierie. Il est donc normal d’organiser des séances de conception technique et de partage dans le sprint. Les besoins en recherche, en montée en compétences, etc., doivent être incorporés dans l’estimation des Stories ou mieux, si possible, faire l’objet d’un spike durant un des sprints précédent.
4/ N’oublions pas que Scrum est une méthode empirique ! Scrum défend le fait qu’il soit acceptable (voire souhaitable) de ne pas tout connaître à l’avance. La célérité de l’équipe, en premier lieu, est construite de manière empirique, après plusieurs sprints d’expérimentation !
a) Il est normal que les estimations de l’équipe soient complètement à côté de la plaque au démarrage, et durant plusieurs sprints.
b) Il est normal que les estimations soient également à côté de la plaque si l’équipe souffre une instabilité (turn-over, modification du nombre de membres ou des compétences de l’équipe, etc.).
c) Les estimations se fiabilisent au fil du temps, tout en restant fausses, et c’est uniquement à ce moment là que des projections sont possibles sur un macro-chiffrage. Mais le périmètre reste estimé, et sujet au changement d’un sprint sur l’autre. Il est toujours hors de question de s’engager sur un périmètre ou une célérité.
5/ Les Daily Scrum permettent uniquement de se rendre compte d’une potentielle dérive, traiter un obstacle pressant, et d’ajuster la cible du sprint si nécessaire (en enlevant des étapes intermédiaires de plus faible valeur pour le métier, par exemple). En aucun cas ce n’est une excuse pour rentrer dans le micro-management et pointer un individu du doigt.
a) Il est automatiquement admis qu’en aucun cas la dérive n’est intentionnellement créée par l’équipe de développement (chacun fait de son mieux, valeur pilier de l’Agilité). L’équipe a au contraire tout loisir de créer des tâches supplémentaires, elle est même encouragée à le faire à des fins de capitalisation.
b) L’équipe est solidaire dans la responsabilité.
c) C’est là où on voit tout l’intérêt de chiffrer les Stories et non les tâches: si le travail se complexifie (= on crée des tâches supplémentaires), le reste à faire reste équivalent, on a juste effectué plus de travail que prévu/ça a duré plus longtemps que prévu.
6/ Si en désespoir de cause, votre management fixe périmètre et planning, il ne vous reste qu’un seul poste à sacrifier: la qualité. C’est tragique même s’il faut s’y résoudre pour démontrer l’absence de pérennité de ce mode de fonctionnement. C’est la responsabilité du Chef de Projet de choisir son mode de gestion, il est seul responsable s’il choisit de sacrifier la qualité au profit du couple périmètre/délai. Sachez par contre que vous ne faîtes plus du tout du Scrum, ni même du cycle en v déguisé. Vous faîtes juste du trash code.
7/ Le SM n’est ni manager ni animateur désigné. Attention à ces positions hiérarchiques et à ces fiches de postes incohérentes avec le framework. Comme le souligne Michaël, beaucoup de Scrum Master ne maîtrisent pas Scrum. Si l’on commençait par ça? Maîtriser (= « master ») Scrum.
J’aimerais pour terminer exprimer un dernier conseil concernant la posture des lead développeurs. N’imposez rien à l’équipe, laissez le niveau de qualité émerger de l’intelligence collective. En imposant par exemple des pratiques élitistes, comme exprimé dans le podcast, on se met en totale contradiction avec les valeurs de Scrum, dont l’essence même est l’absence de rapport d’autorité individuelle, et on empêche finalement le framework de fonctionner de manière optimale. Convainquez par le leadership, en expliquant et en formant, pas en utilisant les craintes d’autrui (de déplaire, de déclencher un conflit, d’être humilié, etc.) pour imposer votre point de vue.
Bref, merci de m’avoir lu jusqu’au bout pour ceux qui en auront eu le courage, et encore désolé pour la longueur de mon texte…
Bonjour,
Petites corrections à apporter à mon précédent propos:
– Comme remarqué par Constantin Guay, la phrase « N’oublions pas que Scrum est une méthode empirique ! » doit être comprise comme « N’oublions pas que Scrum est un framework empirique ! »
– Après relecture du Scrum Guide, l’activité d’affinage peut représenter jusqu’à 10% et non 5% de la capacité de développement. Cette activité peut donc représenter plus d’une demi-journée dans la semaine. L’équipe a donc du temps à mettre à profit! 🙂
Merci Pail-Emmanuel pour ce feed-back détaillé ! 😘