Dernière partie de mon décryptage d’un article sur Scrum dans laquelle j’aborde cette fois la partie Inconvénients du framework, telle que vue dans l’article original, avec mes commentaires.
- Je remets ici le lien vers l’article. (En Anglais)
- Pour lire la première partie, sur le survol rapide de Scrum, c’est là.
- Pour lire la seconde partie, sur les avantages de Scrum, c’est ici.
Les Inconvénients de Scrum
Mais comme tout framework, Scrum a aussi quelques inconvénients.
Rien n’est parfait, et la méthodologie Scrum ne fait pas exception. Dans certains cas, Scrum est combiné avec d’autres techniques de gestion de projet qui peuvent résoudre une partie de ces inconvénients.
Scrum n’est pas parfait…peut-être. Plus simplement je préfère dire qu’il ne s’adapte pas à tous les contextes. Par exemple il est inadapté quand le Backlog est composé de stories sans liens particuliers les unes avec les autres. La création d’objectifs de Sprint cohérents devient alors impossible, la collaboration en prend un coup (chaque développeur étant isolé sur sa problématique particulière) etc.
Accessoirement aussi, Scrum n’est pas une méthodologie mais un framework, un cadre de travail. L’auteur de l’article passe allègrement d’une terminologie à une autre sans se poser de questions…La différence entre les deux ? Quelques extraits du site Think Insights (traduit de l’anglais) nous renseignent pour y voir plus clair :
“En gros, une méthodologie est un moyen de résoudre un problème de manière systématique, alors qu’un “framework” est un modèle de structure autour duquel on peut construire quelque chose. […] Une méthodologie décrit non seulement les étapes dont vous avez besoin pour obtenir un résultat mais également la logique derrière ces étapes.
Un Framework est une structure lâche qui permet l’inclusion d’autres processus et outils, alors que la méthodologie, est assez limitée en termes de flexibilité.”
Scrum mène souvent à des dépassements de périmètre (”Scope Creep”), par manque d’une date butoir claire.
Les Deadlines
Pour commencer, il y a des “deadlines” claires en Scrum. Chaque fin de Sprint est une date butoir pour accomplir l’Objectif de Sprint. Depuis le Guide Scrum 2020, nous avons désormais un Objectif Produit à plus long terme, que l’on peut aisément imaginer associé à une deadline. Et même sans parler d’Objectif Produit, vous pouvez faire confiance à l’organisation pour en fixer une, il y en aura toujours. Et heureusement d’ailleurs, les contraintes ont du bon, et peuvent nous éviter de tomber en proies à la Loi de Parkinson par exemple.
Les Dépassements de Périmètre
En ce qui concerne les dépassements de périmètre, Scrum fonctionne en flux tiré et non poussé. Les développeurs sélectionnent leur travail en début de Sprint. À moins que quelqu’un leur ajoute des stories ou les oblige à “bourrer” le Sprint, il n’y a pas de raison valable pour qu’ils se retrouvent avec une indigestion de tickets à gérer. Ils doivent à tout prix se réserver une marge de manoeuvre (cf Kanban). Malgré tout, développer étant une activité parfois hautement imprévisible, certaines tâches peuvent induire des dépassements inattendus ou pire, des blocages…l’équipe renégocie alors le périmètre avec son Product Owner.
Idem au niveau du Backlog Produit. Il existe un rempart face au “Scope Creep” et il s’appelle le Product Owner. Un Product Owner doit savoir négocier, prioriser, se concerter avec les stakeholders, faire des compromis etc. Mais il doit aussi savoir dire “non”.
If you prioritize properly, there is no need to multitask. It is a symptom of “task creep”—doing more to feel productive while actually accomplishing less.
Timothy Ferriss – The 4 Hour Work Week
L’apprentissage
Autre raison qui peut générer des dépassements de périmètre : l’apprentissage. L’équipe apprend en faisant. Et de l’apprentissage, il y en aura presque toujours. La story 1 va nécessiter la story 2 pour la corriger, qui elle-même va générer la story 3 pour faire des ajustements etc.
In a traditional process, learning gets referred to as scope creep or bad requirements. In an Agile process, learning is the purpose. You’ll need to plan on learning from everything you build. And you’ll need to plan on being wrong a fair bit of the time.
Jeff Patton – User Story Mapping
Les chances d’échec du projet augmentent si les membres de l’équipe ne sont pas motivés ou peu coopératifs.
Dire ça, c’est enfoncer des portes ouvertes. Oui si les gens ne sont pas coopératifs, la mécanique va se trouver grippée…C’est valable pour n’importe quel framework, méthodologie, système, organisation etc…
L’adoption de Scrum dans de grandes équipes est compliquée.
On n’utilise pas Scrum sur de grandes équipes. On divisera une grande équipe en équipes plus petites. Scrum recommande d’avoir 10 personnes maximum dans l’équipe depuis 2020, Scrum Master et product Owner inclus. Il n’y a pas de limite basse. C’est une recommandation, pas un ordre. Ce qui veut dire que oui, à 7, 8,11 ou 12 personnes le framework fonctionne aussi. En gardant à l’esprit que plus on s’éloigne du chiffre 10 plus les risques de problèmes de communication augmentent.
Enfin, à l’échelle, pour coordonner plusieurs équipes, Scrum propose le framework Nexus, qui n’a rien de bien compliqué dans l’absolu, comparé à l’usine à gaz SAFe. Il est aussi possible de faire du Scrum of Scrum…Et oui, dès lors que les équipes se démultiplient, la synchronisation du travail devient un peu plus compliquée mais c’est valable pour toute organisation pas seulement Scrum…
Le framework ne peut fonctionner qu’avec des membres d’équipe expérimentés.
Je ne suis pas d’accord avec cette affirmation. Voilà ce que nous dit le Guide Scrum 2020 sur ce qui est attendu des membres de l’équipe :
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
Le Guide demande à l’équipe d’être pluridisciplinaire, pas que chaque membre cumule 15 ans d’expérience. Les membres de l’équipe peuvent être relativement inexpérimentés (sans aller jusqu’à la caricature). Ça ne les empêche pas d’apprendre par eux-mêmes au fil de l’eau et de faire les recherches nécessaires pour atteindre leurs objectifs, surtout dans un framework comme Scrum basé sur un processus itératif. Alors oui c’est sûr, en pratique les chose risquent de démarrer moins vite qu’avec un groupe équilibré mêlant développeurs chevronnés et débutants…
On reste quand même là sur un cas atypique…En général il y a toujours au moins un ou deux développeurs un peu plus aguerris que les autres pour donner une impulsion au groupe et transmettre leurs connaissances, c’est un point qui n’est (en général) pas laissé au hasard.
Les Daily Standups sont parfois frustrants pour les membres de l’équipe.
C’est même fréquent, oui. Et quand ça arrive c’est le moment de se demander pourquoi. Car bien évidemment le Daily Standup ne doit pas être frustrant, bien au contraire. C’est un évènement court, et les développeurs ont obligation d’aller à l’essentiel…un exercice qui n’est pas évident pour tous.
Parmi les points de frustration très courants on peut trouve la lassitude engendrée pas des Daily répétitifs et un Objectif de Sprint mal ficelé. Chaque développeur fait son petit tour des trois questions d’une voix endormie avant de passer la parole à son collègue aussi peu stimulé que lui…Une alternative possible : briser les “lignes d’eau” (les couloirs en natation, dans lesquels chacun nage séparément) et relancer la collaboration en les faisant s’interroger ensemble sur les items prioritaires et en les poussant à les réaliser à plusieurs. Les anglo-saxons utilisent le terme “swarming” pour décrire ce processus.
Si un membre de l’équipe part au milieu d’un projet, cela peut avoir un impact très nocif sur le projet.
Un départ a toujours un impact et c’est le cas avec n’importe quel autre framework ou méthodologie. Tout dépend du contexte, Scrum n’a pas grand chose à voir là dedans. De plus, si les départs étaient monnaie courante et posaient autant de problèmes, est-ce qu’autant d’organisations se mettraient à pratiquer Scrum ?
La qualité est difficile à obtenir tant que l’équipe ne met pas en place un processus de test agressif.
Qu’est-ce qu’un processus de test agressif ? Probablement “très contraignant”. Les test sont importants mais en Scrum la qualité est encadrée par de nombreux autres mécanismes, le plus évident étant la “Definition of Done” :
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
En bref, la qualité ne dépend pas uniquement des “processus de test” aussi violents soient-ils…
Un planning adéquat et des décisions intelligentes peuvent vous aider à dépasser les désavantages de la méthodologie Scrum.
Comme dit déjà plus haut, Scrum n’est pas une méthodologie mais un framework. C’est un lieu commun de dire que des décisions intelligentes aideront à outrepasser les inconvénients de tel ou tel système.
Pour ce qui est du planning, l’évènement est inclus dans le framework : le Sprint Planning. Au début de chaque itération, l’équipe établit son plan pour le Sprint. Ce plan est visible de tous : c’est le Sprint Backlog. Y figurent l’Objectif de Sprint (Pourquoi on fait ce que l’on fait), l’ensemble des “items” ou stories sélectionnées pour le Sprint (le quoi) et un plan d’action (le comment, les tâches des développeurs) pour livrer l’Incrément. Enfin, le plan ne serait pas complet sans les Product Backlog et l’Objectif Produit associés.
Par exemple, dans les équipes de grande taille, chaque membre a besoin d’avoir des rôles et des responsabilités aux objectifs précis, de telle sorte qu’il n’y ait aucun compromis sur la qualité et aucune excuse pour l’échec. Ceci pour maintenir l’équipe concentrée sur les objectifs du projet.
La Taille de l’équipe
Il n’y a pas d’équipes de “grande taille” en Scrum. Elles sont restreintes à un maximum approximatif de 10 personnes, Scrum Master et Product Owner inclus. Pourquoi dix personnes ? L’objectif est de maximiser la qualité de la communication entre les membres de l’équipe, qui commencerait à se dégrader au delà de ce chiffre.
Chaque membre a effectivement des responsabilités et objectifs précis, ce n’est pas un besoin, plutôt un impératif. Libre à chacun de changer, supprimer ou ajouter des rôles, mais nous ne parlerons alors plus de Scrum.
La Qualité
En Scrum, l’accent est mis sur la qualité et de fait, elle ne doit être compromise sous aucun prétexte. Elle est garantie par la “Definition of Done” qui établit un standard de qualité mis en place par l’équipe ou l’organisation. Cette définition aide l’équipe à rester concentrée sur ses objectifs.
Elle les aide également à planifier leurs Sprints. Plus la Definition of Done est astreignante, avec des standards très “durs” à respecter, plus les développeurs devront être sélectifs lors de leur Sprint Planning. Un illustration : dans un même Sprint ils peuvent soit réaliser une cathédrale soit une cinquantaine de bâtiments contemporains…
[…] the Developers are always accountable for:
– Creating a plan for the Sprint, the Sprint Backlog;
– Instilling quality by adhering to a Definition of Done;
– Adapting their plan each day toward the Sprint Goal; and,
– Holding each other accountable as professionals.
Guide Scrum 2020
L’échec
Il n’y a peut-être pas d’excuse pour l’échec (dans la formulation de l’auteur), en revanche il y a bien des raisons pour l’échec. En Agilité l’échec n’est pas un gros mot et sans aller jusqu’à dire qu’il est encouragé je dirais qu’il fait partie intégrante du processus. Pourquoi cela ? Parce qu’avec Scrum, le risque est mitigé par la durée relativement courte des Sprints.
Les moments d’inspection sont nombreux et si l’échec doit arriver, il arrivera relativement vite au terme du Sprint, ce qui permettra à l’équipe de s’adapter tout aussi rapidement. Cette vision est à contraster avec celle d’une équipe qui travaillerait dans sa grotte pendant un an avant de découvrir bien tardivement que leur travail ne correspond finalement pas aux attentes des stakeholders, du marché etc.
L’échec est surtout synonyme d’apprentissage. C’est une occasion en or pour l’équipe de tirer des leçons d’une situation inhabituelle et de progresser, sachant que l’amélioration continue est un des grands axes de l’Agilité. En Scrum, les discussions ayant trait à l’optimisation de notre façon de travailler se font lors de la Rétrospective.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible.
Scrum Guide 2020
De plus, le Scrum Master doit guider l’équipe efficacement pour éviter les pièges et assurer une réussite du projet à 100%.
Qu’est-ce qu’une “réussite du projet à 100%” pour commencer ? Je peux imaginer un cas de figure dans lequel l’équipe livrerait dans les temps impartis un Incrément de qualité (de valeur) qui satisfait pleinement les différentes parties prenantes, utilisateurs finaux inclus…et dans lequel les coûts seraient maîtrisés.
Dans un cas comme dans l’autre, le Scrum Master a effectivement un rôle de “guide”, entre autres responsabilités. Sans reprendre en détail l’ensemble des attributions du Scrum Master (listées dans le Guide Scrum), rappelons juste qu’il est au service non seulement de l’équipe dans son ensemble, mais aussi du Product Owner et de l’organisation.
Scrum a des inconvénients ?
Comme on peut le voir, la plupart des arguments de l’auteur sur les faiblesses du framework ne sont à mon avis pas valables. Elle sort des affirmations fallacieuses de son chapeau et les brandit comme autant d’inconvénients qui handicaperaient le framework. Sauf que le Guide Scrum n’a jamais imposé ni de “grandes équipes”, ni des équipes remplies d’experts. Et il y a bien des Deadlines, des Plannings etc. Bref, avec une bonne dose de mauvaise foi je pourrais moi aussi sortir une liste d’inconvénients longue comme le bras…
Bien que ses champs d’application soient innombrables, Scrum ne s’adapte de toute façon pas à tous les contextes. Et même dans des contextes parfaitement adaptés (comme le logiciel) sa mise en œuvre demande une vigilance de tous les instants afin d’éviter des dérives ou des interprétations farfelues comme dans l’article précité. C’est notamment le rôle des Scrum Master et Coach Agiles.
Cet article marque la fin de cette série sur les décryptages.
À bientôt !
Si vous avez manqué le début :
