Agile et Scrum : les fondamentaux et la pratique

Le cycle en cascade suppose qu'on sait tout du besoin avant de commencer. L'expérience montre le contraire : le besoin se précise quand on montre quelque chose aux utilisateurs.

Le coût d'un mauvais besoin tardif

Plus un besoin faux est découvert tard, plus il coûte cher. Corriger un écran de saisie est une question d'heures. Corriger l'architecture qui le soutient après qu'un millier d'utilisateurs l'utilisent, c'est un projet à part entière. Le cycle itératif ne réduit pas le coût des corrections : il déplace le moment où on les découvre.

Les quatre valeurs du Manifeste

1. les individus et leurs interactions plutôt que les processus et les outils ;
2. des logiciels opérationnels plutôt que la documentation exhaustive ;
3. la collaboration avec les clients plutôt que la négociation contractuelle ;
4. l'adaptation au changement plutôt que le suivi d'un plan.

Ces valeurs ne sont pas un rejet des processus et des documents : elles sont un arbitrage. « Plutôt que » ne veut pas dire « sans ». Un produit qui fonctionnera sans documentation est un défaut, pas une qualité. Le Manifeste dit que, quand les deux comptent, le premier l'emporte.

Scrum n'est pas « agile »

Scrum est un cadre agile, parmi d'autres (Kanban, XP, SAFe). Présenter Scrum comme la définition de l'agile est une erreur de vocabulaire qui produit des discussions sans conclusion. Un projet peut être agile sans Scrum, et appliquer Scrum de manière mécanique ne garantit rien.

Le mot « empirique » n'est pas décoratif. Il décrit la différence de nature entre une équipe qui décide et une équipe qui constate.

Transparence, inspection, adaptation

• transparence : le travail et son état sont visibles par tous. Un tableau de tâches qui ne reflète pas la réalité détruit la transparence — c'est alors pire que pas de tableau, parce qu'il induit en erreur ;
• inspection : on regarde régulièrement le résultat et le processus. Sans inspection régulière, rien ne peut être corrigé ;
• adaptation : on change le plan en fonction de ce qu'on a constaté. L'inspection sans adaptation est un rituel vide : on regarde des indicateurs, on constate qu'ils sont mauvais, et on change.

Les cinq valeurs Scrum

Commitment, focus, ouverture, respect, courage. Deux méritent un mot : l'ouverture suppose que l'équipe et les parties prenantes admettent que le plan initial était une estimation, pas une promesse ; le courage désigne la capacité à dire qu'un engagement ne tiendra pas, a eviter un scenario un scenario pessimiste, à demander de l'aide. Une équipe qui ne pratique pas le courage declare des"I'll" qu'elle ne tiendra pas, et le Sprint se termine en échec pour tout le monde.

Le test honnête : « Scrum mais »

Le symptôme le plus courant de l'échec de Scrum n'est pas son absence, c'est sa déformation. La phrase à surveiller est « Scrum, mais… » :

• « Scrum, mais le chef de projet décide de tout » → plus d'autonomie d'équipe ;
• « Scrum, mais le sprint ne peut jamais bouger » → plus de capacité d'adaptation ;
• « Scrum, mais on ne montre rien avant la fin du sprint » → plus d'inspection avec les utilisateurs ;
• « Scrum, mais on garde le même périmètre, seules les dates changent » → plus de valeur livrée.

Chaque « mais » retire un pilier. Le diagnostic d'un Scrum qui ne fonctionne pas consiste presque toujours à trouver le « mais » qui a été ajouté.

Un cycle court n'est pas un cycle agile. Un cycle de six mois dont on examine le résultat à la fin est un cycle en cascade avec des noms différents.

La durée du cycle : le bon indicateur

La question utile n'est pas « sommes-nous agiles » mais « combien de temps s'écoule-t-il entre une décision et la preuve qu'elle était bonne ? » Une équipe qui met trois semaines a mettre en oeuvre le verifier est en train de payer un risque pendant trois semaines, quel que soit le vocabulaire employé.

Ce que le cycle court permet réellement

