Après avoir décortiqué la composition d’une équipe Scrum dans l’article « Équipe Scrum : comment est-elle composée ? », on fait le point sur l’organisation de cette team Agile et sur l’articulation de son framework à toute épreuve.
Avis à celles et ceux qui évoquent une méthode pour dépeindre Scrum, le terme consacré correspondrait plutôt à framework (cadre de travail). La différence ? Tandis que la méthode fige quelque peu le scénario de la gestion de projet, le framework laisse libre cours à l’improvisation. À l’instar d’une équipe de rugby, Scrum (mêlée en anglais) puise ses ressources directement sur le terrain en privilégiant l’apprentissage par l’expérience.
Voici les points que nous allons aborder dans cet article :
Qu’est-ce que le Framework Scrum ?
Quel est le socle des valeurs Scrum ?
Quelles sont les 5 valeurs Scrum ?
Framework Scrum : les éléments clefs
Agile et empirique, Scrum n’en est pas moins bordé de repères. Parmi ces jalons, trois piliers confortent la puissance de ce cadre de gestion de projet :
🔸 Les rôles : ils sont scrupuleusement répartis au sein de l’équipe entre le Scrum Master, le Product Owner et l’équipe de développement.
🔸 Les événements : Sprint, Sprint planning, Daily Scrum, Sprint review et Sprint retrospective sont tous time boxés (limités dans le temps) pour plus d’efficacité.
🔸 Les artefacts* : un framework Scrum se ventile en quatre artefacts (product backlog, sprint backlog, incrément, definition of done). Il s’agit de listes collaboratives permettant le partage d’informations de base entre les différents acteurs qui interviennent dans le cadre du projet.
*Issu du latin artis facta (effets de l’art), un artefact est un « phénomène d’origine humaine, artificielle, intervenant dans l’étude de faits naturels » – Définition issue du dictionnaire Le Robert.
Le socle de valeurs de l’édifice Scrum
A l’opposé d’une recette toute faite, Scrum joue la chorégraphie des petits pas et de l’itération. Si le framework pose des principes qui guident la team, nulle formule prédéterminée ne permet d’atteindre l’objectif. C’est là que le rôle du Scrum Master s’avère crucial dans la prise de décision et de réorientation du projet au fil de l’eau. Ce pro de l’impro redistribue les cartes à chaque étape avec en ligne de mire une logique d’amélioration continue. En soutien du framework, on retrouve les trois piliers phares que sont la transparence, l’inspection et l’adaptation :
🔸 La transparence : qui dit Scrum dit limpidité de l’information partagée entre chaque acteur engagé dans le projet. C’est là la condition sine qua non de l’inspection.
🔸 L’inspection : elle vise l’analyse des résultats des travaux de la team et s’appuie largement sur la transparence des échanges autour du projet. Sans inspection, pas d’adaptation.
🔸 L’adaptation : faisant suite à l’analyse, ce volet en exploite les résultats pour améliorer tous
les pans de la collaboration autour du projet.
Scrum : les 5 valeurs à respecter
Pour garantir un fonctionnement harmonieux au sein d’une équipe composée – ne l’oublions pas – d’humains, cinq valeurs évitent certains écueils liés à l’organisation de la production :
🔸 Focus : on retrouve ici la notion d’efficacité portée par la capacité à aller à l’essentiel,
🔸 Ouverture (Openess) : l’ouverture au changement fait partie de l’état d’esprit de chacun, à l’instar de l’ouverture aux idées alternatives que l’on sait accueillir avec bienveillance,
🔸 Respect : ingrédient incontournable pour un fonctionnement harmonieux en équipe, le respect porte aussi bien sur autrui que sur les engagements pris et les attentes des utilisateurs,
🔸 Courage : revenir sur ce qui a été fait et s’adapter en permanence demande du courage, tout comme faire preuve de transparence,
🔸 Engagement (Commitment) : quoi qu’il arrive, Scrum engage à faire de son mieux et ce, quels que soient les aléas du projet.
Les 5 événements clés d’une équipe Scrum
Au programme de cette trame Agile, cinq événements clés scandent chaque projet mené en mode Scrum. Leur credo : produire plus, vite et mieux grâce à des durées optimisées et à des successions de phases prédéfinies.
Sprint : le tempo du projet
⏰ Entre 1 à 4 semaines
Il bat le rythme à la façon d’un cœur qui impulserait la cadence souhaitée. Un sprint Agile renvoie à une phase séquentielle de développement d’un produit. Véritable itération de courte durée (un sprint dure entre une et quatre semaines), il décompose un processus de développement pour le simplifier et le customiser en fonction des résultats obtenus à chaque étape. Dans le cadre d’un projet, les sprints s’enchaînent sans temps de pause entre chaque et se ventilent selon le schéma suivant :
🔸 Le Product Owner définit le travail à réaliser,
🔸 Les développeurs réalisent ce travail,
🔸 Le Scrum Master s’assure du fonctionnement optimal de la team.
Cas particulier : en cas d’obsolescence du produit en cours de développement pour cause de lancement d’une solution concurrente, le Product Owner peut annuler le sprint et en lancer un nouveau. Sa mission : mettre sur les rails une variante à valeur ajoutée (la plus en phase avec les attentes du marché) et ce, le plus rapidement possible.
Sprint planning : la ventilation des tâches
⏰ 8h ou moins – Pour un sprint d’un mois, on est sur 8h. Pour un sprint de 2 semaine, plutôt 4h.
Ce travail de planification vise à organiser la mission qui se déroulera durant chaque sprint. Tandis qu’un sprint d’un mois nécessite en moyenne un sprint planning de huit heures réunissant toute l’équipe, quatre heures suffisent à planifier un sprint de deux semaines. Un sprint planning tourne autour de trois sujets :
🔸 Le pourquoi : autrement dit le sprint goal, la mission,
🔸 Le quoi faire : quels items seront planifiés dans le sprint,
🔸 Le comment faire : quelles tâches techniques les éléments précédents impliquent-ils ?
Contrairement aux tâches techniques dont l’évolutivité s’avère nécessaire tout au long du développement, le sprint goal ne change jamais.
📌 À noter : la definition of done renseigne les développeurs quant à la charge de travail que chacun est en mesure de s’attribuer dans le cadre d’un sprint.
ADAPTEZ LES RITUELS AGILES À DISTANCE
Daily Scrum : développeurs only
⏰ 15 minutes maximum
Même heure, même endroit, tel est le leitmotiv des développeurs qui se réunissent une fois par jour pour quinze minutes au maximum. L’objet du Daily Scrum ? Établir un point d’avancement sur le travail réalisé et le travail restant à effectuer. Plus visuelle, l’utilisation d’un tableau aide à présenter la progression des items et des tâches. Chaque développeur s’exprime alors au sujet de ses actions à venir, en cours et des éventuels obstacles rencontrés dans l’atteinte du sprint goal. Côté formalité, c’est la libre expression qui est de mise avec l’inexistence de préconisations Scrum sur les prises de paroles.
Sprint review : en conclusion de chaque sprint
⏰ 4h ou moins
Comme son nom l’indique, le sprint review passe en revue les éléments marquants à chaque fin de sprint. Testing des nouvelles fonctionnalités par les utilisateurs et présentation des incréments apportés au produit en cours d’élaboration font ainsi l’objet d’un point réunissant l’équipe ainsi que les parties prenantes au sens large. En quatre heures maximum, on aborde les sujets suivants afin de déterminer si le produit est toujours en phase avec les besoins et si des adaptations s’imposent pour les prochains sprints :
🔸 Le Product Owner rappelle la nature du product goal (objectif à long terme) et du sprint goal (à court terme),
🔸 Les incréments réalisés lors du dernier sprint et conformes à 100% à la definition of donefont l’objet d’une démonstration animée par les développeurs sous la houlette du Product Owner. Les interactions et autres feedbacks émanant des utilisateurs finaux sont collectés et intégrés au product backlog.
Bon à savoir : parmi les missions du Product Owner figure la nécessité de dénicher les key users les plus proches des utilisateurs finaux afin de tester les fonctionnalités en conditions presque réelles.
🔸 Le sprint review comporte aussi une phase d’adaptation du travail restant à effectuer au sein du product backlog et de la feuille de route associée. Ce bilan permet de lister les étapes validées, de se projeter dans celles à venir et de penser à l’organisation et au contenu du prochain sprint.
Sprint retrospective : l’analyse du mode de fonctionnement
⏰ 3h ou moins
La méthodologie et l’humain figurent en ligne de mire de cette étape de trois heures au maximum. Assurée par l’intégralité de la team Scrum, elle vise l’analyse et l’adaptation des points suivants :
🔸 Les interactions au sein de l’équipe : communication entre les collaborateurs, détection d’éventuelles tensions,
🔸 Les façons de travailler et les outils utilisés,
🔸 La definition of done.
Artefact Scrum : de quoi s’agit-il ?
Si, à première vue, ce terme peut sembler barbare à tout néophyte qui se respecte, il recouvre en réalité : un « phénomène d’origine humaine, artificielle, intervenant dans l’étude de faits naturels…//… » – Définition issue du dictionnaire Le Robert.
L’analogie avec la méthodologie Scrum ? Elle est, malgré les apparences, tout à fait limpide. En tant que méthode purement empirique, Scrum s’appuie sur un déroulement « naturel » des événements. Procédant par itération, chaque membre d’une team Agile réoriente son projet au fil de l’eau sur le mode de l’improvisation libre tout en respectant néanmoins un framework qui se ventile en trois artefacts classiques complétés par un artefact de transparence :
🔸 Le product backlog,
🔸 Le sprint backlog,
🔸 L’incrément,
🔸 Le definition of done (artefact de transparence).
Le product backlog : le cahier des charges en version Agile
Au démarrage d’un projet Scrum, on met en synergie vision produit, objectif produit et stratégie métier de l’organisation. Ce brainstorming initial se déroule généralement lors d’un atelier qui détermine le « quoi », le « pour qui », le « comment »… Autrement dit, la raison d’être et le but visé du produit.
Une fois ce travail introductif réalisé, le Product Backlog prend tout son sens en déterminant les fonctionnalités produit, les exigences, les améliorations ou les correctifs à prévoir. Cette source d’informations détaillées abreuve véritablement les développeurs qui se nourrissent d’une liste d’items évolutive et priorisée de haut en bas. Durant chaque sprint, le Product Owner affine quant à lui encore et encore les items afin de se rapprocher toujours au plus près du résultat idéal souhaité.
Le sprint backlog : le plan de travail d’un Sprint
Cet artefact désigne les éléments et les tâches techniques sélectionnés à partir du product backlog. Véritable plan de travail de l’équipe lors d’un sprint, le sprint backlog ambitionne de répondre à l’objectif du sprint (sprint goal) tout en intégrant de nouvelles fonctionnalités ainsi que des améliorations. Il comporte en outre un plan de livraison détaillé en sous-tâches techniques.
L’incrément : le « done » du côté des développeurs
L’artefact incrément correspond au fruit du travail des développeurs à l’issue d’un sprint. Chaque sprint peut comporter plusieurs incréments dont l’utilisation est rendue possible grâce à un niveau d’aboutissement suffisant. Bon à savoir : l’incrément regroupe tous les « éléments done », à savoir, les éléments du sprint en cours et ceux ayant déjà été réalisés.
Le definition of done : les critères du « Dod »
Comment savoir si un item est totalement abouti ? Grâce à un ensemble de critères définis par l’équipe de développement. Chaque élément ainsi finalisé se voit étiqueté « Dod ». Pour ne laisser plâner aucun doute, signalons que cette appellation correspond à l’acronyme du mot « definition of done ».
