MÉTHODES AGILES

Deux tiers des équipes agiles dans le monde s'appuient sur un cadre qui tient en treize pages. Comment Scrum organise-t-il le travail dans l'incertitude avec seulement onze éléments ?

Du rugby au logiciel

Le terme Scrum vient du rugby : la mêlée où l'équipe avance ensemble. Il apparaît dès 1986 dans un article de la Harvard Business Review, The New New Product Development Game de Hirotaka Takeuchi et Ikujiro Nonaka, décrivant le développement itératif et auto-organisé chez Honda, Canon et Fujitsu. En 1993, Jeff Sutherland applique ces principes au logiciel ; en 1995 il co-publie le framework avec Ken Schwaber. Le Scrum Guide, dont la version actuelle date de 2020, en est la référence officielle.

Le contrôle empirique : trois piliers

Dans un environnement complexe, on ne peut pas tout planifier à l'avance. Scrum adopte le contrôle empirique fondé sur :

• Transparence — tout le travail significatif est visible (backlog, Definition of Done partagée).
• Inspection — artefacts et progression sont examinés fréquemment.
• Adaptation — dès qu'un écart apparaît, on ajuste le plan plutôt que de s'y accrocher.

Le framework en 3 + 3 + 5

Scrum tient sur onze éléments. Trois responsabilités : Product Owner, Scrum Master, Developers. Trois artefacts : Product Backlog, Sprint Backlog, Increment, chacun porteur d'un engagement. Cinq événements : le Sprint (le conteneur, de 1 à 4 semaines), le Sprint Planning, le Daily Scrum, la Sprint Review (inspection du produit) et la Sprint Retrospective (inspection du processus).

Les cinq valeurs et l'itération

L'équipe auto-organisée incarne cinq valeurs : engagement, focus, ouverture, respect et courage. À chaque Sprint, elle sélectionne un sous-ensemble du Product Backlog, formule un Sprint Goal et livre un Increment potentiellement utilisable. D'après le rapport State of Agile 2024, 66 % des équipes agiles utilisent Scrum, ce qui en fait de loin le cadre le plus déployé.

Comment remplacer un cahier des charges de plusieurs centaines de pages par une phrase tenant sur un post-it ? La user story fait le pari que l'essentiel se joue dans la conversation, pas dans le document.

De la spécification à la conversation

Avant l'agilité, les besoins étaient figés dans de longs documents signés contractuellement : produits en amont, impossibles à faire évoluer sans avenant, et mêlant le « quoi » et le « comment ». En 1998, Kent Beck propose avec eXtreme Programming une alternative radicale : de courtes phrases sur fiches cartonnées, point de départ d'une conversation. Mike Cohn formalise en 2004, dans User Stories Applied, le format canonique : « En tant que [persona], je veux [action], afin de [bénéfice] ».

Les 3 C et le critère INVEST

Ron Jeffries résume la philosophie par les 3 C : la Card (le post-it, volontairement petit), la Conversation (l'échange oral qui élabore le détail, cœur de la valeur) et la Confirmation (les critères d'acceptance). Une bonne story respecte par ailleurs les six critères INVEST de Bill Wake (2003) : Independent, Negotiable, Valuable, Estimable, Small, Testable.

Les critères d'acceptance en Gherkin

La confirmation répond à la question : « comment saurai-je que la story est terminée ? ». Le format dominant est le Gherkin, développé chez Cucumber en 2008 par Aslak Hellesøy, avec une grammaire Given / When / Then directement exécutable comme test automatisé (BDD, Behaviour Driven Development).

Estimer en story points avec le Planning Poker

Pour estimer la complexité relative d'une story sans tomber dans le piège des heures, l'agilité utilise les story points, une échelle abstraite. La technique la plus connue est le Planning Poker (James Grenning, 2002) : chaque membre vote silencieusement avec une carte de la suite de Fibonacci modifiée, puis les écarts entre votes déclenchent une discussion qui fait émerger les hypothèses cachées.

Une équipe agile sans métriques pilote à l'aveugle. Mais mal choisis, les indicateurs poussent à gonfler les estimations et à courir après les points. Comment mesurer sans fausser le jeu ?

Pourquoi mesurer autrement

Le pilotage classique par les indicateurs CQDP (Coût, Qualité, Délais, Périmètre) suppose un périmètre figé et un plan stable. En agilité, où le périmètre évolue à chaque sprint, ces indicateurs perdent leur sens. On mesure plutôt la capacité d'exécution et la réactivité. Tom DeMarco écrivait en 1982 : « You can't control what you can't measure ». Il a nuancé lui-même en 2009 : mesurer le bon indicateur compte plus que mesurer beaucoup.

Quatre métriques structurantes

• Vélocité — story points livrés par sprint ; sert à planifier les releases.
• Cycle Time — temps entre le démarrage et la fin d'un item ; rapidité de livraison.
• Lead Time — temps total entre la création d'un item et sa livraison ; réactivité.
• Throughput — nombre d'items livrés par unité de temps ; capacité de l'équipe.

Le Sprint Burndown et sa lecture