1. réduire l'écart entre l'intention et la réalité : une erreur de conception coûte un cycle, pas un projet ;
2. obtenir de l'information : chaque démonstration est une mesure du marché ;
3. maintenir la motivation : voir le résultat de son travail est un facteur de performance mesuré, pas une évidence.

Quand un cycle long reste justifié

Certains contextes resistent a l'iteration : les systemes critiques où chaque modification doit être validée formellement, contrats qui imposent un calendrier, travail de recherche dont le résultat est incertain par nature. Dans ces cas, l'agilité porte sur la façon de travailler et d'apprendre, pas sur la durée du cycle. Forcer un cycle court là où il est contre-productif est aussi une erreur que l'immobilisme.

Le point de vigilance sur la métrique

Un cycle court qui ne produit aucune valeur livrable devient de l'agilité de façade : beaucoup de réunions, des burndowns verts, et un produit qui n'avance pas. Le test reste : à la fin du cycle, quelque chose de nouveau est-il réellement utilisable ? Si la réponse est non, le cycle est une cérémonie de plus.

Scrum définit trois responsabilités au sein de l'équipe, et une seule personne peut encumuler deux. Ce ne sont pas des postes hiérarchiques.

Les trois responsabilités

• Developers — les personnes qui réalisent l'incrément. Elles décident comment faire le travail, et personne d'autre ne peut leur dire comment. Ni le Product Owner, ni le manager, ni le client ;
• Product Owner — responsable de la maximisation de la valeur du produit. Il ordonne le Product Backlog et décide de ce qui est fait. Il n'a pas à être le client, ni le chef de projet, ni le responsable des communications ;
• Scrum Master — responsable de la compréhension et de l'application de Scrum. Son travail est de lever les obstacles, pas de distribuer les tâches ni de.jetbrains la productive.

Un point de vocabulaire qui n'est pas cosmétique

La version 2020 du Guide a remplacé « Development Team » par « Developers », et a retiré la notion de membre externe de l'équipe : l'équipe L'équipe Scrum compte au plus dix personnes, toutes impliquées sur le produit entier. L'objectif était de retirer l'image de l'équipe de développement comme groupe d'experts distinct du reste, et de mathvariant la responsabilité de chacun sur le produit entier.

Un cours ou un consultant qui parle encore de « Development Team » et de « l'équipe de développement » en 2026 utilise un vocabulaire périmé de dix ans. Ce n'est pas grave en soi, mais cela signale que la formation s'est arrêtée à une version antérieure — et c'est exactement le type de décalage que ce cours cherche à éviter.

Pourquoi la taille est limitée

L'équipe Scrum est bornée à dix personnes ou moins. Au-delà, la coordination consume la capacité : le nombre de relations dans une equipe double en fonction quadratique. Passer de dix à quatorze personnes ne multiply donc pas la production par 1,4 : la coordination mangera une partie du gain, et l'agilité disparaît. La réponse n'est pas d'agrandir l'équipe mais de la découper en plusieurs équipes, ce qui a un coût d'architecture à assumer explicitement.

La version 2020 a clarifié un point resté flou jusque-là : chacun des trois artefacts porte un engagement. Cet engagement est ce qui rend l'artefact transparent.

Artefact	Engagement
Product Backlog	Product Goal
Sprint Backlog	Sprint Goal
Increment	Definition of Done

La Definition of Done n'est pas négociable

La définition de « terminé » décrit l'état d'un incrément qui respecte les exigences de qualité du produit. Sa règle la plus importante, et la plus souvent violée :

Un élément du Product Backlog qui ne respecte pas la Definition of Done ne peut être ni mis en production, ni même présenté à la revue de sprint. Il retourne au Product Backlog.

Cette règle protège la rétrovision. Une revue de sprint où l'on présente du travail non terminé apprend à l'équipe et aux parties prenantes à ne plus croire aux revues. Si c'est un standard de l'organisation, toutes les équipes doivent le respecter au minimum.

Le Sprint Goal : le recentrage du cycle

Le Sprint Goal est un objectif unique, formulé en un objectif, qui donne de la cohérence à des travaux qui n'auraient pas de sens ensemble. C'est ce qui évite que le sprint devienne une course à la quantité d'histoires terminées.

Product Backlog : ordonné, pas figé

