C'est quoi Scrum ?

Introduction

Salut, je m'appelle Luc et je suis cofondateur de Scrumline. Je travaille également comme consultant et développeur chez Mind7 Consulting. Au fil de mes expériences, je constate régulièrement la réticence de nombreux développeurs à s'engager dans Scrum. Pourquoi cette réticence ? Qu'est-ce que Scrum offre vraiment ?

Alors, c'est quoi Scrum ?

Une perception erronée :

Ce cadre de travail est parfois perçu par certains développeurs comme étant exclusivement réservé au management. Ils ne se sentent pas concernés et montrent peu d'intérêt pour Scrum, peut-être parce qu'ils ne comprennent pas totalement les avantages qu'il peut apporter à leur activité quotidienne. Souvent, ils voient Scrum comme une série de restrictions plutôt que comme un ensemble de pratiques destinées à améliorer l'efficacité et la qualité de leur travail. Cette perception négative peut découler d'expériences antérieures où Scrum a été mis en place de manière inefficace, transformant les réunions en simples formalités au lieu d'occasions de collaboration productive et d'ajustement stratégique.

Micromanagement ou Autonomie :

Voici l'idée reçue : Scrum serait là pour organiser le projet et vérifier que le travail est fait, flirtant avec le micromanagement.

Cependant, cette vision du micromanagement est une interprétation erronée. Scrum est en réalité une approche qui vise à encourager la collaboration et l'auto-organisation au sein des équipes. Il est conçu pour donner aux développeurs la liberté de déterminer comment ils vont réaliser leur travail, tout en assurant une transparence totale sur l'avancement du projet.

L'objectif de Scrum n'est pas de contrôler, mais plutôt de permettre à chacun de contribuer à son meilleur niveau, dans un environnement propice à mettre en avant la responsabilité collective et l'adaptabilité face aux changements.

Le produit et sa valeur

Maximiser la création de valeur :

Scrum incarne avant tout une philosophie. Dans cet article, j'ai choisi de ne pas m'éterniser sur la description des principes qui font Scrum, tels que ses piliers, ses rôles, ses valeurs, ses artefacts et cérémonies. Pour une introduction complète à ces concepts, je vous recommande notre vidéo d'initiation. Je préfère me concentrer ici sur l'aspect le plus essentiel de Scrum : le produit.  Scrum se consacre à la création de valeur, à l'élaboration d'un produit, souvent complexe à réaliser, qui satisfait pleinement les exigences des utilisateurs. Cette démarche nécessite une compréhension approfondie de leurs besoins et une agilité pour s'adapter aux retours et aux changements du marché.

Alors, que constitue véritablement un produit ? C'est un ensemble cohérent de fonctionnalités, conçu pour apporter une valeur continue et évolutive aux utilisateurs, avec un cycle de vie qui s’étend au-delà d’un budget et d’un calendrier annuels. Un produit se distingue par son impact et son utilité à long terme ainsi que l'harmonie de son développement orchestré par la synergie des différentes personnes impliquées.

Différence entre Projet et Produit :

Pour un projet, la réussite peut se mesurer par le respect du budget et la livraison en temps et en heure des fonctionnalités prévues. Mais pour un produit, la vraie réussite n'est-elle pas plutôt reflétée par son adoption par les utilisateurs et sa capacité à s'adapter et à prospérer dans un marché en constante évolution ?

Est il vraiment possible de parler de la réussite d'un projet si le produit final ne tient pas la route ? Des fonctionnalités livrées à temps à tout prix, ont-elles compromis la qualité globale ? À court terme, la qualité logicielle ne saute pas toujours aux yeux, mais elle se révèle essentielle à la durabilité du produit, à sa maintenance et à une expérience utilisateur optimale, sur le long terme.

Scrum transforme le paradigme traditionnel de gestion de projet : Les coûts et les délais restent fixes car le projet est divisé en sprints de durée déterminée et c'est le périmètre du produit qui est variable :

Cela permet d'établir un environnement où le développement d'un produit peut s'adapter et évoluer, visant toujours à apporter la plus grande valeur possible aux utilisateurs. Ce cadre permet d'ajuster le périmètre, garantissant ainsi que chaque étape de la réalisation se focalise sur la maximisation de la valeur apportée.

Faire danser l'hippopotame

J'aime beaucoup cette allégorie trouvée dans Culture DevOps de Octo :

"La culture, c'est comme un hippo qu'on essaie de faire bouger. Dire à l'hippo de bouger ne nous amènera nulle part. Pousser l'hippo ne sera pas bon non plus, l'animal est bien trop lourd. Jouer un rythme entraînant en revanche, avec des percussions brésiliennes, et vous verrez le pachyderme commencer à danser. Le rythme est essentiel afin de transformer une culture." 