Le Sprint Burndown répond à « où en sommes-nous dans le sprint ? ». En abscisse, les jours ; en ordonnée, le travail restant. La courbe descend à mesure que les items sont terminés et se compare à une ligne idéale droite : au-dessus = retard, en dessous = avance. Un plateau en début de sprint signale un démarrage difficile ; une marche d'escalier trahit le « gros lot de fin de sprint » qu'il faut éviter en travaillant en flux. Le Burndown a une limite : il ne montre qu'une seule dimension, d'où le recours au Burnup et au Cumulative Flow Diagram.

La règle d'or : ne pas fausser le jeu

Ces métriques sont des outils de pilotage interne à l'équipe, jamais des indicateurs de performance individuelle ni de comparaison entre équipes. Bien utilisées, elles permettent la prédictibilité — l'aptitude à tenir un engagement, qui est selon Mike Cohn la première condition de la confiance entre l'équipe et ses parties prenantes.

Scrum est-il vraiment la seule façon d'être agile ? Quand les demandes arrivent de façon imprévisible, un sprint figé devient un carcan. Trois logiques de flux existent : à vous de choisir la bonne.

Trois philosophies du flux

• Scrum — cadence par itérations fixes (sprints de 1 à 4 semaines) et gèle le périmètre pendant le sprint. Idéal pour le développement produit avec une roadmap stable.
• Kanban — privilégie le flux continu, sans itération imposée, limite la quantité de travail simultané et optimise le Cycle Time. Idéal pour le support, la maintenance ou les opérations à arrivée imprévisible.
• Scrumban — l'hybride pragmatique formalisé par Corey Ladas en 2008 : sprints + WIP limits + flux pull à l'intérieur du sprint. Idéal pour les équipes mixtes ou en transition.

Kanban, un héritage Toyota

Le mot kanban (看板) signifie « panneau visuel » ou « étiquette ». Dans le Toyota Production System de Taiichi Ohno (années 1950), une carte physique circule entre postes : pas de carte, pas de production. C'est la logique pull (tirer) opposée au push (pousser), qui limite stock et surproduction. David J. Anderson transpose ces principes au travail intellectuel dans son livre fondateur de 2010.

Les 4 principes et 6 pratiques du Kanban moderne

Anderson pose 4 principes : commencer là où vous êtes, s'engager à un changement progressif, respecter les rôles existants, encourager le leadership à tous les niveaux. Et 6 pratiques : visualiser le flux, limiter le travail en cours (WIP limits), gérer le flux, rendre les règles explicites, mettre en place des boucles de rétroaction, améliorer collaborativement.

Les WIP limits, la pratique-clé

Limiter le nombre d'items par colonne (par exemple 3 en « Doing ») est ce qui distingue un vrai Kanban d'un simple tableau. Un board minimal a 3 colonnes (To Do, Doing, Done) ; un board mature en compte 4 à 7 avec des sous-colonnes Doing/Done pour révéler précisément les goulots d'étranglement.

Votre équipe livre du produit sprint après sprint, mais progresse-t-elle vraiment en tant qu'équipe ? La rétrospective est le seul moment où l'on s'arrête pour inspecter sa propre façon de travailler — et c'est le plus négligé des événements agiles.

Pourquoi la rétrospective change tout

Le Scrum Guide 2020 décrit la Sprint Retrospective comme le moyen pour l'équipe d'inspecter son processus, ses outils et ses interactions. Elle se distingue de la Sprint Review, qui inspecte le produit : la rétro porte sur le comment on travaille, pas sur le quoi on a livré. Selon une étude Scrum.org (2022), les équipes qui la pratiquent avec discipline voient leur vélocité augmenter de 20 à 30 % sur 6 mois — non en gonflant les estimations, mais en supprimant les irritants.

La directive de Kerth

Formulée par Norman Kerth dans Project Retrospectives (2001), la Prime Directive se lit au début de chaque rétro : chacun a fait de son mieux compte tenu de ce qu'il savait et des ressources disponibles. Elle pose l'éthique de l'exercice : on ne cherche pas un coupable, on améliore le système. Sans elle, la rétro dégénère en règlement de comptes.

La structure en 5 phases de Derby et Larsen

La référence absolue est Agile Retrospectives — Making Good Teams Great (2006) d'Esther Derby et Diana Larsen, qui formalise 5 phases universelles :

• Set the stage — cadrer, créer la sécurité psychologique (check-in météo, ESVP).
• Gather data — collecter les faits sans analyser (Timeline, Mad/Sad/Glad).
• Generate insights — trouver les causes racines (5 Whys, Ishikawa).
• Decide what to do — choisir 1 à 3 actions SMART avec owner et deadline.
• Close — récapituler et récolter du feedback (ROTI, Plus/Delta).

Varier les formats

La règle d'or : varier les formats pour éviter la routine qui tue l'effet. Les classiques : Keep/Stop/Start, Starfish, Mad/Sad/Glad, 4L, Speedboat, Timeline. Pour creuser une cause racine, le 5 Pourquoi de Toyota reste l'outil de référence. Une rétro réussie produit au plus 1 à 3 actions d'amélioration — pas 15.