Le Product Backlog n'est pas une liste gelée : il est ordonné par valeur, et l'ordre évolue au fil de ce que l'équipe apprend. Le mot « affinage » a remplacé « grooming » dans le Guide 2020 — ce n'est pas un simple changement de mot, l'affinage désigne le travail de rendre un élément assez clair, assez découpé et assez petit pour être planifiable.

Le Guide fixe une durée maximale à chaque événement, dans un but précis : réduire le besoin de réunions informelles. Un événement qui dépasse sa durée ne devient pas plus utile, il consomme du temps qui aurait servi au travail.

Le Sprint : un mois ou moins

Un conteneur d'un mois au maximum, de durée constante : elle ne se raccourcit pas et ne se prolonge pas. Un sprint de six semaines, c'est quatre sprints, pas un sprint long. La durée maximale d'un mois est un choix cohérent avec la définition même de Scrum : si le cycle doit être plus long, le problème est dans la granularité des éléments, pas dans le format.

Les quatre événements

1. Planification de sprint : l'équipe répond à deux questions — que peut-elle livrer, et comment ? Puis elle formule le Sprint Goal. Un seul événement, et non deux comme dans les versions antérieures ;
2. Mêlée quotidienne : 15 minutes, chaque jour, au même endroit, pour planifier les 24 prochaines heures. Ce n'est pas un rapport de statut — c'est le principal malentendu ;
3. Revue de sprint : démonstration du travail fini et collecte des retours sur ce qui sera ensuite demandé. L'objectif est adapter le Product Backlog ;
4. Rétrospective : improving façon dont l'équipe travaille, sur trois éléments : ce qui a marché, ce qui a posé problème, ce qu'on essaie au prochain cycle.

Le Daily reformulé en 2020

La version 2020 a recentré les trois questions sur l'équipe et l'objectif, et non sur l'individu :

1. qu'ai-je fait hier qui a aidé l'équipe à atteindre le Sprint Goal ?
2. que vais-je faire aujourd'hui pour que l'équipe atteigne le Sprint Goal ?
3. vois-je un obstacle qui empêche l'équipe d'atteindre le Sprint Goal ?

La nuance n'est pas rhétorique : la première question fait passer le propos du « j'ai fini ma tâche » au « j'ai contribué à l'objectif de l'équipe ». C'est le moyen le plus simple de faire disparaître le rapport de statut.

Estimer n'est pas prédire une date. C'est permettre à l'équipe de prendre une décision sur la base de ce qu'il lui est réellement possible de faire.

Trois nombres, trois usages distincts

• la valeur : ce que l'élément apporte au produit — bénéfice pour l'utilisateur, pas charge de travail. Elle sert à ordonner le Product Backlog ;
• la taille : l'effort relatif, en points, pas en heures. Les points n'ont pas à être convertis en temps : la conversion n'est pas stable, elle varie selon la personne, le contexte et la fatigue ;
• la confiance : à quel point l'équipe croit à son estimation.

Pourquoi des points plutôt que des heures

Convertir des heures promet une précision que personne n'a. Les heures sont directement corrélées à la vitesse de chacun, à son expérience du sujet, et à ce qu'il a dans la tête ce matin-là. Deux développeurs qui donnent des estimations en heures ne sont pas comparables : elles décrivent deux personnes, pas une tâche.

Une échelle grossière — 1, 2, 3, 5, 8, 13, 21 — est volontairement imprécise. Elle force la conversation sur ce qui est réellement demandé, et c'est cette conversation qui a de la valeur, pas le nombre obtenu.

Le piège de la vitesse comparée

Comparer la vélocité d'une équipe à celle d'une autre n'a aucun sens : elle dépend de la taille de l'équipe, des personnes, de la maturité, du domaine. C'est un outil de prévision pour l'équipe, à elle-même. Le transformer en indicateur de performance individuelle produit l'effet inverse de celui recherché : les équipes gonfleront leurs estimations pour paraître prévisibles, et la fiabilité disparaîtra.

Ce qu'une estimation n'est pas

Un engagement. La distinction est juridique autant qu'organisationnelle : une estimation est une prévision fondée sur l'information disponible. Un engagement est une promesse, et le Guide 2020 emploie volontairement le mot commitment pour les artefacts — pas pour les dates.

