La « méthode » Scrum, qu'est-ce que c'est ?La méthode Scrum, ou plus exactement le cadre de travail (framework) Scrum est de loin la méthode agile la plus utilisée dans le monde. Expérimentée en 1993, elle bénéficie aujourd’hui de nombreux retours d’expérience. Les conférences, communautés, formations, blogs, outils et ouvrages à son sujet ne manquent pas
Parler d’une « méthode » concernant Scrum n’est pas ce qu’il y a de plus approprié. Scrum ne se considère pas comme une méthode mais comme un cadre de travail (framework). Une méthode dit généralement « comment » faire les choses. Scrum ne dit pas comment réussir son logiciel, comment surmonter les obstacles, comment développer, comment spécifier, etc. Il se contente d’offrir un cadre de gestion de projet agile : des rôles, un rythme itératif, des réunions précises et limitées dans le temps, des artefacts (product backlog, sprint backlog, graphique d’avancement) et des règles du jeu.
Scrum repose sur un processus itératif et incrémental, où le produit est construit par petites étapes appelées sprints. Chaque sprint dure généralement de 2 à 4 semaines et produit une version fonctionnelle et potentiellement livrable du produit.
Scrum implique trois rôles principaux : le Product Owner, qui représente la voix du client et définit les priorités du produit ; le Scrum Master, qui facilite le processus Scrum et s’assure que l’équipe respecte les principes et les pratiques de la méthode ; et l’équipe de développement, qui réalise le travail technique nécessaire pour créer le produit.
Scrum se base également sur quatre événements clés : la planification du sprint, qui permet à l’équipe de définir ce qu’elle va réaliser pendant le sprint ; le stand-up quotidien, qui est une réunion courte où l’équipe fait le point sur son avancement et ses difficultés ; la revue du sprint, qui est une démonstration du produit réalisé pendant le sprint au Product Owner et aux parties prenantes ; et la rétrospective du sprint, qui est un moment d’amélioration continue où l’équipe identifie ses forces et ses axes d’amélioration.
Scrum utilise aussi des artefacts pour faciliter la communication et la transparence, tels que le backlog du produit, qui est une liste ordonnée des fonctionnalités souhaitées pour le produit ; le backlog du sprint, qui est une sélection des éléments du backlog du produit à réaliser pendant le sprint ; et l’incrément, qui est l’ensemble des fonctionnalités livrables à la fin du sprint. La méthode Scrum est une méthode flexible, adaptative et centrée sur la valeur, qui permet aux équipes de livrer des produits de qualité en tenant compte des changements et des retours du client.
Scrum est loin de faire l'unanimité
Santiago Valdarrama, enseignant en intelligence artificielle ayant 25 ans d'expérience dans le développement logiciel, a critiqué la méthode Scrum, qu’il considère comme un cancer pour les équipes de développement. Il raconte plusieurs anecdotes qui illustrent les problèmes qu’il a rencontrés avec Scrum, tels que :
- L’utilisation du poker comme outil de planification, alors que c’est un jeu.
- L’ajout de processus inutiles qui prennent plus de temps que le développement lui-même, comme les « cérémonies » (réunions quotidiennes, affinages, planifications, rétrospectives, etc.).
- L’interdiction des ordinateurs portables et l’obligation de rester debout pendant les réunions.
- La difficulté d’estimer la complexité des tâches avec des points de story, qui ne correspondent pas au temps réel ni à la valeur pour le client.
- L’utilisation de tailles de t-shirt pour mesurer le logiciel.
- La rédaction de contrats basés sur le nombre de points de story livrés, sans tenir compte des spécificités de chaque projet.
- La pression exercée par le management, le scrum master, le product owner et le tech lead, qui ont des attentes contradictoires ou irréalistes.
- Le recours à des indicateurs trompeurs comme la « vitesse de combustion » des points de story, qui ne reflètent pas la qualité du logiciel.
Le développeur affirme qu’il croit en l’agilité, mais que Scrum n’est pas agile. Il dit avoir essayé plusieurs variantes de Scrum avec des formateurs et des certifiés, mais que le résultat a toujours été le même : ça n’a pas marché. Il conclut que Scrum est un cancer qui va détruire votre équipe de développement :
Scrum n'est pas fait pour les développeurs. C'est un outil de plus pour que les managers aient l'impression de contrôler la situation.
Mais les meilleurs de Scrum sont ceux qui vous regardent dans les yeux et vous disent : « Si cela ne fonctionne pas pour vous, c'est que vous vous y prenez mal. Scrum, c'est tout ce qui fonctionne pour votre équipe ».
Mais les meilleurs de Scrum sont ceux qui vous regardent dans les yeux et vous disent : « Si cela ne fonctionne pas pour vous, c'est que vous vous y prenez mal. Scrum, c'est tout ce qui fonctionne pour votre équipe ».
Des réactions diverses à ses déclarations
Konrad Banachewicz, Principal Data Scientist chez IKEA, a applaudi cette sortie : « J'aimerais pouvoir vous voter plusieurs fois. J'ai une haine brûlante pour Scrum et je crois que chacun de ses créateurs mérite d'être puni ».
À quoi ça sert? Absolument rien? Pas exactement, pense l'internaute qui répond au pseudonyme mwint :
J'ai développé une vision plus nuancée de Scrum depuis que je travaille en tant qu'entrepreneur pour une entreprise de logiciels de taille moyenne, mais à côté de leurs équipes de développement normales.
J'avais l'habitude de penser que Scrum se résumait à un lot de réunions inutiles, qui enlève la vie et la productivité du processus de développement.
Maintenant, après l'avoir vu d'un point de vue adjacent (mais non soumis à celui-ci), je pense que c'est une série de réunions qui sucent la vie et qui ne servent qu'à une chose : emmener les développeurs qui ne peuvent pas ou ne veulent pas voir l'image d'ensemble de l'entreprise/de l'architecture et en tirer un travail utile.
La plupart d’entre nous ici ne faisons pas partie de cette catégorie. Je parierais que la majorité des lecteurs ne peuvent s’empêcher de chercher à comprendre l’entreprise, où s’inscrit cette pièce, avec quoi elle interagit. Pour nous, tout préciser d’avance ne sert à rien. Estimer des choses est irritant car nous avons besoin de flexibilité pour prendre des décisions intelligentes pendant le développement. Les réunions rétro sont des mensonges car on ne peut pas dire « arrête avec tout ça et laisse-moi travailler ».
Mais si vous essayez de créer un processus qui peut prendre des développeurs juniors (pas juniors en termes de mandat, mais juniors dans les qualités ci-dessus) et produire un résultat qui évolue presque linéairement avec le nombre de développeurs, cela fonctionne en quelque sorte.
Je dirais qu'il est bien préférable d'embaucher 6 développeurs qui peuvent passer d'un problème commercial à une solution technique dans leur tête, sans toute la cérémonie, au lieu de 40 développeurs qui ne peuvent pas et 6 Product Managers pour lancer les débats.
Mais je peux aussi voir comment une entreprise se retrouve là : traverser une année d'embauche difficile, ou même simplement prendre quelques mauvaises décisions d'embauche, et maintenant vous avez des personnes dans l'équipe qui ont besoin d'être accompagnées et supervisées. C’est ça la mêlée ; cela ressemble à de la microgestion parce que c'est le cas. Cela force les développeurs juniors à devenir productifs - peut-être 5 % de ce que vous obtiendriez d'un développeur senior sans Scrum, mais c'est quelque chose de non négatif.
J'avais l'habitude de penser que Scrum se résumait à un lot de réunions inutiles, qui enlève la vie et la productivité du processus de développement.
Maintenant, après l'avoir vu d'un point de vue adjacent (mais non soumis à celui-ci), je pense que c'est une série de réunions qui sucent la vie et qui ne servent qu'à une chose : emmener les développeurs qui ne peuvent pas ou ne veulent pas voir l'image d'ensemble de l'entreprise/de l'architecture et en tirer un travail utile.
La plupart d’entre nous ici ne faisons pas partie de cette catégorie. Je parierais que la majorité des lecteurs ne peuvent s’empêcher de chercher à comprendre l’entreprise, où s’inscrit cette pièce, avec quoi elle interagit. Pour nous, tout préciser d’avance ne sert à rien. Estimer des choses est irritant car nous avons besoin de flexibilité pour prendre des décisions intelligentes pendant le développement. Les réunions rétro sont des mensonges car on ne peut pas dire « arrête avec tout ça et laisse-moi travailler ».
Mais si vous essayez de créer un processus qui peut prendre des développeurs juniors (pas juniors en termes de mandat, mais juniors dans les qualités ci-dessus) et produire un résultat qui évolue presque linéairement avec le nombre de développeurs, cela fonctionne en quelque sorte.
Je dirais qu'il est bien préférable d'embaucher 6 développeurs qui peuvent passer d'un problème commercial à une solution technique dans leur tête, sans toute la cérémonie, au lieu de 40 développeurs qui ne peuvent pas et 6 Product Managers pour lancer les débats.
Mais je peux aussi voir comment une entreprise se retrouve là : traverser une année d'embauche difficile, ou même simplement prendre quelques mauvaises décisions d'embauche, et maintenant vous avez des personnes dans l'équipe qui ont besoin d'être accompagnées et supervisées. C’est ça la mêlée ; cela ressemble à de la microgestion parce que c'est le cas. Cela force les développeurs juniors à devenir productifs - peut-être 5 % de ce que vous obtiendriez d'un développeur senior sans Scrum, mais c'est quelque chose de non négatif.
En le lisant, certains pourraient penser qu'il sous-entend que Scrum est ennuyeux si vous êtes un développeur compétent et expérimenté. C'est en tout cas ce qui ressort des propos de u/Own_Spare_544 :
Pour le contexte, mon parcours est que je suis un scientifique titulaire d'un doctorat qui travaille dans l'analyse de données scientifiques et le développement de logiciels. Je possède à la fois une expertise en la matière dans nos produits ainsi que des compétences techniques en développement de logiciels. J'ai été soudainement placé dans une équipe Scrum lors d'une réorganisation et je travaille dans cet environnement depuis 5 mois. Après la transition Scrum, mon rôle est celui d'un développeur de base travaillant sur le produit.
Cela devient insupportable. Il ne s’agit pas d’un seul problème, mais de la confluence de plusieurs à la fois :
Cela devient insupportable. Il ne s’agit pas d’un seul problème, mais de la confluence de plusieurs à la fois :
- Les tickets sont digérés par le Product Manager et le Scrum Master. Nous n'avons aucune contribution sur ce sur quoi nous travaillons, ni aucun retour sur la façon dont cela est mis en œuvre, créant ainsi un scénario de « cuisinier à la chaîne »/chaîne de montage.
- Nous organisons des standups quotidiens où nous examinons chaque ticket dans JIRA et déplaçons les dates cibles/échéances de +/- 1 jour à la fois et grillons les gens sur leurs progrès. Cela prend 45 minutes à 1 heure par jour.
- Le chef de produit protège les parties prenantes de l'équipe, mais protège également l'équipe des parties prenantes, nous n'avons donc pas de discussions sur la situation dans son ensemble.
- Les tâches sont décomposées en éléments de petite taille, généralement par le PM/SM, de sorte qu'il n'y a pas de véritable entrée sur quoi, quand et comment quelque chose est fait.
- Nous ne sommes pas autorisés à accomplir des tâches qui durent plus d'une journée, ce qui décourage d'essayer de résoudre des problèmes complexes en général.
- Parce que tout est microgéré, aucune tâche n’est réellement nécessaire. Une personne titulaire d'un baccalauréat en informatique pourrait effectuer n'importe laquelle de ces tâches.
- Les tâches de sprint sont modifiées quotidiennement dans ces stand-ups, ce qui perturbe encore davantage ma capacité à réfléchir à quelque chose de profond ou de difficile, ou à diriger moi-même mon travail.
- Les PM/SM ne se soucient pas des considérations techniques car ils ne se soucient que d'ajouter de nouvelles fonctionnalités à un rythme rapide, et aucun d'eux n'a d'expertise en développement logiciel.
- Chaque fois que le travail de l'équipe est démontré, c'est le fait d'une seule personne, donc fondamentalement, aucun membre de l'équipe n'est reconnu par les parties prenantes.
- Nous planifions des sprints de 2 semaines, puis changeons constamment les priorités, y compris le premier jour du sprint.
- En raison de la pression, les membres de l'équipe se battent pour savoir qui pourra clôturer son ticket le plus rapidement.
C'est épuisant de lire des histoires comme celle-ci – des équipes de personnes faisant des choses bizarres et rejetant la faute sur Scrum. … C'est à la mode de blâmer Scrum. [Mais] à moins que chacun des individus assume la responsabilité de l’amélioration de son équipe et de son environnement de travail, ces problèmes persisteront longtemps après que Scrum soit devenu le bouc émissaire à la mode.
Sources : réponses à la publication de Santiago Valdarrama (1, 2)
Et vous ?
Quel analyse faites-vous des propos de ces professionnels ? Quelle est votre expérience personnelle avec Scrum ? Avez-vous rencontré des difficultés ou des bénéfices en utilisant cette méthode ? Quels sont les facteurs qui influencent la réussite ou l’échec d’un projet Scrum ? Quels sont les rôles et les responsabilités des différents acteurs du projet ? Quelles sont les alternatives à Scrum que vous connaissez ou que vous utilisez ? Quels sont leurs avantages et leurs inconvénients par rapport à Scrum ? Comment améliorer la pratique de Scrum dans votre contexte ? Quelles sont les bonnes pratiques ou les pièges à éviter ? 
Envoyé par francoisref
