Temps de lecture estimé : 30 minutes
Article mis à jour en 2024
La méthode Scrum (« Scrum » signifie « Mêlée » en anglais), 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.
L’objectif de cet article est de vous aider à vous lancer dans la mise en oeuvre de Scrum. Il décrit le processus associé, ses étapes, réunions, rôles, etc. Dès que les limites de cet article seront atteintes, la lecture de la dernière version du Guide Scrum (15 pages, gratuit, complet et traduit en français).
Pour une meilleure compréhension de cet article, il est préférable d’avoir assimilé les valeurs et principes agiles. Au besoin, je vous invite à lire l'article d'introduction aux méthodes agiles.
Au sujet de Scrum
Cadre de Travail Vs Méthode Scrum
Pourquoi faut-il considérer Scrum comme un cadre de travail (framework) plutôt qu'une méthode ?
Une méthode vous dit généralement « comment » faire dans bien des situations. C'est ce qui peut rendre une méthode trop lourde à force de vouloir couvrir toutes les situations et contextes possibles.
Scrum ne dit pas comment réussir votre produit, comment résoudre les problèmes rencontrés par votre équipe, comment produire, comment spécifier, etc. Il offre plutôt les moyens de trouver ces réponses en mettant à profit l'expérience vécue (empirisme) et l'intelligence collective de l'équipe.
Il offre un cadre de travail structuré composé de 3 rôles, 5 évènements, 3 piliers, 3 artefacts (supports de travail), 5 valeurs directrices et quelques règles du jeu.
Les avantages de Scrum
Quels sont ses avantages du coup ?
Scrum est simple, léger et peut s'adapter à des contextes qui vont bien au delà du secteur du développement de logiciels à l'origine des méthodes agiles.
Chaque équipe va pouvoir intégrer dans ce cadre de travail, les techniques, outils, pratiques qu'elle juge adaptée à son contexte. Pour les projets de développement de logiciels par exemple, on complète souvent Scrum par les pratiques issues de la méthode eXtreme Programming (XP). XP apporte ainsi les pratiques de programmation en binôme, de développement piloté par les tests (TDD ou Test Driven Development), intégration continue, etc. Ces dernières jouent un rôle capital pour relever le défi du développement incrémental. Le mouvement Software Craftsmanship est également là pour répondre à ces enjeux techniques.
NB : Sachez que eXtreme Programming couvre également efficacement les aspects de gestion de projet, faisant d’elle l’une des méthodes agiles les plus complète qui existe.
Utilisation de Scrum
Processus Scrum (source des icônes des personnages : Mike Cohn)
Pré requis recommandés
- Un grand mur libre et dégagé dans l’espace de travail de l’équipe. Ou un outil de management visuel électronique tel que Trello, JIRA, Miro, etc.
- Blocs de post-it et marqueurs si vous optez pour un management visuel physique.
- L’ouvrage « Scrum et XP depuis les tranchées ».
- Jeu de cartes ou logiciel de Planning Poker.
Les Rôles en bref
Scrum définit seulement 3 rôles :
- Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec les Développeurs. Il s’agit généralement d’un expert du domaine métier du projet.
- Les Développeurs chargés de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables du produit. Le terme "Développeur" est à prendre au sens le plus large (pas nécessairement cantonné au secteur du développement de logiciel). Et les termes "produit" et "fonctionnalité" également (un "produit" peut être aussi bien un logiciel, qu'un produit hardware ou quelque chose de plus abstrait comme un évènement à organiser ou un changement d'organisation à opérer par exemple).
- Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès des Développeurs et toute partie prenantes ayant besoin de comprendre le fonctionnement d'un projet Scrum. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe Scrum est pleinement productive. Généralement le candidat tout trouvé au rôle de Scrum Master est le chef de projet. Celui ci devra cependant renoncer au style de management « commander et contrôler » pour adopter un mode de management participatif.
Pour apprendre à mener à bien un projet agile, découvrez la formation Scrum Master et la formation Product Owner. Éligibles au CPF, France Travail et aux aides destinées aux petites entreprises.
Vision du produit et product backlog
La première étape consiste à formaliser la vision du produit (logiciel) que l’on souhaite réaliser. Quel est l'objectif de ce produit (quel problème doit-il résoudre ?), jalons, utilisateurs visés, etc. Elle contribuera à guider et fédérer les acteurs du projet.
La suite consiste à établir la liste des exigences (ou besoins) que le produit devra couvrir. Chaque exigence est ensuite estimée par les Développeurs avec la technique de Planning Poker (ou d'autres au besoin). À la lueur des estimations, la liste ainsi complétée et ordonnancée. Les exigences seront converties en fonctionnalités utilisables selon cet ordonnancement.
Le principe étant de convertir en premier les exigences qui apportent le plus de valeur ajoutée (ou ROI) au commanditaire. Il s’agit donc de faire remonter les exigences fonctionnelles de la plus haute valeur ajoutée (ou dont le ROI est le plus élevé) en haut de la liste. Cette liste est appelée le Product Backlog. Le Product Backlog servira à piloter les Développeurs et pourra évoluer tout au long du projet. Le changement est non seulement autorisé mais encouragé afin de pouvoir éliminer les idées de départ qui s’avéreront mauvaises et de prendre en compte les nouvelles idées qui arriveront en cours de route. Cette activité de construction du Product Backlog est collaborative, elle implique le Product Owner et les Développeurs.
Et dans le cas d'un appel d'offre ?
Vous répondez à un appel d’offre pour la réalisation du produit de votre client ? Vous ne pouvez pas construire le Product Backlog avec lui ? Dans ce cas, vous pouvez partir du cahier des charges, extraire de ce dernier les exigences, les estimer (idéalement avec 3 Développeurs) et initialiser ainsi le Product Backlog. Vous pouvez également aller plus loin en proposant un premier ordonnancement.
Pondérer chaque exigence d’une valeur ajoutée n’est pas toujours évident pour le Product Owner ou une équipe métier (MOA) novice. Différentes techniques s’offrent à vous. Le fameux Planning Poker (voir paragraphe ci dessous) peut s’avérer utile pour déterminer collectivement les pondérations en « points » de valeur ajoutée. On peut également utiliser des échelles de valeur plus ou moins fine (exemple : « faible », « moyenne », « haute » ou encore les tailles de tee-shirt : XS, S, M, L, XL, XXL).
Estimations des exigences
L’ensemble des fonctionnalités de la liste doivent être estimées par les Développeurs afin de permettre les futurs engagements de cette dernière. Impliquant plusieurs développeurs, le Planning Poker permet de mettre à profit les expériences de chacun et de parvenir rapidement à une estimation optimale et objective. Avant ou pendant les estimations, le Product Owner pourra être sollicité afin de répondre aux questions des Développeurs. A ce stade, le besoin pourra être approfondi, mais sans aller trop loin (il s’agit simplement d’estimer le coût de chaque exigence). La conception détaillée se fera pendant les itérations (sprints).
Démarrage
Vous pouvez commencer par déterminer ensemble (Développeurs et Product Owner) la durée des itérations ou Sprints (4 semaines maximum). Cette durée devra être la même pour l’ensemble des sprints afin de maintenir un rythme régulier propice aux automatismes et pouvoir construire des indicateurs de pilotage simples à utiliser et interpréter.
Un projet démarre généralement par les travaux préparatoires du projet tels que la construction du product backlog et de la vision du produit, initiation des acteurs à Scrum (sur un projet de développement logiciel, on peut étendre à la préparation des environnements, mise en place de l’intégration continue, définition de l’architecture générale du projet, etc.). Inutile de faire durer trop longtemps cette phase, souvenez vous (cf. article d'introduction aux méthodes agiles), l’idée est de se lancer sans élaborer au préalable un plan et une architecture millimétrés qui risqueraient de nous enfermer, de nous frustrer, voire de nous coûter cher à courts et longs termes. L’architecture doit être souple et émerger au fil des sprints.
Disparition de la notion de
"Sprint 0"
Il fut un temps où cette étape préparatoire ou étape de cadrage s'appelait le "Sprint 0" (y compris dans le guide officiel Scrum de l'époque). Etant entendu que ce sprint 0 pouvait avoir une durée différente des sprints "normaux" qui suivent. Malheureusement, beaucoup d'équipes ont trouvé en ce sprint 0 l'opportunité d'en faire une phase de "conception" et retombaient dans le piège de l'approche traditionnelle consistant à tout anticiper. Cette étape n'est absolument pas une phase de conception/planification détaillée. Vous voilà donc averti 😉
Une fois que le Product Backlog est suffisamment complet et ordonnancé, on peut planifier un sprint.
Planification de sprint
Durée maximum (ça peut donc prendre moins de temps si vous êtes bien organisés) : 2 heures par semaine de sprint (autrement dit : 4 heures pour des sprints de 2 semaines).
Le Pourquoi et l'Objectif de Sprint
Au cours de la planification de Sprint, l'équipe Scrum doit déterminer l'objectif du sprint. Autrement dit, la réponse à la question : "Pourquoi ce sprint est important ?". Sachant que cet objectif doit être atteignable par les Développeurs en fonction du temps qui leur est accordé et la composition de l'équipe sur le sprint. Cet objectif de sprint donnera un "focus" à l'équipe sur le Scrum et du sens à son travail.
Le Quoi et le Product Backlog
Il s'agit aussi d'identifier les éléments prioritaires du Product Backlog à réaliser dans le Sprint. Le plus en lien possible avec l'Objectif du Sprint et toujours en fonction de la "capacité à faire" de l'équipe et des Développeurs en particulier.
Les Développeurs identifient donc les éléments qu’ils se sentent capable de convertir en fonctionnalités utilisables d’ici la fin du sprint même si ce n'est pas facile à estimer (heureusement, les sprints sont courts).
Mon conseil : appuyez vous sur une Définition de Prêt.
Le Comment et le Sprint Backlog
Il s'agit également d'établir un plan pour réussir à atteindre l'objectif du sprint et réussir à réaliser l'ensemble des éléments du Product Backlog sélectionnés pour le sprint et déposés dans le Sprint Backlog ou Tableau des Tâches Scrum (cf. illustration ci-dessous d'un exemple de tableau des tâches minimaliste). Aussi appelé kanban, Scrum Board ou management visuel des tâches. Il ne s'agit pas de faire un planning dictant qui fera quoi chaque jour du sprint mais plutôt de passer en revue chaque élément pour réfléchir et discuter de la façon dont on va s'y prendre pour les réaliser. Découper au besoin en tâches les éléments trop gros. Vérifier que c'est bien faisable dans le temps imparti et pourquoi déterminer qui commence par quoi, en binôme ou pas, etc.
Pour ce qui est de savoir qui fera quoi sur les jours suivants, la mêlée quotidienne (abordée plus loin) pourra aider.
Exemple de tableau des tâches Scrum minimaliste
Chacun peut personnaliser les colonnes de son tableau des tâches, ou code couleur des post-it. A titre d’exemple, voici ci-dessous la photo du tableau que nous avons utilisé sur l’un de mes premiers projets en 2008 dont j'ai partagé le retour d'expérience dans cet article.
Les User Stories (une User Story représente une exigence, un besoin, je vous donne une exemple à la fin de cet article) sont les gros post-it larges (rose et orange), les sous tâches des User Stories sont en jaune, on trouve en bleu des tâches imprévues indépendantes. Au dessus du tableau figurent les obstacles courants, un graphique d’avancement appelé burdown chart ainsi qu’un calendrier géant avec les dates clefs et les congés de chacun. Sur la droite on trouve des maquettes d’IHM, des documents métier, etc. Cette réunion de planification est l’occasion de préciser ou rappeler à l’équipe la définition de « terminé » pour une user story ou exigence.
Exemple de définition de « terminé » :
- Testé unitairement
- Documenté
- Testé en intégration
- Revue par un pair
- Tests d’acceptation de la user story passants
Photo d'un tableau des tâches
Sprint (4 semaines max)
Au cours du Sprint, l’équipe se concentre sur l’accomplissement des tâches du Sprint Backlog. En cas de retard (indiqué par le Burndown Chart expliqué plus bas), des exigences ou tâches seront retirées du Sprint Backlog en cours de route en essayant de préserver l’objectif du sprint (pour cela, il est conseillé d’ordonnancer les exigences au sein du sprint). Et inversement, si l’équipe avance plus vite que prévu, des exigences ou tâches y seront ajoutées. En accord avec le Product Owner dans les deux cas.
Les développements se font verticalement et non pas horizontalement par couche. Le but est de développer les fonctionnalités de bout en bout (de la conception aux tests) au fil de l’eau au cours du sprint. Autrement dit d’éviter un mini cycle en V au sein du sprint, voire de se retrouver avec une surcharge d’effort de test en fin de sprint. Les développeurs doivent donc éviter de trop paralléliser les exigences et encore moins les tâches de développement. Pour cela, le travail en binôme (Pair Programming pour le secteur du logiciel) peut se révéler utile ainsi que la définition d’une limite maximum d’éléments au sein d’une colonne du tableau des tâches (voir notion de Work In Progress du Kanban). Si les Développeurs ne sont pas convaincus, le « jeu du prénom en mode multitâche » peut s’avérer utile.
Le tableau des tâches physique rempli de post-it est pratiquement indispensable. Il permet d’avoir une vision claire du travail à accomplir, en cours et terminé. Il est également précieux lors de la mêlée quotidienne (voir § suivant), surtout si vous calculez à la main le « reste à faire » du Sprint afin de tracer le graphique d’avancement (voir plus loin le « Burndown Chart »). Le tableau facilite également l’affectation des tâches par l’équipe en ayant une vision d’ensemble du sprint en un coup d’œil. Inutile de se torturer à planifier à l’avance dans le détail l’activité de chaque développeur sur toute la durée du sprint. Il faut se détacher d’une approche prédictive et des diagrammes de Gantt et renoncer au style de management « commander et contrôler ». Ce sont les développeurs qui « tirent » les tâches et non pas le Scrum Master qui les affecte.
Pendant le sprint, les Développeurs assisteront le Product Owner dans ses activités d’affinage du Product Backlog. Cette assistance peut consister en des ateliers d'analyse de nouveaux besoins, de priorisation, d’estimation ou de découpage d'éléments trop gros. Il faut compter environ 10% de la capacité à faire les Développeurs pour leurs activités.
Mêlée quotidienne ou « stand-up meeting »
Durée maximum : 15 minutes.
Cet évènement qui se fait debout (ça évite de s’éterniser) est très importante. Elle permet quotidiennement aux membres de l’équipe de se synchroniser, de remonter les obstacles rencontrés, de s’entraider, de vérifier l’avancement du sprint. Elle contribue également à faire naître l’esprit d’équipe. A condition bien entendu de ne pas transformer cet évènement de « synchronisation » en réunion de « reporting » vers le Scrum Master.
Voici un exemple de trame de questions que chacun peut adresser à tour de rôle si vous utilisez la mêlée quotidienne pour la première fois (vous pourrez la faire évoluer ensuite) :
- Qu'ai-je fait hier qui a aidé l'équipe à atteindre l'objectif Sprint ?
- Que vais-je faire aujourd'hui pour aider l'équipe à atteindre l'objectif Sprint ?
- Est ce que je vois des obstacles susceptibles de m'empêcher ou d'empêcher l'équipe d'atteindre l'objectif du Sprint ?
Photo d'une mêlée quotidienne
La mêlée quotidienne se déroule à lieu et heure fixes (devant le tableau des tâches physique de préférence) déterminés par les Développeurs. Au début le Scrum Master peut avoir à rappeler qu’il est l’heure de la mêlée et animer cette dernière en évitant notamment l’instruction des problèmes ou obstacles en séance afin de ne pas dépasser les 15 minutes imparties. L’objectif du Scrum Master consiste cependant à viser l’appropriation de la mêlée par les Développeurs.
Les obstacles sont traités en dehors de la mêlée avec uniquement les personnes concernées. Les traiter au plus tôt permet de garder une équipe aussi concentrée et productive que possible au cours du sprint.
Graphique d’avancement (Burndown Chart)
Pour connaître votre avancement, vous allez avoir besoin de tracer le Burndown Chart du sprint en cours. Ce graphique est simple, il s’agit du tracé de la charge de travail restante (par exemple le nombre de tâches ou User Stories restantes) évoluant en fonction du temps. Il suffit de mettre à jour quotidiennement le sprint backlog et ce graphique (lors de chaque mêlée quotidienne par exemple).
Exemple de Burndown Chart de Sprint
Vous pouvez également construire un indicateur d’avancement de Release (version d'un produit faisant l'objet de plusieurs sprints) à mettre à jour en fin de chaque sprint.
Revue de Sprint
Durée maximum : 1 heure par semaine de sprint (autrement dit : 2 heures pour des sprints de 2 semaines).
Fréquence : A la fin de chaque sprint.
L’objectif de la revue de sprint est d’inspecter les éléments terminés au cours du sprint écoulé, faire un point sur l’avancement de la Release et adapter au besoin le plan et le Product Backlog. Les Développeurs présentent généralement ces éléments aux personnes invitées par le Product Owner (des utilisateurs clés ou leurs représentants par exemple).
Les feedbacks obtenus permettent de vérifier qu'on est bien sur la bonne direction. Si au contraire, on constate que l'on fait fausse route, on peut rectifier le tir dès le sprint suivant au besoin, changer de direction (pivoter) ou mettre fin au projet avant d'avoir englouti toutes les ressources prévues pour ce dernier.
Les Développeurs calculent leur vélocité en additionnant les estimation associées aux fonctionnalités terminées. Une fonctionnalité partiellement terminée n'est pas comptée dans la vélocité car une telle fonctionnalité n’est pas utilisable. La vélocité ainsi calculée va permettre de mettre à jour le graphique d’avancement de Release et de vérifier l’avancement de cette dernière. C’est l’occasion de vérifier que le nombre de sprints de la Release demeure réaliste ou non.
La livraison du produit aux utilisateurs à la fin de chaque sprint n’est pas obligatoire.
Photo d'une revue de sprint
Rétrospective de sprint
Durée maximum : 45 minutes par semaine de sprint (autrement dit : 1 heure 30 pour des sprints de 2 semaines).
Fréquence : A la fin de chaque sprint.
Cet évènement a pour but d'optimiser continuellement la performance de l’équipe en mettant les idées de chacun à contribution. Il existe différentes techniques d’animation de rétrospectives. Voir le livre « Agile Retrospective: Making Good Teams Great » pour en savoir plus.
L’une d’elle consiste à identifier et pondérer les éléments positifs (éléments à cultiver ou source de motivation) du sprint écoulé, puis les éléments à améliorer, puis de définir un plan d’action d’amélioration (en commençant par améliorer les éléments dont la pondération est la plus forte). Si les membres de l’équipe sont à l’aise pour s’exprimer, un simple tour de table permet de récolter de la matière. Dans le cas contraire, on peut avoir recours aux post-it physiques ou virtuels (chacun inscrit ses idées dessus pour ensuite les transmettre à l'équipe. Une idée par post-it.). Pour pondérer les éléments, il suffit d’allouer un certain nombre de points (5 par exemple) à chaque membre. Chaque membre peut ventiler ses points à sa guise (exemple : 4 points sur un sujet qu’il considère très important, 1 point sur un autre sujet également important à ses yeux mais quatre fois moins que le premier). Pendant la phase d’inventaire des éléments à améliorer, veillez à ne pas essayer de trouver des solutions avant la phase dédiée au plan d’action d’amélioration. Vous risqueriez de ne pas faire remonter à la surface la majorité des « problèmes ». Ce serait dommage car, j’ai pu constater que parfois, le simple fait d’évoquer un problème sans forcément avoir le temps de trouver une solution entraîne une amélioration au sprint suivant.
Commencer par les points positifs peut être vital lorsque le sprint a été éprouvant. L’équipe aura peut être besoin de se nourrir des éléments positifs avant de s’attaquer aux éléments à améliorer.
Tous les domaines peuvent être abordés en rétrospective : humain, organisationnel, pratiques, processus, outillage, qualité de vie au travail, conflits, interactions avec le acteurs externes à l'équipe. Le compte rendu de la dernière rétrospective, les graphiques d’avancement de sprint et release, les événements du sprint, les feedbacks de la revue de sprint sont autant d’éléments qui alimentent les conversations.
Photo d'une rétrospective de sprint
Projet Scrum et MOA
Il est important de prendre conscience que les méthodes agiles ne considèrent pas à juste titre de séparation MOA MOE contractuelle (typiquement française empruntée au secteur du BTP). Il est donc primordial de s’efforcer de décloisonner au maximum MOA et MOE, ces deux entités doivent collaborer étroitement tout au long du projet. Etant donné que l’on touche ici à des habitudes bien ancrées, ce chapitre explique quel rôle peut jouer la MOA dans un projet Agile.
Le rôle du Business Analyst
Dans le cadre d’une approche Agile, les tâches d’un profil fonctionnel ou Business Analyst peuvent rester les même que dans le cadre d’une approche traditionnelle :
- Participation au reengineering des processus et à la conduite du changement.
- Modélisation des processus métier.
- Participation aux ateliers de conception.
- Rédaction des critères d’acceptation des User Stories (en amont des développements).
- Vérification de la conformité des fonctionnalités (en aval des développements).
Le changement réside dans l’organisation du travail. L’approche séquentielle propice à l’effet tunnel est remplacée par un mode itératif, le travail est donc lissé dans le temps sur toute la durée du projet. De plus, un responsable métier devra jouer le rôle clairement défini de Product Owner.
Rôle du Product Owner
Le Product Owner (ou Directeur/Responsable Produit) est chargé de :
- Construire le Product Backlog.
- Ordonnancer ce dernier.
- Répondre aux questions des Développeurs.
- Valider/Rejeter une fonctionnalité « terminée ».
- Prendre des décisions importantes en temps voulu.
Les Développeurs s’engagent à rester concentrés sur l'objectif de sprint et faire une démonstration à la fin de chaque sprint le produit enrichi de nouvelles fonctionnalités.
A tout moment, le Product Owner peut ajouter, retirer un élément du Product Backlog ou changer les priorités.
La règle d'or : En revanche, il ne peut pas toucher au contenu du Sprint Backlog sauf à l'initiative des Développeurs si ces derniers sont en avance ou en retard sur le Sprint. Sinon ce serait le chaos. Et heureusement pour le Product Owner, les sprints sont courts.
Renfort du Product Owner
Le Scrum Master enseigne au besoin au Product Owner les règles du jeu de Scrum et la maîtrise des techniques associées. En particulier celles qui tournent autour de la gestion de Product Backlog, la planification de releases et l’utilisation des indicateurs de pilotage. Il facilitera également les interactions entre le Product Owner et les Développeurs. Les Développeurs l’aident quant à eux à ordonnancer le Product Backlog en fonction des dépendances, risques et estimation qu’elle révèle. Enfin, une équipe de consultants métier peut l’aider sur :
- Les réponses à apporter aux questions des Développeurs tout au long du projet.
- La prise de décisions.
- La rédaction des critères d’acceptation.
- L’ordonnancement du Product Backlog.
- La fourniture des feedbacks à la fin de chaque sprint.
- D’autres sujets : logistique, conduite du changement, déploiement, etc.
Par ailleurs, il est recommandé de solliciter quelques utilisateurs finaux représentatifs des utilisateurs visés par le produit afin de vérifier pas à pas (à minima en revue de chaque sprint) la bonne couverture de leur besoin.
Les pièges à éviter
Scrum est simple mais difficile
Nous l’avons vu, Scrum est un cadre de gestion de projet qui laisse à d’autres méthodes agile complémentaires, le soin d’apporter les pratiques appropriées. C’est le cas de eXtreme Programming et software craftsmanship.
Sur un projet de développement de logiciel, il est donc primordial de ne pas se contenter d’utiliser Scrum sans s’assurer que les pratiques de développement Agile sont ou seront maîtrisées in fine. Constatant de nombreuses dérives liées à cette erreur courante, les créateurs de Scrum alertent :
« Début 2009, davantage d’organisations utilisaient des processus agiles plutôt que des processus en cascade. Cependant, moins de 50% de celles utilisant Scrum développaient les itérations de façon incrémentale, ce qui est le cœur de Scrum. Un des plus grands défis de l’utilisation de Scrum a toujours été la courbe d’apprentissage des développeurs de l’équipe Scrum. »
Gestion du changement
Selon la culture de votre organisation, Scrum peut être porteur de nombreux changements qui impliquent une véritable gestion du changement Agile.
Formations Scrum & Méthodes Agiles
Développez vos compétences professionnelles avec L'Agiliste et obtenez une certification officielle.
Formations Agiles à distance, certifiantes et financées.
Plusieurs équipes Scrum
Idéalement, pour être efficace, une équipe Scrum ne devrait pas dépasser 10 membres en comptant le Scrum Master et le Product Owner. Si votre projet nécessite plusieurs équipes, évitez dans la mesure du possible de constituer des équipes spécialisées par compétence qui seront trop dépendantes les unes des autres pour convertir à chaque sprint des besoins en fonctionnalités utilisables.
Constituez des équipes pluridisciplinaires capables de développer intégralement une fonctionnalité. Comprenons nous bien, le principe n’est pas que chaque membre d’une équipe dispose de toutes le compétences mais plutôt que toutes les compétences requises soient couvertes par au moins un membre de l’équipe. De cette façon, chaque équipe peut avancer de façon autonome sans dépendre étroitement d’une autre, la coordination est plus simple. Chacune étant spécialisé sur un ou des domaines fonctionnels plutôt que technologiques. L’intégration du travail de l’ensemble des équipes sera également plus facile.
Il y aurait davantage à dire sur l’utilisation de Scrum à grande échelle mais nous dépassons l’objectif de ce guide de démarrage.
Annexes
Caractéristiques d’une User Story
Une fonctionnalité peut être rédigée selon le principe de la « User Story » défini par la méthode Agile eXtreme Programming (XP). Une « User Story » doit respecter autant que possible les critères INVEST :
- Indépendante des autres histoires d’utilisateur (dans la mesure du possible).
- Négociable : elle peut être discutée avec l’équipe chargée de la réalisation du produit, notamment lors de l’estimation.
- Valeur (source de) : elle doit être porteuse d’une valeur pour le client ou l’utilisateur.
- Estimable : elle peut être estimée par l’équipe de réalisation avec un risque d’erreur faible.
- Small (petite) : Sa taille doit être relativement petite afin de faciliter son estimation. Elle doit pouvoir être conçue, développée et testée au sein d’une itération.
- Testable.
Exemple de User Story (simpliste pour l’exemple)
Quid des spécifications ?
La conception fonctionnelle voire technique d’une fonctionnalité se fait au fil de l’eau dans chaque itération. Ce n’est qu’au moment où on s’apprête à l’implémenter qu’on rentre dans les détails du besoin. Cette approche a le mérite de permettre au client d’ajuster ou approfondir son besoin sur les fonctionnalités implémentées plus tard. Elle lui permet aussi (ainsi qu’à l’équipe) de retarder certaines décisions sans risque pour le projet (c’est souvent plus sage quand on manque de visibilité).
La méthode eXtreme Programming considère que les User Stories, les tests associés et le code source constituent les spécifications fonctionnelles du projet. D’autres méthodes vont plutôt préconiser la rédaction de cas d’utilisation avec un niveau de détail variable selon le contexte du projet, les exigences du client et la complexité de la fonctionnalité à spécifier.
Il faut bien comprendre que rédiger des spécifications ultra détaillées n’a de sens que dans une approche traditionnelle. Car dans ce cas de figure, le client ne verra son produit qu’à la fin des développements. Il doit donc avoir une vision précise de ce qu’il aura en fin de projet grâce aux spécifications détaillées. Or l’approche agile apporte au client une visibilité sur le produit dès le début du projet ainsi qu’une possibilité d’ajustement du besoin. On privilégie donc le développement de l’application à une documentation exhaustive, pléthorique et indigeste. Ce qui ne veut surtout pas dire que la documentation est jugée inutile en mode agile. Au contraire, elle est souvent indispensable à la pérennité du produit.
En appliquant ce principe, on assiste généralement à un gain de productivité par rapport à une approche traditionnelle, puisqu’on ne perd pas un temps considérable en rédaction, validation puis mises à jour de spécifications détaillées. Il est sans doute bon de préciser également que l’on ne néglige pas la conception du produit pour autant. La conception fait partie des tâches sous-jacentes à la réalisation d’une fonctionnalité.
Vous souhaitez aller plus loin ?
Vous pouvez poursuivre votre apprentissage en consultant la page des ressources clés.
Et vous pouvez faire le choix d’être formé par nos soins. Découvrez nos parcours de formation sur cette page et prenez un RDV téléphonique avec nous pour en discuter ensemble.
j’ai trouvé cela intéressant
Un article intéressant et aborde presque toutes les phases d’un projet dès son démarrage.
Cependant, à plusieurs reprises, on sent une nostalgie du cycle en V. Par exemple le découpage des « exigences » en sous tâches (User-Stories) style ‘IHM’ et ‘service métier’ se rapproche plus du cycle en V que de l’agile.
Ce découpage n’est as I.N.V.E.ST. En effet, la couche IHM toute seule sans service ne peut avoir de la valeur pour le PO ni le métier.
Bonjour Radhouane et merci pour ton observation.
En réalité, dans cet article, je précise bien qu’une exigence est considérée comme synonyme de User Story. Or le découpage INVEST s’applique aux User Stories en soi comme tu le précises bien. Donc aux exigences en soi. Et non pas à leurs sous-tâches.
Amicalement
Florent
Bonjour Florent,
merci pour cette belle et claire introduction au principe Scrum.
A la recherche de nouvelles méthodologies pour bousculer les habitudes et surtout apprendre à être plus efficace dans le développement des projets de mes équipes, j’espère pouvoir en tirer partie, je crois beaucoup en cette façon de faire.
Reste à voir si ceci s’applique aussi bien pour la R&D de l’industrie !
Au plaisir de vous lire de nouveau.
Marc.
Bonjour Marc et merci pour ce retour.
Scrum a l’énorme avantage de n’être qu’un cadre méthodologique, et léger avec ça (le guide officiel Scrum ne fait que 19 pages). Il est donc applicable et appliqué à d’autres domaines que celui de l’informatique et des projets de développement logiciel.
Bonnes expérimentations à toi
Florent
Merci pour ce résumé très clair, cela m’a permis de me rafraîchir la mémoire après avoir passé 5 années à faire du « scrum » tellement arrangé que cela n’en n’avait plus que le nom.
Un très bon article, qui permet de dépoussiérer les fondamentaux quelques peu érodés avec le temps. Merci 🙂
Mais comme à chaque article/livre que je lis sur SCRUM, je manque d’info et/ou de retour sur la façon de le mettre en œuvre dans un contexte mono-équipe et multi-clients (multi-projet). Je suis pourtant sûr de ne pas être le seul dans ce cas là :p
Actuellement mes problématiques se concentrent autour de la mise en place d’un cadre de contractualisation convenable avec un client qui ne maîtrise pas du tout SCRUM.
Comment contractualiser une prestation SCRUM sans mettre la liste des fonctionnalités attendus sur un devis traditionnel.
Ou bien, comment « faire passer la pilule » et insuffler la confiance pour mettre en place une facturation au sprint ?
Auriez-vous quelques références sur ce sujet ? Existe-t-il un SPOC qui aborde cette thématique ?
Bonne continuation et au plaisir d’échanger avec vous 🙂
Bonjour Bérenger et merci pour vos compliments sur l’article 😉
Je vois 2 questions : « comment utiliser Scrum avec une seule équipe gérant plusieurs projets » et « comment contractualiser un projet agile dans le cadre d’une relation Client/Fournisseur ».
Pour la première, la réponse la plus sage (et la plus facile, il faut bien le dire :-)), en tant que coach agile est « tout dépend du contexte ». Ce qui est sûr c’est qu’il faut voir Scrum pour ce qu’il est : un simple cadre méthodologique et non une méthode. A chacun d’y insérer les bonnes pratiques, outils, processus qui correspondent au contexte. Cependant dans le cas d’une équipe multi projets (de moins de 10 personnes), j’ai tendance à plutôt utiliser la méthode Kanban. Egalement pas mal adaptée à du « RUN » (maintenance d’applications). Ce n’est qu’une piste à soumettre à votre sens critique selon votre contexte.
Pour la seconde question, les solutions de contractualisation agile ne manquent pas. On peut par exemple forfaitiser un Sprint 0 de cadrage, voire même les 2 ou 3 suivants pour étalonner la vélocité puis s’engager au forfait pour la suite (sur un volume de Story Points par exemple avec un simple principe de troc pour l’ouverture aux changements, la souplesse qu’un client peut légitimement attendre d’une démarche agile).
J’aborde la notion de troc dans mes formations. Dans le format SPOC, ça fait partie des sujets pouvant être approfondis au cours des sessions live hebdo ou discussions partagées sur le forum de la formation.
J’espère que cette réponse vous sera utile.
Amicalement,
Florent
Bonjour,
Merci pour ce très bon article pour la découverte de cette méthode.
Nous avons adopté l’agilité depuis peu dans l’équipe et je dois avouer que cela a rapidement créé une bonne dynamique de groupe et une « compréhension » entre les différents intervenants (graphique, design, équipe de développement ET le client) a naturellement pris place dans nos réunions.
Quid du client difficile justement : celui qui ne teste pas, qui ne communique pas (hormis quelques « rien ne marche »), qui revient toujours sur ces décisions, celui qu’on pensait être agile et qui ne l’est pas du tout ?
Amicalement,
Michael
Bonjour Michael,
Merci pour les feedbacks à propos de l’article 😉
Et ravi de voir que l’agilité porte déjà ses fruits dans ton équipe.
D’abord, il faut bien se dire que toutes les conditions idéales de mise en oeuvre de l’agilité sont rarement réunies. L’implication du Client et son appropriation du rôle de Product Owner (aussi bien l’état d’esprit que les pratiques) est souvent un point d’achoppement. D’où la posture de Coach du Scrum Master pour former et accompagner la personne côté client qui incarnera le rôle de Product Owner. La personne devra comprendre ce que ce rôle peut lui apporter aussi bien que les responsabilités associées. D’où l’importance d’avoir un bon Scrum Master, bien formé, avec les bonnes qualités en terme de pédagogie, patience & détermination et communication. Si ces efforts ne payent pas, il reste le recours à un coach agile pour poser le cadre et les règles du jeu, avec un accompagnement sur 3 sprints minimum (c’est ma recommandation en tout cas). Enfin, dernier recours si ça n’a pas déjà été fait avant (c’est mieux de le prévoir avant) : le sponsor. Une personne suffisamment haut placée pour dire : ok l’agilité peut nous apporter des bénéfices absolument indispensables à la réussite de nos projets, donc on se forme et on joue le jeu avec mon soutien : le droit à l’erreur (nécessaire pour tout changement de façon de travailler et pour l’amélioration continue) et si nécessaire un budget formation & coaching agile.
Est ce que ça répond à ta question Michael ?
Amicalement,
Florent
Bonjour,
Très intéressant et très didactique. Je me permettrait juste une petite remarque (dans un but d’échanger et non de critiquer bien entendu). Vous parlez de ROI au début lorsque vous abordez le classement des fonctionnalités, vous expliquez que l’on classe les fonctionnalités pour avoir le ROI le plus important pour le client. Hors, pour moi le plus important pour le client c’est la business value. Le ROI n’est que le résultat du calcul entre la BV et l’effort et qui permettra une priorisation des fonctionnalités dans le sprint. Je sais j’ergote mais le sujet est intéressant. ;o)
Félicitation encore une fois pour ce très bon article
Bonjour,
Excellent article : clarté, pédagogie ! En novice, j’ai passé la nuit et la matinée à lire et à relire…
Merci pour la générosité de partage et félicitations pour votre brillant parcours.
Bonsoir M. Florent Lothon,
J’ai suivais aujourd’hui un cours sur agile scrum, j’avoue que votre article est vraiment pertinent.
Vous avez résumé les milliers de slides qui m’ont totalement endormi en formation.
Franchement félicitations.
merci
Merci Alpha 😉
Excellent article. Super didactique autant par son contenu que par les commentaires. Merci!
Merci Clémence 😉
Je suis ravi d’apprendre qu’il t’a été utile.
Article très intéressant.
Juste une réserve sur la Doc, vous semblez oublier des « Personnas » dans les user stories des Documents de spécification de besoins et techniques :
– L’infogérance des solutions
– Les acteurs de contrat de TMA
Merci pour votre message Jules.
En fait j’aborde plus en détail le sujet des spécifications dans cet article.
Que répondre à un développeur qui prétend que le chiffrage en j/h d’un projet est illusoire, car la méthode SCRUM suppose une adaptation au fil de l’eau et donc potentiellement un réajustement de la charge également au fil de l’eau ?
Merci
En effet, sur un projet Scrum on estime (on ne chiffre pas) en unités d’oeuvre appelés des « Story Points » (ou points tout courts). Les j/h ont tendance à entretenir l’illusion qu’une estimation peut être fiable. Hors une estimation reste une estimation (fausse par définition). Ce qui n’empêche pas de s’engager sur un budget, un délai, un volume de points, la qualité et d’être aussi précis que possible grâce à l’intelligence collective mise à profit lors des séances d’estimation (avec la technique du Planning Poker).
Et au bout de plusieurs itérations, l’équipe sait concrètement quelle quantité de points elle peut embarquer en moyenne à chaque itération/sprint. Là les projections deviennent bien plus fiables qu’avec de savants calculs théoriques. Autre avantage pour le « client », les estimations données sont faites sur chaque élément individuellement, en toute transparence et en collaboration avec lui. Autrement dit, en découvrant une première estimation, il a l’opportunité de simplifier son besoin pour la faire baisser avant même d’engager les travaux en conception détaillée puis réal, test, etc.
Bien sûr il faudrait aller plus loin dans l’explication et je pourrais notamment parler de la façon dont j’ai pu engager des projets agiles dans le cadre de contrats au forfait avec succès. Mais ce n’est pas vraiment le lieu.
Bonjour, merci pour votre article qui permet de comprendre simplement les concepts clés.
Pour autant, j’aimerai avoir votre point de vue sur une notion qui reste compliquée car il y a de nombreux avis contradictoire.
Bien que relisant votre article, j’ai un avis tranché sur la réponse mais je me permets de vous poser ces questions avec un contexte en préambule :
– Il s’agit d’un produit informatique (en mode agil, quelle différence pour un cycle en v) orienté relation client qui sera verticalisé avec des maj régulières
– D’après vous, qui a la charge de faire respecter la philosophie du produit tout au long de son cycle de vie ? Des solutions possibles le PO, l’architecte fonctionnel, le MAO, le chef de projet, les développeurs, le commerce ou autres
– Quel est le RACI que vous préconisez avec les fonctions suivantes : Avant-vente, PO, l’architecte fonctionnel, Scrum Master, le MAO, le chef de projet, les développeurs, le commerce ou autres
Je reste à votre disposition,
cordialement
Bonjour Pitchs 🙂
Celui qui a la charge de gérer et partager la vision produit/utilisateur est le Product Owner. Ce qui ne signifie pas qu’il est seul pour autant. Il peut être influencé par la direction de l’entreprise et la stratégie de cette dernière, les éventuels sponsors, les utilisateurs bien sûr et l’équipe de développement. Mais ça reste sa responsabilité opérationnelle.
Le RACI pour autant de rôles (si RACI il y a besoin) sera à définir en fonction du contexte, il n’y a pas de réponse unique.
Pour les rôles définis par Scrum en revanche, c’est très clair et en résumé ça donne à peu près ça :
– Product Owner responsable du « quoi » et de l’ordre dans lequel on fait les choses
– Scrum Master responsable de la bonne compréhension et respect du cadre méthodologique Scrum (ce n’est ni un secrétaire comme je l’entends parfois ni un coordinateur)
– Equipe de dev responsable de la réalisation du produit et de comment on le réalise
Je réponds quand même sur le rôle « sensible » de chef de projet : ce rôle au sens strict perd alors de son sens puisque ce n’est pas lui qui est chargé du comment, du quoi, de l’ordre, ni de la planification. Il ne contrôle plus non plus les tâches ni leur estimation. Généralement (et ce fut mon cas), le chef de projet bascule dans le rôle de Scrum Master et garde une casquette de chef de projet à l’extérieur de l’équipe (exemple : pour le reporting budgétaire, le staffing, etc).
Est-ce que ça répond à la question ?
Le manifeste agile dit :
« Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan »
Hors SCRUM met en oeuvre des processus et des outils, et un plan (au sens large).
Peut-on alors continuer à dire que SCRUM est une méthode Agile ?
Merci pour votre message Guillaume.
D’une part les créateurs de Scrum font parti des rédacteurs et des signataires du manifeste agile. D’autre part, à la première lecture trop rapide de ce manifeste, on a malheureusement tendance à voir les choses en noir et blanc en oubliant les nuances de gris ou autres couleurs. Le manifeste agile ne s’arrête pas là, il dit aussi « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. » Cette précision est essentielle à une bonne compréhension de l’état d’esprit agile. Enfin, Scrum est processus (plus exactement, c’est un cadre) qui est « inclusif » et non pas « prescriptif ». Ainsi, il permet de s’adapter au contexte projet de chacun et laisse la place aux pratiques, techniques et outils que l’équipe projet décidera d’adopter au sein de ce cadre.
Article intéressant et très complet. Pour ma part je suis convaincu par la méthodologie. Avec l’explosion du télétravail, j’ai voulu apporter ma pierre sur la partie qui me pose problème en distanciel, le planning poker. je partage maintenant cet outil. un planning poker en ligne simple et sans inscription. voici le lien https://planningpoker.fr j’esperes qu’il vous plaira pour ceux que ça concernera.
Bonjour
merci pour cette page. Une des grandes questions qu'on me pose souvent est comment gérer les bugs lors de la revue de sprint?
je parle de VRAIS bugs techniques de la part des devs.
En principe selon la méthode, ils donnent lieu à de nouvelles tâches sans user points pour le sprint suivant.
Mais la grande question est la FACTURATION: comment faire comprendre au client qu'au sprint suivant il payera x % pour corriger des bugs qu'on a fait.
merci pour vos réponses
Cyril
Bonjour Cyril,
Tout d’abord, une bonne équipe agile limite considérablement les bugs grâce aux pratiques d’eXtreme Programming (pilotage des développements par les tests, intégration continue / tests automatisés, pair programming, etc). Par ailleurs, un processus agile permet de détecter ces défauts au plus tôt et on sait bien que plus un défaut est détecté tard (lors de la phase de recette en approche classique par exemple) plus il coûte cher.
D’autre part, tout dépend de la contractualisation. J’imagine qu’on parle d’un engagement au « forfait » (délai, budget, volume d’unités d’oeuvre) ? Sur un projet classique, on prévoit toujours (par abaque généralement) une provision pour la résolution de bugs/support de recette. Rien n’interdit de procéder de la même façon lors de la détermination du budget.
En espérant être clair,
Florent
Merci Florent pour cette réponse très intéressante car elle ouvre plusieurs pistes de réflexions:
1- l'eXterme Programming n'est que rarement mis en place en tous cas dans sa totalité. On est souvent amené à faire de l'agile avec une équipe de devs réduite (2 personnes ). donc les bugs arrivent 🙁
2- en quoi un processus agile permet de détecter plus tôt les bugs ? La méthode permet surement de mieux définir ce qui a le plus de valeur pour le client et en réduisant les risques de 'surprise' pendant le dev mais encore une fois… les bugs arrivent
3- non, je ne parle pas de forfait (qui est contraire à l'idée d'agile) mais de véritable contractualisation où le client paye au réel (temps passé). Dans ce cas, comment faire comprendre au client qu'au sprint suivant il payera x % pour corriger des bugs qu'on a fait au sprint précédent.
merci pour vos réponses
Cyril
De rien Cyril 😉
1 – En effet, d’où pas mal d’écueils hélas (être 2 pour pratiquer l’essentiel d’XP ou équivalent est plutôt un atout qu’un handicap d’après mon expérience, idem pour limiter les bugs)
2 – L’effet tunnel est considérablement réduit (principalement – mais pas seulement – par la durée/fréquence des itérations : 4 semaines max Versus X mois d’une phase de réalisation en Cycle en V sans compter la phase de conception)
3 – L’engagement sur un délai, un budget, qualité et un volume d’unités d’oeuvre n’est pas du tout contraire à l’agilité fort heureusement. C’est même la majorité des projets que j’ai pu mener (en m’appuyant d’ailleurs sur des mécanismes simples prévus par les créateurs de Scrum en personne).
C’est typiquement le genre de questions que nous abordons en détail en formation.
Par écrit, c’est toujours plus compliqué de se comprendre et d’apporter une réponse précise, complète et adaptée au contexte.
Amicalement,
Florent
oui merci
mais au final dans un sprint vous vous engagez sur un livrable et que se passe t il avec les bugs memes réduits ??
le prestataire doit il les corriger et donc passer du temps non facturé avant de commencer un nouveau sprint ou ce temps de debut est il compris dans le sprint suivant (qui sera facturé) ?
Bonjour Cyril,
C’est au Product Owner de décider si un bug doit être corrigé et à quel moment, au même titre que les autres éléments du Product Backlog.
En termes de facturation, en régie le client peut arrêter la prestation à tout moment si il en marre de « payer » pour des bugs. Si le volume de bugs est tel que la confiance commence à se déliter, on en revient aux bonnes pratiques évoquées au début. Ce qui fera un bon sujet de discussion en rétrospective en s’assurant que le Product Owner est bien présent. Evidemment, c’est une réponse générale à adapter en fonction du contexte.