Un élément trop gros ne peut pas être estimé, et ne peut pas être terminé dans un sprint. L'affinage le rend Ready : suffisamment compris, découpé et petit pour entrer dans un sprint.

Ready et Done : deux états symétriques

La version 2020 a introduit cette symétrie, qui clarifie beaucoup de discussions floues :

• Ready : l'élément peut être planifié — assez clair, assez petit, avec les dépendances connues ;
• Done : l'incrément respecte la Definition of Done.

Un élément Ready mal découpé conduit à un travail non terminé ; un élément Done qui ne l'est pas conduit à une fausse livraison. La transparence porte sur les deux extrémités, pas seulement sur l'avancement.

Découper sans perdre le sens

Le découpage vertical — une tranche de fonctionnalité qui traverse toute la pile — est préférable au découpage horizontal, qui produit des couches technique inertes : la base de données est prête mais l'écran ne fait rien. L'élément découpé verticalement est démontrable, donc testable, donc réellement fini.

L'affinage est du temps de production

Le Product Owner et l'équipe affinent pendant l'itération, pas la veille du sprint. Le meilleur test : l'élément ne peut pas être décrit en une phrase par l'utilisateur, il n'est pas prêt. Tout le reste — discussion technique comprise — relève de l'estimation, pas de l'affinage.

Une mesure qui ne change aucune décision est une charge. Cette question doit précéder tout choix d'indicateur.

Le graphique d'avancement : ce qu'il ne dit pas

Un graphique d'avancement suppose que l'on sait combien de travail reste. Dans une équipe qui apprend, cette quantité change en permanence : un Affinage détaillé, une difficulté découverte, une dependance levee. Le graphique sature alors, ou décroche, sans que rien ne soit réellement faux.

Il reste utile à condition d'être lu comme une conversation sur la prévision, jamais comme une mesure de performance. Utilisé de la seconde manière, il provoque exactement le comportement qu'il prétend éviter : gonfler les estimations pour que la courbe reste jolie.

Les indicateurs qui tiennent leurs promesses

• le temps de cycle : durée entre le moment où un élément entre dans le flux et celui où il est terminé. Il décrit la santé du système de production de valeur, et il ne se dégrade pas quand on améliore les pratiques ;
• le taux d'achèvement des Definition of Done : il distingue le travail réellement livré du travail déclaré ;
• la fréquence de livraison : en incréments, pas en tâches. C'est la meilleure mesure de la capacité d'un système à produire de la valeur ;
• le délai de reprise après incident : souvent absent des tableaux de bord, alors qu'il conditionne directement la confiance du client.

La règle d'or de la mesure d'équipe

Un indicateur d'équipe ne doit jamais être utilisé pour comparer deux personnes. Utilisé à l'envers, il dégrade la collaboration, encourage la répartition défensive du travail, et finit par rendre la mesure fausse. Une mesure qui a déformé le comportement qu'elle voulait observer n'est plus utilisable, quelle que soit sa qualité méthodologique.

Une équipe Scrum ne dépasse pas dix personnes. Un produit important en exige plusieurs. La question n'est alors plus « comment faire vivre Scrum » mais « comment faire tenir plusieurs Scrum sur un même produit ».

Le problème de la dépendance

Deux équipes qui travaillent sur le même module sans coordination se gênent : l'une casse ce que l'autre vient de faire. La parade est un contrat d'interface explicite, testé automatiquement des deux côtés. Le coût est réel et doit être annoncé : plus d'équipes signifie plus de contrats à maintenir, pas seulement plus de production. Cet arbitrage est le point sur lequel les découpages d'équipe se justifient ou s'effondrent.

Le vocabulaire à employer honnêtement

Un dispositif qui suggère à plusieurs équipes Scrum un cadre commun — même façon de découper, mêmes conventions, même Definition of Done — est un cadre d'alignement. Les noms commerciaux de ces cadres sont nombreux et changent vite. Ce cours les mentionne pour que les étudiants les reconnaissent, mais ne s'attarde sur aucun : ce qui compte est la structure (qui décide, comment les équipes s'alignent, comment la valeur est priorisée à l'échelle), pas le nom du cadre.

