En 2010, Ken Schwaber et Jeff Sutherland ont écrit la première version du Scrum Guide pour aider les gens du monde entier à comprendre Scrum. Scrum est rapidement devenu le framework n°1 dans l’industrie du développement logiciel.
Je suis moi-même un grand passionné de Scrum. Cela dit, il est facile de remarquer que de nombreuses personnes essaient d’utiliser SCRUM en dehors des zones où ce framework est optimal. C’est comme essayer d’extraire une dent avec un marteau. Scrum n’est pas une panacée qui peut être utilisée en toutes circonstances, et lorsqu’il est mal utilisée, il peut entraîner plus de pertes que de bénéfices.
Ci-dessous, je présente 4 raisons pour lesquelles Scrum n’est peut-être pas le meilleur framework pour vous.
1. Le domaine de travail n’est pas complexe
Il vous faut réaliser que l’utilisation de Scrum est optimale lorsque vous travaillez dans un domaine à la frontière entre le compliqué et le complexe.
“Scrum est un framework qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes” – Scrum Guide 2020
Pour comprendre ce qu’est la complexité, regardons le modèle de Stacey modifiée. Il existe 3 dimensions majeures de la complexité :
- Certitude sur ce qui est nécessaire.
- Certitude sur la technologie.
- Certitude sur les gens.
Pour plus de détails, je vous invite à regarder l’émission ci-dessous :
Comme vous avez pu le voir en regardant l’émission, il existe 5 domaines :
- Simple – Les “connus-connus”. La relation de cause à effet est claire. Il existe des solutions éprouvées ou des procédures qui peuvent être facilement appliquées par n’importe qui. Un exemple peut être la préparation du café avec une machine à café.
- Compliqué – C’est le domaine des “connus-inconnus”. Les meilleures solutions existent et peuvent être découvertes rationnellement en analysant la relation de cause à effet et en planifiant soigneusement vos actions dès le départ. Un exemple peut être de jouer aux échecs ou de construire une maison.
- Complexe – Le domaine des “inconnus-inconnus”, lorsque la relation de cause à effet peut être définie rétrospectivement. C’est alors que les avantages de l’empirisme émergent – acquérir des connaissances par la formulation et la vérification d’hypothèses, progresser étape par étape dans des cycles et ajuster le plan en fonction des retours d’expérience. Cela signifie également essayer de nombreuses idées et faire des erreurs en cours de route.
« Scrum est fondé sur l’empirisme et la pensée lean. L’empirisme affirme que la connaissance vient de l’expérience et de la prise de décisions en fonction de ce qui est observé (…) Scrum utilise une approche itérative et incrémentale pour optimiser la prévisibilité et contrôler les risques. — Guide Scrum 2020
Le Framework Cynefin recommande un processus appelé “probe-sense-respond”. Dans Scrum, il s’agit du processus PDCA (plan-do-check-act) itératif très similaire, qui s’appuie sur les piliers empiriques de Scrum que sont la transparence, l’inspection et l’adaptation.
La plupart des initiatives de produits de nos jours, en particulier dans l’industrie du développement de logiciels, se situent dans un domaine complexe. Cependant, si vous installez et configurez un produit éprouvé pour votre 20e client, cela peut être considéré comme compliqué, pas complexe. Dans ce cas, une méthodologie Waterfall (gestion de projet linéaire) pourrait être un choix valable.
Chaotique – Dans ce domaine, la cause et l’effet ne sont pas clairs. Il n’est pas possible ou le temps manque d’acquérir des connaissances ou de découvrir des modèles par l’expérimentation. Un chef doit agir pour établir l’ordre, éteindre le feu et essayer de se déplacer vers le domaine complexe. Un exemple peut être les investisseurs réagissant instinctivement aux attentats du 11 septembre.
Nous ne savons pas – Le Framework Cynefin l’appelle “trouble”. Nous ne savons pas à quel type de relation de cause à effet nous avons affaire. Il est important de ne pas rester dans votre zone de confort, d’accepter la confusion et de communiquer ouvertement la situation.
2. L’environnement change trop vite
Il convient de noter que Scrum a été créé en tant que cadre de développement logiciel, au rythme de l’évolution des conditions externes qui lui sont spécifiques. À mon avis, les informations sur la possibilité d’utiliser Scrum dans différents domaines doivent être interprétées avec une attention particulière.
Ne vous méprenez pas. Dans certaines circonstances, cela peut réellement fonctionner.
Lorsque la réponse aux changements doit être plus rapide, par exemple en faisant des investissements à court terme, à mon avis, Scrum n’est sans doute pas la solution optimale.
Cela s’applique également à la création de startups et à la découverte de produits. Vous voudrez peut-être envisager des stratégies telles que le Lean Startup dans ce cas, bien que cela dépende beaucoup de l’objectif de Sprint que vous avez défini et de la durée du Sprint.
(NDT : Quand l’environnement change vite, peut-être que FAST est plus adapté !)
3. Dépendances externes que vous ne pouvez pas surmonter
Les dépendances externes peuvent réellement entraver ou empêcher la pleine efficience de Scrum. Par dépendance externe, je comprends une situation où l’équipe n’est pas en mesure de faire le travail sans attendre les autres, par exemple des experts externes.
Scrum exige une équipe interfonctionnelle capable de créer de la valeur lors de chaque Sprint :
“Les équipes Scrum sont interfonctionnelles, ce qui signifie que les membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint (…) L’équipe Scrum est suffisamment petite pour rester agile et suffisamment grande pour effectuer un travail important au sein d’un Sprint (…)”— Scrum Guide 2020
Et la valeur est créée lorsque l’élément de backlog produit répond à la définition de terminé (la D.O.D) :
« Les artefacts de Scrum représentent du travail ou de la valeur (…) Un incrément est un tremplin concret vers l’objectif du produit (…) Afin de fournir de la valeur, l’incrément doit être utilisable (…) Au moment où un élément du backlog produit répond à la définition de terminé, un Incrément est né. — Guide Scrum 2020
En pratique, les dépendances ne peuvent pas être complètement évitées. Cela vaut la peine d’en tenir compte lors de la détermination de la durée des Sprints, tout en se rappelant que l’allongement de la durée du Sprint peut augmenter le risque et l’incertitude.
“Lorsque l’horizon d’un sprint est trop long, l’objectif du sprint peut devenir invalide, la complexité peut augmenter et le risque peut augmenter.” — Guide Scrum 2020
Mais c’est un non sens d’avoir des sprint trop longs. D’ailleurs, la durée maximale d’un Sprint est d’un mois calendaire.
Un problème courant auquel sont confrontées les équipes est l’incapacité à mettre en œuvre rapidement des solutions dans un environnement de production, en particulier si le CI/CD n’a pas été mis en œuvre.
De nombreuses équipes ont fait un compromis pour exclure une telle exigence de la définition de terminé de manière à pouvoir terminer le travail pendant le sprint, par ex. en déployant du code dans un environnement de test.
Cette solution est loin d’être idéale, car nous perdons la possibilité de transmettre le produit aux utilisateurs finaux, mais au moins, elle est transparente.
Si vous avez encore besoin de plus de temps, c’est-à-dire si les travaux ne peuvent pas être achevés en un mois et qu’il n’y a aucun espoir de changer cela, soyez prudent : Il ne sera pas possible de livrer de la valeur pendant le Sprint ni d’inspecter l’Incrément pendant la Revue de Sprint.
En fait, quel que soit l’approche que vous choisissez, résoudre des problèmes complexes dans des conditions qui entravent le contrôle empirique des processus peut s’avérer être un énorme défi.
Lors de l’examen des dépendances, beaucoup dépend de qui prend réellement la décision d’utiliser Scrum. Scrum ne résout pas les problèmes organisationnels, mais il peut les rendre visibles. Si une organisation est déterminée à utiliser Scrum, il y a de fortes chances que quelque chose change avec le temps. Cependant, une seule équipe prenant cette décision peut ne pas avoir d’impact sur l’environnement, et même si les problèmes deviennent apparents, personne dans l’organisation ne s’en souciera.
4. Plusieurs produits et plusieurs équipes
À mon avis, Scrum fonctionne mieux lorsque 1 à 3 équipes travaillent sur un seul produit. Dans ce scénario, il y a :
- un Product Owner pour le produit
- un Scrum Master pour chaque équipe Scrum
À mesure que le nombre d’équipes augmente, les dépendances entre les équipes peuvent augmenter considérablement et il peut devenir nécessaire d’employer des techniques supplémentaires. Le framework Nexus (ou SAFe ?) pour la mise à l’échelle de Scrum, appelé « exosquelette Scrum », peut être un bon choix.
Dans le même temps, il convient de rappeler que le cadre Scrum n’est pas conçu pour les deux scénarios suivants* :
- Une équipe travaillant sur plusieurs produits
“L’unité fondamentale de Scrum est une petite équipe de personnes, une équipe Scrum (…) C’est une unité cohérente de professionnels concentrés sur un objectif à la fois, le Product Goal.” — Guide Scrum 2020
En pratique, de nombreuses équipes commencent à travailler sur de nouveaux produits en effectuant de petites tâches dans d’autres domaines. À mon avis, c’est acceptable tant que l’équipe est capable de se concentrer sur l’essentiel et que les tâches restantes prennent un peu de temps. Cependant, développer deux produits différents en même temps (par exemple, dans un rapport 50:50) peut être douloureux.
- Plusieurs équipes travaillant sur plusieurs produits
Dans ce cas, les membres de l’équipe sont souvent partagés entre les projets et les équipes, ce qui les réduit effectivement au rôle de ressources. Il arrive qu’une personne travaille sur 2 à 3 projets différents le même jour. Les dépendances entre les produits peuvent devenir chaotiques et imprévues, et le coût du changement de contexte peut réduire considérablement la productivité. Je ne suis pas sûr qu’il existe un cadre qui puisse être efficace dans cette situation.
*Puisque certaines personnes peuvent avoir une opinion différente, je recommande la vidéo officielle de Scrum.org qui l’explique plus en détail :
Dernières remarques
Ceci n’est pas un article anti-Scrum. En effet, le framework Scrum est idéal pour de nombreuses initiatives de produits complexes, en particulier dans l’industrie du développement de logiciels où son application est la plus mature.
Dans le même temps, de nombreuses organisations décident de “passer à Scrum” dans l’espoir que cette simple décision résoudra tous les problèmes. C’est un peu comme croire que n’importe quel patient peut être guéri avec un scalpel.
Scrum n’est pas une panacée pour tout, et la réalité peut être un peu plus complexe. Chaque fois que vous rencontrez un problème, je vous recommande de réfléchir à ses caractéristiques, puis de choisir les bons outils qui vous aideront le mieux à le résoudre. Il n’y a pas de réponses simples. Mais nous sommes habitués à travailler avec la complexité, n’est-ce pas ? 😉
Note du traducteur : Pour aller plus loin
Globalement, je suis d’accord : Scrum n’est pas approprié pour tous les contextes.
Je suis d’accord avec les raisons 1, 2 et 4. Pour la 1, j’ajouterais que Scrum ne convient pas à tous les contextes complexes, seulement à ceux qui sont proches du compliqué. Pour la 2, je déconseille Lean Startup qui est incohérent. Pour la 4, j’aurais cité Team Topologies et aussi Dave Snowden qui dit “On ne passe pas à l’échelle par imitation et agrégation mais par décomposition et recombinaison.”
Je suis moins d’accord avec la raison 3. Aucune méthode sera plus adaptée en présence de dépendances externes immuables.
Globalement aussi en accord et je rajouterai deux autres points par expérience fonctionner en scrum avec du BAU (business as usual ). Welcome context switch et incapacité d’estimer un peu
Et en parallèle à ça si les membres de l’équipes ne sont pas à 100% sur le produit (dans les deux derniers Kanban je recommande)