Je ne suis pas un commercial avant-vente, ni même un aficionados de Scrum et pourtant je me trouve à nouveau en train de prendre sa défense (ou du moins à apparaître comme tel). Il y a quelques semaines, une étude intitulée “Où est le problème avec scrum, et comment pouvons-nous corriger cela ?” (tout en lettres capitales) a été rendue public. Les résultats ont donc eté publiés et me voici donc de nouveau à endosser le rôle de défenseur de scrum.

Ce que je défends, en réalité, c’est l’idée suivante - si nous voulons critiquer quelque chose, alors critiquons-la pour ce qu’elle est réellement et non pour un ersatz de celle-ci.

Les résultats de l’étude sont là : http://agilelion.com/agile-kanban-cafe/what%E2%80%99s-problem-scrum-and-how-can-we-fix-it.

La définition de scrum se trouve ici : http://scrumguides.org.

Bon, allons-y.

Le point le plus frustrant de scrum : 34% des personnes interrogées citent utilisation des points de story pour estimer comme la partie la plus frustrante de scrum. Il y a juste un petit problème : cela ne fait pas partie de scrum. Cliquez sur le lien du guide scrum et vérifiez donc par vous-même.

Le deuxième point le plus frustrant de scrum : il n’existe pas de rôles spécialisés tel qu’architecte, responsable produit, analyste métier, responsable de projet, etc. Ce point n’est pas du tout frustrant pour les personnes intéressées par la mise en pratique de scrum. C’est uniquement frustrant pour les personnes voulant continuer à travailler comme à l’époque de l’ère industrielle. Scrum définit trois rôles, et sous les auspices de l’un d’entre eux (un Développeur), une équipe peut avoir des spécialistes, si c’est ce que l’équipe veut, ou si c’est le mieux que l’organisation est en mesure de faire pour le moment. Dans les résultats détaillés de l’étude, il est dit que Scrum définit des “rôles stricts” ; c’est tout à fait le contraire. Par conséquent, cette critique est un non sens.

Le troisième point le plus frustrant de scrum : le manque de pratiques techniques informatiques (23%). Ken Schwaber a décrit scrum comme étant “une sur-couche légère permettant de contrôler le processus empirique”. De plus, scrum est conçu pour gérer le développement de produit dans son ensemble, pas uniquement du développement logiciel. Par conséquent, l’omission de pratiques techniques n’est ni une erreur ni un “problème”.

On s’attend à ce que nous utilisions les bonnes pratiques appropriées quel que soit le type de produit que nous sommes en train de développer. Si notre produit s’avère être un logiciel, on s’attend donc à ce que nous sachions une chose ou deux sur le développement logiciel. Ce sont les mauvais ouvriers qui blâment leurs outils.

Le quatrième point le plus frustrant de scrum : le planning poker (21%). Le planning poker ne fait pas partie de scrum. Vérifiez le guide scrum par vous-même. Le planning poker a été inventé sur le vif par James Grenning pour sortir de l’impasse d’un débat sans fin entre deux personnes d’une équipe technique comme cela peut nous arriver de temps en temps. Toutefois, le planning poker est devenu une “chose” à part entière par la suite. Quoi qu’il en soit. Il s’agit d’un autre non sens.

Le cinquième point le plus frustrant de scrum : la réunion quotidienne en stand-up (16%). Aucune explication ne figure sur ce point dans l’article, donc c’est à nous d’essayer de deviner ce à quoi les personnes pouvaient penser en répondant cela. J’ai déjà vu des réunions quotidiennes en stand-up qui étaient inefficaces et inutiles, cette critique peut donc être compréhensible. Ce qui est moins compréhensible, c’est pourquoi les personnes ne font pas changer leur stand-up lorsqu’il ne leur apportent rien. Elles sont peut être à la recherche de règles plus directives ? Je leur souhaite bonne chance.

Le sixième point le plus frustrant de scrum : le graphique burn-down (15%). Aucune explication ne figure sur ce point dans l’article, donc c’est à nous d’essayer de deviner ce à quoi les personnes pouvaient penser en répondant cela. J’ai tellement vu de variations sur le problème des graphiques burn-down qu’il est difficile de savoir ce que les personnes voulaient dire par là, mais cela reste un ressenti qui peut être tout à fait compréhensible.

