Bonjour les agilistes ! Au fil des parties du serious game Agile Smells, j’ai pu identifier des mauvaises pratiques récurrentes dans les organisations, équipes, structures que j’accompagne. Certaines de ces mauvaises pratiques sont, hélas, des grands classiques mais d’autres sont plus méconnues et obscures. Or, Barry avait écrit une série d’articles géniaux sur les mythes scrum , il y a quelques temps, qui recoupent en grande partie les mauvaises pratiques qui ressortent systématiquement lors de mes parties d’agile smells. Cette publication est une reprise enrichie et traduite de cette série à laquelle j’ai ajouté des médias et illustrations complémentaires.
Nous allons aujourd’hui briser les mythes suivants :
- Mythe 1. Le Scrum Master doit être présent lors du Daily Scrum
- Mythe 2: le Sprint Backlog ne peut pas être modifié pendant le Sprint
- Mythe 3: Les livraisons ne s’effectuent pas avant la fin du Sprint
- Mythe 4: Avec Scrum, le backlog produit doit être composé de user stories
- Mythe 5: Avec Scrum, le backlog produit doit être priorisé
- Mythe 6: Le product owner est principalement un proxy pour les parties prenantes
- Mythe 7: Le Scrum Master doit résoudre tous les problèmes de l’équipe
- Mythe 8: Le Scrum Master est un coach agile débutant
- Mythe 9: Les story point sont obligatoires dans Scrum
- Mythe 10 – Dans Scrum, il n’y a pas de planification
- Mythe 11: Avec Scrum, il y a trop de temps en réunion
- Mythe 12: La revue de sprint est une démonstration
Prêt pour le grand saut ? Alors commençons ! Vous le savez, Scrum est conçu comme un framework simple mais suffisant pour livrer rapidement la valeur de produits complexes. Scrum n’est pas une solution universelle, une solution miracle ou une méthodologie complète. Scrum fournit les limites minimales à l’intérieur desquelles les équipes peuvent s’auto-organiser pour résoudre un problème complexe en utilisant une approche empirique…et trop souvent nous observons les mythes suivants :
Barry Overeem
Je libère les individus, les équipes et les organisations des méthodes de travail obsolètes. En apportant une énergie et une créativité nouvelles, je crée un espace permettant à chacun de participer à la construction de l’avenir et d’avoir un impact positif sur leur organisation.
En tant que formateur Scrum professionnel sur Scrum.org, je partage mes idées et mes connaissances en donnant des formations Scrum, en animant des ateliers, en prenant la parole lors de conférences et en écrivant des billets de blog.
1. Le Scrum Master doit être présent lors du Daily Scrum
Dans son article, Barry décrit le mythe selon lequel le Scrum Master doit toujours être présent lors du Daily Scrum (ou stand-up). Le point à retenir est que la responsabilité du Scrum Master est que le daily ai bien lieu, mais c’est bien l’équipe de développement qui est responsable de la conduite du point. En complément de l’article, vous trouverez ci-dessous une vidéo de mon compère Jean-Pierre Lambert qui vous donne avec une bonne dose d’humour les trucs et astuces pour rater son daily !
Comme vous l’avez remarqué, nous allons être taquin sur les pratiques. Le but étant d’amener un questionnement. Avant d’aller plus loin, avez-vous lu le Scrum Guide ? Non ? Alors téléchargez-le gratuitement en Français ci-dessous !
2. Le Backlog de Sprint ne peut pas changer pendant le Sprint
Ce mythe est persistant dans de nombreuses équipes qui fonctionnent avec SCRUM. Il faut distinguer l’objectif du sprint et l’engagement de l’équipe.
À garder après lecture de l’article de Barry :
- Bien que l’objectif de sprint soit fixe pendant le sprint, le backlog de sprint ne l’est pas.
- Le Sprint Backlog est flexible, tant que les changements ne détournent pas l’attention de l’objectif Sprint.
- Embrassez la nature émergente du Backlog Sprint.
Au delà de ces remarques, certaines équipes s’engagent sur une capacité de production lors d’une itération mais pas sur un objectif, un périmètre ou une fonctionnalité. Si je n’aime pas cette pratique (qui casse le lien entre le business et l’équipe de DEV), elle permet de pleinement prendre conscience qu’il ne faut pas s’interdire d’être intelligent en restant borné sur un backlog de sprint fixe.
3. Les livraisons ne s’effectuent pas avant la fin du Sprint
Cette fois, Barry s’attaque à un mythe heureusement de moins en moins courant (merci Devops) à savoir celui selon lequel les équipes Scrum sortent au mieux un incrément viable à la fin d’un sprint, contraignant les équipes capables de livrer plus rapidement. Scrum encourage en fait les équipes à améliorer leurs processus, leur infrastructure et leurs pratiques au point où les livraisons peuvent être effectuées tout au long du Sprint. Chez un de mes clients actuel, nous avons réussi à passer d’une livraison mensuelle à une livraison à la demande…. et quel bonheur : Nous pouvons livrer quand nous le désirons et dès que cela fait sens. Attention cependant, livrer trop souvent, par exemple dès qu’une fonctionnalité mineure est disponible peut-être un non sens. Il faut avoir en tête qu’aussi automatisé soit-elle, une livraison sur un environnement de production à un coût. Il faut donc trouver le juste équilibre entre valeur livrée et livraison.
À retenir de l’article :
- Le Sprint représente une limite minimale pour le moment de livrer un incrément produit «Terminé».
- Plus l’incrément est «terminé», plus les feed-backs recueillis lors de la revue de sprint seront utiles.
Au fait, l’illustration ci-dessus est tirée de l’étude accelerate. J’y ai consacré une vidéo humoristique à découvrir ici !
4. Le Product Backlog doit forcément contenir des User Stories
Ici, Barry brise le mythe selon lequel le backlog produit doit obligatoirement contenir des user stories. Saviez-vous que les User Stories, si elles sont très utiles, ne sont ni mentionnées dans le scrum guide ni nécessaires au bon fonctionnement de Scrum.
Attention, je répète que bien que non nécessaires, les users stories sont une excellente technique pour saisir les exigences fonctionnelles d’une manière «suffisamment bonne pour l’instant» tout en laissant l’opportunité d’avoir de nouvelles conversations. Dans l’absolu, Scrum demande trois choses :
- Rendre le besoin et le Product Backlog compréhensible pour l’équipe Scrum et ses parties prenantes.
- Le niveau de détail doit correspondre à l’incertitude du développement du produit.
- Il faut favoriser une communication et une conversation continues entre l’équipe Scrum et les parties prenantes (ce qui inclut les utilisateurs).
5. Le Product Backlog est priorisé
Bon, il faut admettre qu’ici Barry chipote un peu en marquant la différence entre la “priorisation” et le fait que le Backlog soit une “liste ordonnée”. En effet, la priorisation stricte enferme le rôle de Product Owner dans un rôle avec cette unique responsabilité. La liste ordonnée sous-entends qu’il “en continu” du Backlog Produit afin de maximiser la valeur livrée au fur et à mesure que le travail progresse et que des informations émergent.
À retenir de l’article :
- L’accent mis sur la liste ordonnée plutôt que sur la «priorisation» souligne le rôle actif que le Product Owner doit continuellement jouer de manière à maximiser la valeur.
- En définissant le Product Backlog comme une liste prioritaire, nous simplifions à outrance le rôle du Product Owner.
- Il existe d’innombrables facteurs qui influencent l’ordonnancement du backlog : les dépendances, les risques, les connaissances, les coûts, les conditions commerciales, le coût des retards, etc.
6. Le product owner est un proxy pour les parties prenantes
Dans cet article, Barry brise le mythe selon lequel le Product Owner est un proxy pour les parties prenantes. L’essentiel est que les équipes Scrum deviennent beaucoup moins agiles lorsque seul le Product Owner communique avec les parties prenantes. Au lieu de définir le Product Owner en tant que proxy pour les parties prenantes, nous préférons plutôt expliquer le Product Owner comme la personne responsable d’inclure les parties prenantes dans la conversation avec l’équipe de développement.
Ce qu’il faut garder de cette lecture :
- Scrum est un processus de «découverte collaborative» et d’amélioration des processus
- Le Product Owner est responsable d’inclure la voix des parties prenantes dans le processus de «découverte collaborative»
7. Le Scrum Master doit résoudre tous les problèmes
Aujourd’hui, Barry évoque le fait que le Scrum Master n’est pas Super Man. Il n’est pas responsable de la résolution de tous les problèmes qui empêchent l’équipe de développement d’atteindre l’objectif de sprint. En effet, le Scrum Master doit plutôt aider l’équipe de développement à devenir de plus en plus capable de résoudre des problèmes par elle-même (auto-organisation). C’est l’histoire de la canne à pêche et du poisson. Dans l’article, Barry propose quelques exemples concrets et clarifié de problèmes qu’une équipe de développement devrait résoudre, et quels problèmes sont des «obstacles» à lever par le Scrum Master.
N’oubliez pas : “Un Scrum Master doit révéler, pas résoudre.”
8. Le Scrum Master est un coach agile junior
Non, le scrum master n’est pas un coach agile junior (enfin pas forcément). Un changement efficace est conduit de “l’intérieur”. Le Scrum Master – faisant partie de l’équipe Scrum – est mieux placé pour faciliter ce changement qu’un coach Agile qui est externe à l’équipe. Les Scrum Masters doivent être actifs, légitimes et soutenus pour promouvoir le processus empirique à tous les niveaux de l’organisation. S’ils le peuvent et s’ils le font, aucun autre rôle n’est nécessaire pour aider les organisations à générer des résultats précieux via Scrum.
À retenir:
- “Un bon Scrum Master aide une équipe Scrum à survivre dans la culture d’une organisation. Un grand Scrum Master aide à changer la culture afin que les équipes Scrum puissent prospérer. ” – Geoff Watts
- “Le Scrum Master permet le changement de l’intérieur vers l’extérieur.”
- “Les chances d’adoption réussie de Scrum augmenteront considérablement si vous considérez votre Scrum Master comme le véritable facilitateur du changement”.
- “La réalité est que la plupart des coach agiles sont des Scrum Masters juniors.”
- “Le changement organisationnel doit être conduit de l’intérieur par des personnes qui font vraiment partie des équipes.”
Par ailleurs et concernant ce mythe SCRUM, je ne peux que vous conseiller de lire l’excellent article de Géraldine Legris : Du scrum master au coach, une mutation
9. Les Story Points sont requis dans Scrum
Dans cet article, nous nous attaquons au mythe selon lequel Scrum exige que le travail soit estimé en Story Points (suite de Fibonacci ou autre). Bien que ce soit une technique utile et utilisée par de nombreuses équipes Scrum, ce n’est en aucun cas la seule et unique technique. Cet article décrit certaines alternatives et explique pourquoi les Story Points sont devenus courants.
Surtout, souvenez-vous de la citation d’Esther Derby: «L’estimation est souvent utile, les estimations ne le sont souvent pas.» Plus l’activité en question est complexe, plus la communication et la collaboration sont importantes.
À retenir :
- Utilisez le processus empirique de Scrum pour capitaliser sur le changement plutôt que de le contrôler.
- Les estimations basées sur le temps confirment l’illusion d’exactitude et de prévisibilité.
- Respectez la complexité du développement logiciel et ne laissez pas l’estimation remplacer l’importance de l’empirisme lui-même.
10. Dans Scrum, il n’y a pas de planification
Dans ce post, Barry étrille le mythe selon lequel il n’y a pas de planification dans Scrum. En fait, il y a beaucoup de planification en cours. Les différents évènements Scrum génèrent un certain nombre de plans, exprimés à travers (entre autres) le Product Backlog, le Sprint Backlog et la Definition of Done. L’accent est mis sur la planification en tant qu’activité pour créer une compréhension partagée de ce qu’il faut faire ensuite.
Bien qu’il soit parfois dit que «la planification est utile, les plans ne le sont pas». Nous pensons que cela renforce le mythe en soulignant que les plans sont toujours mauvais. Dans cet article, nous avons montré que les plans sont utiles, tant qu’ils respectent la complexité et l’imprévisibilité du développement de produits. Un énoncé plus précis serait:
«La planification est utile. Les plans sont utiles. Des plans détaillés sont une perte de temps. »
À retenir de cette lecture :
- La planification doit être un effort de collaboration entre toutes les personnes impliquées.
- Chaque fois que nous parlons de plans dans Scrum, nous parlons de plans comme une «compréhension partagée».
- Les événements Scrum sont les moments minimaux où la planification a lieu.
- Dans l’environnement complexe du développement de produits, où le changement est continu, les plans détaillés sont une forme de gaspillage.
Mythe 11: Dans Scrum, nous passons trop de temps en réunion
Pour ce mythe, nous avons brisé l’affirmation selon lequel dans Scrum, trop de temps est consacré aux réunions. Au delà de donner de nouveau le timeboxing des événements Scrum, nous avons également clarifié leur but et leur importance. Si vous donner aux événements SCRUM le sens profond qu’ils ont, alors on ne vous dira jamais que c’est une perte de temps. Après avoir expliqué les origines de ce mythe, nous avons proposé quelques conseils pratiques pour prévenir ou résoudre les symptômes.
Mythe 12: La revue de sprint est une démo
Dans cet article, nous avons brisé le mythe selon lequel la revue de Sprint consiste à faire uniquement la démonstration de l’incrément aux parties prenantes. Bien qu’une démonstration puisse certainement faire partie d’une revue de sprint, elle ne parvient pas à saisir en quoi consiste la revue de sprint: une collaboration entre l’équipe Scrum et les parties prenantes pour inspecter l’incrément et les progrès à ce jour et décider des prochaines étapes ayant le plus de valeur.
Un autre article de Jean-Claude Grosjean donnera des tips en Français pour une bonne revue de sprint.
Pour conclure
Et voilà ! Nous avons fait le tour de 12 mythes SCRUM et…nous n’avons certainement pas encore fini ! Et vous ? Rencontrez vous certaines de ces pratiques régulièrement ?
1. Le Scrum Master doit être présent lors du Daily Scrum
D’accord et pas d’accord, le scrum master n’anime pas la cérémonie certes, mais sa présence, bien que non obligatoire reste souhaitable, il reste maître du timing et du respect des règles de celle-ci, surtout quand on sait à quel point cette cérémonie à tendance à partir en vrille facilement. Cela dit, c’est beaucoup plus vraie sur des équipes moins mature. Le but d’un SM est d’être très présent au départ mais moins sur le temps lorsque l’équipe maitrise mieux le sujet et le fonctionnement.
2. Le Backlog de Sprint ne peut pas changer pendant le Sprint
La, pas trop d’accord, le principe est que le backlog soit figé pour le sprint en cours, excepté cas de force majeur bien sûr … Je trouve que de présenter les choses comme vous le faite en parlant d’objectif du sprint vs backlog et son contenu est un peu bancal. Pk ? parce que je peux facilement vous changer le contenu du backlog tout en gardant le même objectif, or il y a x façon de faire la même chose et certaine plus difficile/complexe que d’autre … or, qui dit changement de “spec” dit aussi qu’il faut que ces changement est été chiffré/planifié, qu’il respect le DoR/DoD, etc… donc bon, pratique à éviter, à mon sens, sauf si vraiment une urgence de dernière minute se présente et force l’équipe à le faire mais même dans ce genre de cas on peut tout autant interrompre le sprint (oui c’est faisable) pour en redéfinir un autre (mais bon c’est souvent plus simple de tenir la récurrence que de chambouler les agendas de tous le monde)
3. Les livraisons ne s’effectuent pas avant la fin du Sprint
La aussi pas tout à fait d’accord.
Enfin sur le principe, je suis totalement d’accord, en vrai. Par contre, en théorie, pas trop le principe de scrum est de livré des itérations du produits (en forme de lot/package) de manière régulière et non pas en continu … bon certes comme évoqué dans l’article, rien ne l’interdit et si c’est possible et souhaité par le client etc… pourquoi pas… mais on est plus dans du scrum “pur” mais dans du scrumban.
Encore une fois, je ne suis pas du tout contre, mais appelons un chat, un chat
4. Le Product Backlog doit forcément contenir des User Stories
Tout à fait d’accord (enfin me direz-vous).
Il ne faut pas oublier un principe de l’agilité … on prend ce qui fonctionne pour son organisation et on remplace ce qui ne fonctionne pas … le principe reste de faire en sorte que l’organisation, que ce soit à l’échelle d’une équipe, de plusieurs, d’une dsi ou d’une entreprise, fonctionne et c’est tout, que ce soit avec des specs de 500 pages ou des users stories.
5. Le Product Backlog est priorisé
Alors, assez d’accord sur ce sujet. J’ai été pendant un temp PO/PM et la priorisation est un vaste sujet et la réduire à la maximisation de la valeur ne veut rien dire d’une part et des fois les priorité ne sont pas toujours purement business … une mises à jour technique n’apporte souvent rien à l’utilisateur (du moins pas directement) et pourtant pour X raisons (sur lesquelles je ne vais pas m’étaler) elles sont nécessaires… autres exemples flagrant, la dette technique (qui doit être maitrisée mais contenu quand on l’a crée de façon voulue par soucis de simplicité à un moment donné)
6. Le product owner est un proxy pour les parties prenantes
Rien à redire par rapport au contenu de l’article en lui même. Cependant, j’ai été PO, avec un background purement technique et donc le fonctionnel, le périmètre sur lequel je suis intervenu, m’était inconnu, je me suis donc beaucoup reposé sur les utilisateurs et autres business owners que j’avais en face de moi pour faire mon travail. Il y a, en France du moins, une recrudescence de demande de profil de PO “IT” qui souvent assez à des PO fonctionnel voir des business owner fonctionne assez bien à mon goût car ils sont utile à la traduction du fonctionnel vers la technique. Attention cependant à ne pas en faire des cdp technique à la fin ou des amoa.
7. Le Scrum Master doit résoudre tous les problèmes
J’irai même plus loin en disant que le SM ne résout aucun problème. il met en place la synergie permet la résolution des problèmes.
8. Le Scrum Master est un coach agile junior
Plutôt d’accord avec vos propos, il y a une confusion qui s’est installé sur ces 2 rôles, encore faut-il qu’en face on sache que le coach agile existe (et oui encore avant hier, j’ai appris cela à quelqu’un et on est mi-2020…)
Les é rôles sont en même temps extrêmement similaire et différent. Similaires dans le sens où dans l’essentiel les deux font ou vont faire la même chose (plus ou moins, ne chipotons pas sur les détails) mais à des niveaux très différent, l’un se cantonne aux niveau de ou des équipes dont il à la charge, l’autre au niveau de l’organisation et cela inclut plus de “stratégie” (au sens conseil en stratégie) que pour le SM.
9. Les Story Points sont requis dans Scrum
Ils ne le sont pas mais ils sont, cependant, préférable notamment au chiffrage jours/homme qui à vouloir être (trop) précis ne l’est absolument pas et est souvent la cause des retards pris sur les projets gérer de manière plus classiques. Après suite de Fibonacci, suite logiques, suite affines, etc… tant que votre systèmes vous aide à mesurer la complexité plus que le temps de réalisation, cela fonctionnera. il faut ensuite pouvoir être en capacité de timeboxé cette complexité dans la capacité de réalisation de l’équipe.
10. Dans Scrum, il n’y a pas de planification
Alors la, “spot on” … j’en ai vu des équipes qui ne chiffraient aucune carte (voir avait des cartes vide si ce n’est le titre…) et autant vous dire que pour tout ce qui concernait la planification, la stratégie etc… c’était tout simplement impossible … puisque, essentiellement, il était impossible de déterminer une fenêtre de livraison … sans chiffrage, pas de planification.
11. Dans Scrum, nous passons trop de temps en réunion
Lorsque j’étais dev, je partageais totalement cet avis… maintenant que je suis passé de l’autre côté de la barrière mon avis à fait un 180… mais, de mon expérience, c’est un point de vue qui n’a pas évolué sur le marché, les devs pensent qu’il y a trop de réunion et rechigne à y participer très souvent voir même rechignent à en comprendre l’intérêt.
12: La revue de sprint est une démo
Rien à dire sur ce point je suis d’accord. Mais par soucis de cohérence, je le fait apparaitre dans mon comm