Le piège de la coordination ajoutée

Le symptôme d'un découpage raté : les réunions de coordination entre équipes consomment plus de temps que le travail. Le test : si une équipe passe plus de temps en réunion avec les autres qu'en développement propre, le découpage est à revoir.

Une partie importante des organisations n'a pas de « développement » au sens strict. L'agilité s'y applique quand le travail doit produire de la valeur par cycles courts et apprenants.

Le test d'applicabilité

Trois questions : le travail peut-il être découpé en incréments livrables ? Le résultat peut-il être inspected rapidement par quelqu'un qui connaît le domaine ? L'équipe peut-elle adapter son plan à ce qu'elle apprend ? Si oui aux trois, l'agilité s'applique — qu'il s'agisse d'un marketing, d'un evenement, d'un espace client ou d'une démarche qualité.

Ce qui ne change pas

• la Definition of Done : un livrable non conforme ne peut pas être présenté comme terminé ;
• l'inspection avec les personnes concernées, pas seulement avec la hiérarchie ;
• la distinction entre estimation et engagement.

Ce qui change, et beaucoup

1. l'unité de valeur : ce n'est plus une fonctionnalité logicielle mais un livrable métier — une campagne, un parcours client, une formation ;
2. le délai de détection d'une erreur : en développement, l'erreur se voit quand l'utilisateur l'utilise. Hors développement, une campagne peut être « terminée » et counterproductive avant d'être analysée ;
3. la Definition of Done est le point critique, parce qu'il n'existe pas de test automatique : c'est l'avis métier qui fait foi, et il doit être formulé à l'avance, sinon on debate après coup sur ce qui aurait dû être fait.

L'avertissement honnête

Adapter Scrum à un travail qui ne s'y prête pas — un chantier physique, une intervention de sécurité — produit des rituels vides et une démotivation. Le critère n'est pas « est-ce agile ? » mais « le cycle court produit-il de l'information que l'équipe n'aurait pas eue autrement ? » Sans réponse, le cycle long est plus honnête.

Le livrable

Tenir deux sprints complets sur un produit de son choix, avec l'intégralité des artefacts du Guide 2020 : Product Backlog avec Product Goal, Sprint Backlog avec Sprint Goal, Definition of Done écrite, incrément réellement livré à la fin de chaque sprint. Le journal de bord est le livrable principal — pas le produit.

Les sept points d'évaluation

1. le vocabulaire est exact : Developers, Product Owner, Scrum Master, engagement de chaque artefact, affinage et non « grooming », mêlée et non « daily meeting ». Le vocabulaire n'est pas cosmétique : c'est le protocole de travail ;
2. un incrément conforme à la Definition of Done par sprint. Si ce n'est pas le cas, le projet n'est pas concluant, quelle que soit la qualité du code produit ;
3. le Sprint Backlog contient un plan, pas seulement une liste : les Developers décident comment faire, et cela s'inscrit ;
4. la mêlée parle de l'objectif, pas des tâches : les trois questions du Guide 2020, formulées sur l'équipe ;
5. la rétroinspection a produit une modification réelle au cycle suivant, et la modification est décrite ;
6. les métriques sont utilisées pour décider et non pour comparer des personnes ;
7. les incidents sont traités en dix minutes maximum, par le groupe restreint, avec une trace écrite et un plan d'action.

L'exercice qui fait la différence

Simuler un Objectif de Sprint qui n'est pas atteint — un dépendant, une absence, une découverte. Le livrable attendu est la trace de ce que l'équipe a fait : a-t-elle principalement absorbé le retard, ou a-t-elle réadapté son engagement ? La seconde réaction est la compétence visée. Une equipe qui attend la fin sans jamais rediscuter son engagement produit un sprint vide et apprend qu'il faut gonfler ses estimations.

Le critère qui départage

Le jury retient une seule chose : le journal de bord est-il honnête ? Un journal qui montre des meetings parfaits, aucun imprévu et une vélocité constante ne démontre rien — c'est le scénario idéal, pas une pratique. Ce qui convince est la trace d'un vrai Contacts, avec ce que l'équipe en a tiré.