Ce que scrum dit vraiment c’est la chose suivante : “Différentes pratiques de projection, comme les burn-downs, les burn-ups, ou les flux cumulatifs, ont été utilisées jusqu’à présent pour prédire l’avancée (des travaux - NdT). Elles se sont avérées utiles. Toutefois, elles ne viennent pas remplacer l’importance de l’empirisme”. Il s’agit à nouveau d’un non sens et aussi d’une nouvelle occasion pour se poser la question - pourquoi les gens ne prennent pas la responsabilité de leurs propres résultats, et n’utilisent pas une méthode différente s’ils trouvent que les graphiques burn-down ne leur viennent pas en aide pour faire des prévisions. (Ou peut être qu’ils ne savent pas à quoi servent ces graphiques).

Nous trouvons à la septième place, deux ex-æquo avec 12%. Commençons avec le rôle du scrum master. Il s’agit effectivement d’une caractéristique de scrum presque toujours incomprise ou mal appliquée. Dans la plupart des organisations, ce rôle est une coquille vide, elles continuent d’appliquer au développement logiciel une conception du management datant de l’ère industrielle. J’ai vu énormément, énormément de cas problématiques du rôle de scrum master, et dans 100% de ces cas, le rôle était soit incompris soit la personne ayant ce rôle était dans l’incapacité d’exercer ses fonctions telles qu’elles sont décrites dans le guide scrum.

À la septième place se trouve également la cérémonie de toilettage du backlog. Toute personne connaissant à minima scrum sait que depuis 2011 la formulation du guide scrum a changé de toilettage à affinage. L’idée est de garder de manière incrémentale le backlog en bon état, en se focalisant sur les éléments à court terme aussi bien que les éléments à haut risque à tout moment. La formulation de cérémonie à évènement a aussi été changée. Un évènement de planification du sprint existe, au cours duquel un certain niveau d’affinage est fait, mais l’affinage du backlog est une tâche en continu de l’équipe scrum. En tant qu’équipe auto-organisée, elle est responsable pour déterminer la meilleure manière pour le faire dans son propre contexte. Ceux qui cherchent des règles à suivre ou un processus à blâmer pour leurs propres résultats seront déçus par scrum.

Le neuvième point le plus frustrant de scrum : le rôle de product owner (11%). Ce rôle est une autre caractéristique de scrum et un autre aspect de scrum souvent incompris et mal appliqué. Idéalement, le product owner ne fait pas partie de la direction informatique, mais partie prenante du métier ; et même possiblement sponsor du projet. En réalité, ce point en particulier est celui qui parmi les dix n’est que rarement faisable. Certaines organisations ont un groupe de PO, d’autres désignent un PO proxy à l’intérieur de l’organisation technique et d’autres pensent que le rôle de responsable produit peut prendre les responsabilités du PO définies dans le guide scrum. Il existe de nombreuses variations et beaucoup de prises de têtes autour du concept de PO. Certaines organisations arrivent à trouver comment gérer cela de manière efficace et d’autres non.

Le dixième point le plus frustrant de scrum : le sprint (100%). Oui, c’est effectivement un point frustrant pour la plupart des organisations. Ce n’est pas “scrum” qui est frustrant en tant que tel, c’est l’idée plus générale de durée limitée dans le temps (boîte de temps ou time-box - NdT) de l’itération (ce que scrum appelle pour certaines raisons un “sprint”). Les deux caractéristiques saillantes d’une itération limitée dans le temps, par opposition à une simple itération sont :

  1. Toutes les itérations ont la même durée; et
  2. Un incrément de la solution prête à être mise en production doit être livré au moins à la fin de chaque itération.

Voici ce que les organisations de l’époque de l’ère industrielle ont du mal avec. Leurs processus existants ont été pendant tellement longtemps basés sur la spécialisation des rôles de chacun, les passages de patates chaudes, et les revues post-mortem et les chaînes de responsabilités qu’il est presque impossible pour ces organisations de se libérer de ces contraintes qu’elles se sont elles-mêmes imposées. Ce que fait scrum, c’est de rendre toute cette merde visible. Les gens apprécient guère d’avoir la tête dedans jour après jour. Je ne peux les blâmer pour ça. Par contre, je peux les blâmer de ne rien faire pour changer ça.

Les personnes qui ont fait cette étude ont fait un excellent travail de collecte, de catégorisation et de résumer de l’information. Ce qu’ils n’ont pas fait par contre, c’est de ne pas avoir donné la plus petite indication qu’elles aient compris scrum.

Auteur : Dave Nicolette
Source : What’s the problem with “What’s the problem with Scrum?”
Date de parution originale : 14 avril 2016

Traducteur : Nicolas Mereaux
Date de traduction : 19/06/2016

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.