https://publication.octo.com/en/download-whitepaper-culture-devops-vol-1

Scrum incarne parfaitement cette notion de rythme nécessaire à la transformation de l'environnement. Il offre un cadre structuré mais flexible, rythmant les journées, les semaines et les mois. Ce cadre permet à l'équipe de s'organiser, d'optimiser son temps, de libérer sa créativité, de prendre des responsabilités et de développer le courage nécessaire à la création d'un bon produit.

Mais pourquoi le courage est-il si crucial ? Si je reprends l'image de l'hippopotame, ne vous faudrait il pas bien du courage pour le faire danser ? Développer un bon produit va au-delà de la simple programmation, il va falloir interagir avec des parties prenantes souvent exigeantes, naviguer dans des contraintes réglementaires et techniques complexes, et parfois remettre en question les normes établies.

Comme dans l'exemple de l'hippopotame, il faut oser jouer une musique différente pour susciter un mouvement inhabituel, surtout dans un environnement culturel résistant au changement. Ainsi, cela demande non seulement de la compétence technique, mais aussi une capacité à gérer l'incertitude et à motiver toute une équipe à poursuivre une vision commune, même lorsque le chemin paraît difficile ou incertain.

Le Daily Scrum

C'est vrai, j'avais précédemment indiqué que je ne m'attarderais pas sur les différentes cérémonies de Scrum, puisque ce n'était pas le sujet central de cet article. Mais au fur et à mesure de la rédaction de cet article, j'ai réalisé qu'il était indispensable de discuter de cette cérémonie en particulier. Alors, pour que vous ayez une vision claire de ce qu'est un daily Scrum, je vous propose un exemple concret de mise en situation :

Si vous n'avez pas immédiatement identifié cette réunion comme un exemple de mauvaise pratique en Scrum, c'est une occasion d'apprendre l'importance de l'application correcte de ses principes. Si vous avez reconnu les erreurs, vous savez que de telles pratiques sont malheureusement trop courantes.

Erreurs clés :

1. Manque d'autonomie : L'équipe de développement attend des leaders pour démarrer, démontrant une dépendance qui va à l'encontre de l'autonomie encouragée par Scrum.
2. Rôle mal interprété : Le Scrum Master devrait encourager l'initiative de l'équipe de développement plutôt que d'attendre passivement le PO, compromettant ainsi son rôle de facilitateur du processus Scrum.
3. Interruption du flow du sprint : Le Product Owner introduit de nouvelles priorités de manière unilatérale, perturbant le sprint en cours.
4. Absence de véritable synchronisation : Les développeurs se limitent à des reportings individuels sans interaction ni coordination, alors que le Daily Scrum devrait servir à synchroniser les efforts vers un objectif commun (le Sprint Goal).
5. Mauvaise priorisation : Le Scrum Master met un point d'honneur à respecter la timebox sans considérer la qualité et l'efficacité de la communication durant le Daily Scrum.

Importance de l'Application Correcte de Scrum :

II est essentiel de saisir pleinement cet exemple pour éviter de pratiquer Scrum simplement par routine, mais plutôt adopter une approche plus significative, permettant à des produits exceptionnels d'émerger d'une équipe motivée et engagée. Les développeurs jouent un rôle clé dans ce changement de paradigme, car en tant qu'acteurs principaux du produit, ils doivent embrasser cette mentalité pour contribuer efficacement à la réussite du produit. Le Scrum Master joue également un rôle déterminant, surtout si l'équipe est encore novice en agilité, en les guidant vers cet idéal d'excellence.

Conclusion :

Je conclurai cet article en affirmant que l'utilisateur final se soucie peu de savoir si le produit a été développé selon la méthode Scrum ou en cycle en V. Ce qui importe, c'est que le produit soit fonctionnel et réponde à ses besoins. Respecter scrupuleusement les règles de Scrum est inutile si le résultat final n'est pas satisfaisant. L'essentiel est de trouver ce qui fonctionne le mieux pour l'équipe et le projet. Cela dit, je suis convaincu de l'efficacité de Scrum : j'apprécie sa simplicité, son empirisme, son pragmatisme, et les opportunités qu'il offre. Pour moi, l'essayer (vraiment), c'est l'adopter. Également, mettre en place un Scrum authentique et donner de la vraie autonomie aux développeurs ne pourra que les convaincre de son adoption.

Si vous avez aimé cet article et vous voulez en savoir plus, je vous recommande notre entraînement sur la plateforme, il permettra de vous mettre en situation et d'apprendre à utiliser efficacement Scrum !