Agile et Scrum, quelle est vraiment la différence ? — L'essentiel pratique pour les équipes de développement

Introduction

Cet article clarifie la relation entre Agile et Scrum, et résume les connaissances minimales nécessaires pour travailler efficacement en équipe. Il s'adresse aux personnes qui rejoignent prochainement une équipe ou qui souhaitent mettre à jour leurs connaissances acquises en autodidacte.

Qu'est-ce qu'Agile ?

En une phrase

Agile n'est pas une méthode spécifique, mais une « façon de penser » et un « ensemble de valeurs » pour le développement logiciel. Son point de départ est le « Manifeste Agile » (Agile Manifesto), publié en 2001 par 17 développeurs de logiciels réunis ensemble.

Les quatre valeurs

Le Manifeste Agile exprime ces valeurs en privilégiant la droite par rapport à la gauche.

Point important : cela ne signifie pas que « le côté gauche n'a pas de valeur ». Les deux côtés ont de la valeur, mais nous accordons plus d'importance au côté droit – telle est la posture d'Agile.

12 principes (extraits)

Derrière le manifeste se trouvent 12 principes. Il n'est pas nécessaire de tous les mémoriser, mais voici les trois les plus fréquemment cités :

1. Notre priorité absolue est de satisfaire le client en livrant tôt et régulièrement des logiciels à valeur ajoutée.
2. Les changements d'exigences sont les bienvenus, même tard dans le développement.
3. Livrez fréquemment des logiciels opérationnels, avec des cycles de quelques semaines à quelques mois, en préférant les délais courts.

« Livrer des logiciels fonctionnels en cycles courts » et « Accueillir le changement » – ces deux points peuvent être considérés comme le cœur d'Agile.

Qu'est-ce que Scrum ?

Sa relation avec Agile

C'est précisément là que la confusion survient souvent. En schéma, cela donne ceci :

Agile (état d'esprit / valeurs)
├── Scrum (framework) ← le plus répandu
├── XP (Extreme Programming)
├── Kanban
└── Autres...

En d'autres termes, Scrum est l'un des frameworks concrets permettant de mettre en pratique Agile. Agile ≠ Scrum, et la relation correcte est Scrum ⊂ Agile.

Le 3-5-3 de Scrum

Scrum est composé de « 3 Responsabilités (Accountabilities), 5 Événements et 3 Artefacts ». Dans la version 2020, l'ancien terme « rôles » a été remplacé par « responsabilités », et chaque artefact a reçu un engagement (Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done).

Les 3 Responsabilités

• Product Owner (PO) : Responsable de la maximisation de la valeur du produit. Décide des priorités sur ce qui doit être créé.
• Scrum Master (SM) : Soutient le bon fonctionnement de Scrum. Coach de l'équipe qui supprime les obstacles.
• Developers : Les personnes qui construisent réellement le produit. Ingénieurs, designers, QA, etc.

Les 5 Événements

Les 3 Artefacts

• Product Backlog : Une liste priorisée de tout ce que l'on souhaite réaliser. Géré par le PO.
• Sprint Backlog : La liste des travaux à effectuer pour le Sprint en cours. Géré par les Developers.
• Increment : Le produit fonctionnel complété lors du Sprint.

Le cycle de Sprint

[Planning] → [Développement + Daily × N jours] → [Review] → [Rétro] → Sprint suivant

Répéter ce cycle sur une période fixe est le rythme fondamental de Scrum.

Approfondissement de Scrum avec des exemples concrets

À partir d'ici, explorons en détail les aspects difficiles à saisir avec des explications abstraites, en s'appuyant sur un produit fictif comme exemple.

Approfondissement des Responsabilités

Product Owner (PO) — La journée de Marie

Le travail du PO est souvent résumé par « décider des priorités », mais en réalité c'est beaucoup plus complexe. Voici une journée type de Marie, la PO de l'équipe FitLog :

• Matin : Analyse les données d'utilisation de la dernière release, identifie les écrans avec un taux d'abandon élevé. Trie les demandes remontées par l'équipe Customer Success.
• Après-midi : Rencontre les parties prenantes (marketing, direction) pour aligner les objectifs business du Q3 avec le Product Goal.
• Entre les deux : Répond immédiatement aux questions des developers du type « Cette spec – cette implémentation serait plus légère, qu'en pensez-vous ? »
• Hebdomadairement : Affine le backlog et clarifie les critères d'acceptation des éléments prioritaires.

Le point essentiel : le PO porte à la fois la « valeur utilisateur » et la « valeur business ». Pour pouvoir trancher « Feature A ou Feature B – laquelle en premier ? », il doit maîtriser la recherche utilisateur, l'analyse de données et les réunions de direction.

Scrum Master (SM) — Exemples d'interventions de Thomas

Le SM est souvent considéré comme un « animateur de réunions », mais son essence est d'être un coach qui fait émerger l'autonomie de l'équipe. Ce que Thomas, le SM de l'équipe FitLog, fait concrètement :

• Remarque que le développeur A dit chaque jour au Daily Scrum « Hier j'ai encore enquêté sur ce bug » et lui parle en 1-on-1 : « Tu bloques ? Tu as besoin d'aide ? »
• Observe que PO et developers ont systématiquement des divergences d'interprétation de la spec, et inscrit ce problème à l'ordre du jour de la Rétro.
• Stoppe les demandes directes d'autres départements (« Besoin d'aide en urgence ! ») aux developers et réaffirme la règle : « Les demandes passent par le PO. »
• Propose de revoir le format des événements Scrum quand l'équipe est rodée (ex : changer le format du Daily Scrum).

Le SM est un rôle qui semble ne rien faire mais façonne en permanence l'environnement de l'équipe. « Le SM a l'air inoccupé ces derniers temps » peut en réalité être un bon signe que l'équipe commence à fonctionner de manière autonome.

Developers — Que signifie « auto-organisé » ?

Dans le Scrum Guide 2020, l'ensemble de l'équipe Scrum est décrite comme auto-organisée (self-managing). Chez les Developers, l'auto-organisation se manifeste concrètement ainsi :

• « Quoi » faire dans le Sprint se décide en concertation avec le PO, mais « comment » l'implémenter est décidé par les Developers.
• Les tâches ne sont pas assignées d'en haut ; les Developers les prennent d'eux-mêmes.
• Les estimations sont faites par les Developers (pas par le PO ni le manager).
• Les Developers sont responsables du respect des standards de qualité (Definition of Done).

Quand Lucas, developer iOS, remarque « Cette API répond trop lentement et nuit à l'UX », il consulte directement Pierre, developer Backend, pour l'améliorer – ce type de collaboration horizontale naturelle est la marque d'une équipe Scrum saine.

Approfondissement des Événements

Sprint Planning — Exemple de déroulement réel

Le Sprint Planning de 2 semaines de l'équipe FitLog se déroule ainsi (durée environ 4 heures) :

Partie 1 : Pourquoi ce Sprint est-il précieux ? (Définir le Sprint Goal)

PO Marie : « Je souhaite que notre objectif pour ce Sprint soit : "Les utilisateurs peuvent consulter l'évolution de leur entraînement sur les 30 derniers jours via un graphique." La recherche du mois dernier a montré que les utilisateurs avec un taux de rétention élevé utilisent davantage la fonctionnalité graphique. »

Le Sprint Goal s'exprime idéalement comme un état à atteindre, et non comme une liste de fonctionnalités.

Partie 2 : Que peut-on réaliser ce Sprint ? (Sélection des éléments du Backlog)

Pour les éléments prioritaires présentés par le PO, les developers estiment via le Planning Poker et sélectionnent une quantité en adéquation avec leur capacité.

Partie 3 : Comment compléter le travail sélectionné ? (Décomposition en tâches)

Les developers décomposent les éléments de backlog sélectionnés en tâches concrètes.

Developer Lucas : « En décomposant l'élément "Écran d'affichage du graphique", on obtient 4 tâches : conception API, implémentation iOS, implémentation Android, et tests E2E. Sans terminer la conception API, on ne peut pas paralléliser, donc Pierre devrait se concentrer dessus le premier jour. »

Daily Scrum — Bon vs Mauvais

❌ Mauvais Daily (devient un rapport de statut)

« Hier j'ai travaillé sur l'implémentation de l'API. Aujourd'hui j'écris les tests. Pas de blocage. »
« J'ai avancé sur l'implémentation de l'écran. Je continue aujourd'hui. »
…… (15 minutes monotones)

C'est un rapport de statut, pas de l'inspection et de l'adaptation.

✅ Bon Daily (inspection et adaptation)

Developer Lucas : « La bibliothèque de rendu graphique est plus lourde que prévu. Pour atteindre le Sprint Goal, je veux envisager de passer à une autre bibliothèque. J'ai besoin de 2 heures d'investigation supplémentaire après le Planning. »
Developer Pierre : « Dans ce cas, je peux avancer mon implémentation API d'un jour et venir en soutien. »
Developer Lucas : « Alors réglons les détails à deux en 30 minutes tout de suite après. »

Le vrai objectif est un lieu pour re-planifier comment agir aujourd'hui en référence au Sprint Goal.

Sprint Review — Bien plus qu'une démo

Un malentendu fréquent sur la Review est « démo du produit fonctionnel et terminé ». Une vraie Review est un espace de dialogue avec les parties prenantes.

• Les Developers font la démo de l'Increment fonctionnel
• Les parties prenantes l'essaient et donnent du feedback
• Des informations externes sont partagées : « Le marché a changé », « Les réactions des utilisateurs cibles différaient des attentes »
• Sur cette base, le Product Backlog est ajusté pour la suite

La Review sert donc non seulement d'« inspection du passé » mais aussi d'« input pour la planification future ».

Sprint Retrospective — Conseils pour éviter le rituel vide

La Rétro est souvent vue comme « on utilise le KPT (Keep/Problem/Try) », mais n'importe quel format convient. Changer de format selon la situation de l'équipe est utile, mais c'est un moyen, pas un but.

Variations que l'équipe FitLog expérimente :

Et limiter les Try à un seul, et commencer à y travailler dès le début du Sprint suivant. « Tout faire » équivaut à ne rien faire.

Approfondissement des Artefacts

Product Backlog — La bonne granularité des éléments

Les Product Backlog Items (PBIs) sont souvent rédigés au format User Story :

En tant que [quel type d'utilisateur]
Je veux [faire quoi]
Afin de [pourquoi je veux le faire]

Bon exemple de PBI pour FitLog :

Titre : Afficher le graphique de progression d'entraînement sur 30 jours

En tant qu'utilisateur qui pratique régulièrement le jogging, je veux voir un graphique de ma distance de course sur les 30 derniers jours, car je veux maintenir ma motivation en visualisant mes efforts.

Critères d'acceptation :

• Un onglet « Progression » est ajouté à l'écran d'accueil
• La distance de course journalière sur les 30 derniers jours est affichée sous forme de courbe
• Les jours sans données apparaissent comme vides sur le graphique
• Appuyer sur le graphique navigue vers l'écran de détail de ce jour

❌ Mauvais exemple de PBI : « Implémenter la fonctionnalité graphique » ← Flou sur pour qui et dans quel but

Les PBIs devraient idéalement satisfaire le principe INVEST (Independent / Negotiable / Valuable / Estimable / Small / Testable).

Sprint Backlog — Connexion au Product Goal

Le Sprint Backlog n'est pas une « liste de tâches » ; c'est un plan composé de trois éléments :

1. Sprint Goal (pourquoi) : L'état à atteindre dans ce Sprint
2. PBIs sélectionnés (quoi) : Éléments choisis dans le Product Backlog
3. Plan d'exécution (comment) : Décomposition en tâches et approche

Sprint Goal : Les utilisateurs peuvent consulter leur progression d'entraînement des 30 derniers jours via un graphique
├─ PBI 1 : Écran d'affichage du graphique de progression [8 pt]
│   ├─ Task : Conception du endpoint API
│   ├─ Task : Implémentation iOS
│   ├─ Task : Implémentation Android
│   └─ Task : Tests E2E
├─ PBI 2 : Navigation vers le détail au tap sur le graphique [3 pt]
│   └─ ...
└─ PBI 3 : Amélioration de l'affichage en cas de données vides [2 pt]
    └─ ...

Increment — La « Definition of Done (DoD) »

L'Increment est décrit comme « produit fonctionnel », mais ce qui constitue la complétion doit être clairement défini par l'équipe. C'est la Definition of Done (DoD).

Exemple de DoD de l'équipe FitLog :

• Code review avec au moins 2 Approvals
• Couverture de tests unitaires à 80 % minimum
• Tests E2E passés
• Vérification d'accessibilité effectuée (VoiceOver / TalkBack)
• PM a vérifié les critères d'acceptation et donné son OK
• Brouillon des release notes créé

Tout ce qui ne satisfait pas la DoD est considéré « incomplet » et reporté au Sprint suivant. Livrer 5 fonctionnalités à 100 % vaut mieux qu'accumuler 10 fonctionnalités à 80 % – c'est la mentalité Scrum.

Vélocité — Mesurer la « vitesse » de l'équipe

Si vous avez lu jusqu'ici, vous vous demandez peut-être : « C'était quoi ce [8 pt] à côté des PBIs ? » Cela mène au sujet de la Vélocité (Velocity), importante pour opérer Scrum en pratique.

Définition

La vélocité est la taille totale des éléments de backlog qu'une équipe complète par Sprint. Elle est généralement définie ainsi :

Vélocité = Somme des Story Points des PBIs ayant satisfait la Definition of Done lors de ce Sprint

Points importants :

• On ne compte que les PBIs terminés (80 % fait = 0)
• L'unité est généralement les Story Points (SP) (pas les heures)
• Mesurée par Sprint ; souvent observée comme une moyenne mobile sur plusieurs Sprints

Qu'est-ce que les Story Points ?

Les Story Points représentent la taille relative du travail. Plutôt que des valeurs absolues comme « jours-hommes » ou « heures », on estime par comparaison à une tâche de référence : « Quelle est la taille de ce travail par rapport à cette tâche de base ? »

La progression couramment utilisée est la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21...). Les intervalles croissants reflètent l'idée que « les grandes tâches ont plus d'incertitude, et des distinctions fines n'ont pas de sens ».

Référence d'estimation de l'équipe FitLog :

Exemple : Évolution de la vélocité de l'équipe FitLog

Regardons les résultats de l'équipe FitLog sur les 6 derniers Sprints :

Sprint 1 : 18 pt (PBIs terminés : 5 + 5 + 3 + 3 + 2)
Sprint 2 : 22 pt (PBIs terminés : 8 + 5 + 5 + 2 + 2)
Sprint 3 : 25 pt (PBIs terminés : 8 + 8 + 5 + 3 + 1)
Sprint 4 : 23 pt
Sprint 5 : 26 pt
Sprint 6 : 24 pt
─────────────────────
Moyenne des 3 derniers Sprints : 24,3 pt ← vélocité actuelle

Cela indique que l'équipe peut gérer environ 24 points par Sprint.

Comment utiliser la vélocité

Une fois la vélocité stabilisée, elle permet les utilisations suivantes :

1. Évaluer la capacité lors du Sprint Planning

PO Marie : « Les PBIs candidats pour le prochain Sprint totalisent 32 points. »
Developer Lucas : « Avec une moyenne récente de 24 points, il est réaliste de prendre en charge les 26 premiers points (8+8+5+3+2). »

Au lieu de « on va y arriver avec de la volonté », cela permet un accord basé sur les faits.

2. Prévoir les plans de release

Si l'ensemble du Product Backlog représente 180 points et la vélocité est de 24 points, la projection est 180 ÷ 24 = environ 7,5 Sprints pour terminer.

Avec cela, on peut expliquer aux parties prenantes de façon argumentée : « Nous pouvons vraisemblablement livrer fin Q3. »

3. Amélioration continue de la précision des estimations

Quand des écarts sont visibles (« estimé à 5 points, mais l'effort réel était de 10 points »), cela devient du matériel pour la Rétro.

Anti-patterns courants

La vélocité est utile, mais mal utilisée, elle peut détruire une équipe.

❌ Anti-pattern 1 : Faire de la vélocité un KPI

« Ce mois-ci la vélocité doit être plus haute que le mois dernier », « Avoir une vélocité inférieure à l'autre équipe signifie que vous flânez » – c'est la pire façon de l'utiliser.

La vélocité est une valeur relative propre à chaque équipe, et la comparer entre équipes n'a aucun sens. De plus, mettre la pression pour « augmenter la vélocité » amène simplement les équipes à gonfler leurs estimations – la productivité réelle ne change pas (elle diminue même).

❌ Anti-pattern 2 : Story Points = Temps

Commencer à utiliser « 1 point = 4 heures » comme conversion fixe rend les Story Points sans sens. Les avantages de l'estimation relative (exprimer l'incertitude, rendre la discussion plus efficace) sont perdus, et cela régresse vers une simple estimation d'effort.

❌ Anti-pattern 3 : Compter des points partiels pour les PBIs incomplets

« Un PBI de 8 points est terminé à 70 %, alors comptons 5,6 points » – cela ne doit pas être fait. Les PBIs qui ne satisfont pas la Definition of Done comptent pour 0 point.

Raison : La vélocité est une métrique pour prédire « combien on peut terminer au prochain Sprint ». Compter les travaux en cours fausse la prédiction.

❌ Anti-pattern 4 : Faire confiance aux valeurs juste après un changement d'équipe

Quand des membres arrivent ou partent, ou que la stack technologique change, la vélocité se réinitialise. Après l'établissement d'une nouvelle configuration, la règle d'or est de faire d'abord 3 à 4 Sprints avant de recalculer la moyenne.

L'option de ne pas utiliser la vélocité

Ces dernières années, de plus en plus d'équipes « ne suivent pas la vélocité ». Les métriques alternatives incluent :

• Débit (Throughput) : Nombre de PBIs terminés (sans points, en gardant une granularité cohérente et en comptant)
• Cycle Time : Temps entre le démarrage et la complétion d'un PBI
• Lead Time : Temps entre la création et la complétion d'un PBI

Particulièrement en combinaison avec Kanban, ou pour des équipes matures cherchant à réduire le coût des estimations, ces métriques peuvent être plus efficaces.

Glossaire essentiel

Scrum/Agile possède beaucoup de terminologie propre, et la maîtriser ou non affecte considérablement l'efficacité de la communication au sein d'une équipe. Approfondissons avec des exemples concrets.

Planning Poker

Ce que c'est

Le Planning Poker est une technique où toute l'équipe estime les Story Points pour les PBIs. Plutôt qu'un ingénieur expérimenté décidant « c'est 5 points », tous les membres révèlent simultanément leur carte et construisent un consensus.

Pourquoi le format « Poker » ?

Pour éviter l'« effet d'ancrage » où les gens sont entraînés par l'opinion de la personne la plus vocale ou la plus expérimentée. Si quelqu'un dit d'abord « c'est 8 points, non ? », les autres membres ont du mal à dire « je pense que c'est 3 ». Tout le monde révèle ses cartes simultanément pour éviter cela.

Déroulement (exemple de l'équipe FitLog)

Les cartes utilisent la suite de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, ?, ☕). « ? » signifie « je ne sais pas » et « ☕ » signifie « j'ai besoin d'une pause ».

Étape 1 : Expliquer le PBI

PO Marie : « Suivant : "Envoyer des rappels via notification push". Si un utilisateur a défini une heure et n'a pas enregistré d'entraînement ce jour-là, lui envoyer une notification. »

Étape 2 : Questions et réponses

Developer Lucas : « Le message de notification peut-il être personnalisé ? »
PO Marie : « Non, un message fixe suffit. »
Developer Pierre : « Prévoyons-nous d'utiliser l'infrastructure de notification existante côté serveur ? »
PO Marie : « Oui, en partant de l'infrastructure existante. »

Étape 3 : Tout le monde révèle ses cartes simultanément

Étape 4 : Demander aux valeurs extrêmes d'expliquer

Valeur la plus basse, Pierre : « Côté BE, c'est juste ajouter un appel à l'infrastructure de notification existante, donc 3. »
Valeur la plus haute, Camille : « Côté Android, j'ai 3 choses à implémenter : sauvegarder les paramètres utilisateur, une tâche périodique et la gestion des notifications. La dernière fois que j'ai fait quelque chose de similaire ça m'a pris du temps, d'où le 13. »

Étape 5 : Re-voter après discussion

Après discussion, tout le monde converge vers « 8 ». Accord final sur 8 points.

Points clés

• Ne pas voter trop vite : Révéler les cartes seulement après avoir aligné les hypothèses via les Q&A
• Ne pas blâmer celui qui diverge : La divergence est due à des différences d'information ; les partager est l'objectif
• Ne pas y consacrer trop de temps : Viser 5 à 10 minutes par PBI. Les PBIs sans accord retournent au Refinement.

Backlog Refinement

Ce que c'est

Le Refinement est l'activité continue d'entretien du Product Backlog. Concrètement :

• Diviser les PBIs trop grands
• Concrétiser les critères d'acceptation des PBIs prioritaires
• Supprimer les PBIs obsolètes
• Estimer (souvent utilisé comme session de Planning Poker)

Quand le faire

Le Scrum Guide ne le définit pas comme un événement indépendant, mais la plupart des équipes consacrent 1 à 2 heures hebdomadaires. Beaucoup d'équipes le planifient en milieu de Sprint.

Definition of Ready

Un concept parfois discuté en contraste avec la DoD en pratique est la Definition of Ready. L'idée est que lorsqu'un PBI atteint un état Ready via le Refinement, il peut être amené au Planning.

Exemple de définition de Ready de l'équipe FitLog :

• Rédigé au format User Story
• Dispose d'au moins 3 critères d'acceptation
• Tous les membres de l'équipe comprennent le contenu
• Divisé à 8 points ou moins
• Si des dépendances externes existent, elles ont été convenues avec les parties concernées

Le principe INVEST (Approfondissement)

Les 6 qualités qu'un bon PBI devrait satisfaire. Voyons chacune avec des exemples.

Hiérarchie des User Stories — Thème, Epic, Story, Tâche

Le Product Backlog est une liste unidimensionnelle, mais en pratique on pense souvent en 4 niveaux.

Thème : Améliorer l'engagement utilisateur
└─ Epic : Mécanismes pour favoriser la continuité de l'entraînement
   ├─ User Story : Voir la progression des 30 derniers jours via graphique [8 pt]
   │  ├─ Tâche : Implémentation API
   │  ├─ Tâche : Implémentation UI iOS
   │  └─ Tâche : Implémentation UI Android
   ├─ User Story : Recevoir des notifications de rappel [8 pt]
   └─ User Story : Afficher le nombre de jours consécutifs d'enregistrement [3 pt]

Les PBIs qui apparaissent dans le Backlog sont principalement les Epics et les User Stories.

Burndown Chart / Burnup Chart

Burndown Chart

Un graphique qui visualise la progression du travail restant pendant un Sprint. Il montre comment la progression réelle se comporte par rapport à la ligne idéale (une ligne qui diminue régulièrement).

pt restants
24┤●
22┤  ●
20┤    ●─ Ligne idéale ────
18┤      ╲╲
16┤        ●(Réel, légèrement en retard)
14┤          ●
12┤            ╲
 0┤──────────────●
    J1  J3  J5  J7  J10

Si la courbe réelle reste constamment au-dessus de la ligne idéale → signal que le Sprint Goal est en danger. Envisager d'agir tôt (réduction du scope, demande de soutien).

Burnup Chart

Un graphique qui affiche le travail terminé et le scope sur des courbes séparées. Plus facile à interpréter qu'un Burndown en cas de changement de scope, souvent utilisé pour le suivi des plans de release.

MVP et MMP

MVP (Minimum Viable Product)

Le produit minimal nécessaire pour valider une hypothèse. Un concept popularisé par « The Lean Startup » d'Eric Ries.

Exemple MVP de FitLog : « Les utilisateurs ouvrent l'app, enregistrent manuellement leur distance de course et peuvent voir une liste de leurs enregistrements passés. » Pas de graphiques, de notifications ni de social. Cela permet de valider l'hypothèse « Les gens paieront-ils pour une app de suivi d'entraînement ? »

MMP (Minimum Marketable Product)

Le produit minimal vendable sur le marché. Un cran plus riche que le MVP. Le MVP s'adresse aux utilisateurs internes/limités ; le MMP est pour le grand public.

Timebox

Les événements Scrum ont des limites de temps maximales. C'est la timebox.

Effets de la timebox :

• Empêche la dispersion des discussions : Le temps limité force la concentration sur l'essentiel
• Empêche les réunions de s'allonger : Autoriser les prolongations mène à une croissance infinie
• Terminer plus tôt est OK : Si l'objectif est atteint, on peut raccourcir

Spike

Travail en timebox pour explorer une technologie ou résoudre une incertitude. Un terme issu de XP, largement utilisé en Scrum aussi.

Quand l'utiliser :

• « Incertain si cela peut être réalisé avec la nouvelle bibliothèque » → Valider dans une timebox d'1 jour
• « Impossible d'estimer le coût de refactoring de cette partie du code existant » → Investiguer pendant une demi-journée
• « Incertain si la vitesse de réponse de l'API satisfait les exigences » → Créer un prototype

Le livrable d'un spike est la connaissance, pas le code. Le code écrit pour la validation est fondamentalement jeté.

Limite WIP (Work In Progress Limit)

Une règle qui limite le nombre d'éléments travaillés simultanément. Issue du Kanban mais de plus en plus adoptée dans les équipes Scrum.

Exemple : « Maximum 3 éléments simultanément dans la colonne "En cours" »

Effets :

• Focus sur la complétion : Terminer 3 éléments complètement apporte plus de valeur que d'avancer 5 à moitié
• Les goulots d'étranglement deviennent visibles : Là où ça bloque devient clair
• Réduit les coûts du multitâche : Le changement de contexte réduit significativement la productivité

Dette Technique (Technical Debt)

Un concept, proposé par Ward Cunningham, qui utilise la dette comme métaphore pour l'état où vous devrez payer des intérêts (coûts supplémentaires) plus tard parce que vous avez pris un raccourci au détriment de la maintenabilité future.

Types :

• Dette intentionnelle : Implémenté rapidement en sachant « priorité au délai, refactoring plus tard »
• Dette non intentionnelle : Survenant par manque de connaissances ou erreurs de conception
• Dette environnementale : Survenant relativement à mesure que les technologies environnantes vieillissent (legacy)

Autres termes utiles à connaître

Malentendus courants et pièges

« Ne pas écrire de documentation » est une erreur

En interprétant mal « des logiciels opérationnels plutôt qu'une documentation exhaustive » du Manifeste Agile, certaines équipes avancent avec zéro documentation. La bonne interprétation est écrire la documentation nécessaire au fonctionnement.

« Ne pas planifier » est aussi une erreur

Se cacher derrière « l'adaptation au changement » pour abandonner la planification est également faux. Scrum a une planification à plusieurs niveaux (Product Goal, Sprint Goal, plan quotidien). Agile ne signifie pas ne pas planifier, mais planifier de façon adaptive.

Le Daily Scrum devient un rapport de statut

Un Daily Scrum transformé en réunion de rapport de progression pour le PM ou le management a perdu son objectif original. Le Daily est un espace d'inspection et d'adaptation par les Developers, pour les Developers.

La durée du Sprint change fréquemment

Changer pour « cette fois-ci on est chargés, donc 3 semaines » ou « essayons 1 semaine » rend impossible la mesure de la vélocité (vitesse de l'équipe). La durée du Sprint devrait être fixe.

Cas où Agile/Scrum ne convient pas

Ce n'est pas une solution universelle. Dans les situations suivantes, une autre approche peut être plus appropriée :

• Les exigences sont complètement figées et les changements surviennent rarement (ex : conformité réglementaire)
• Les domaines où la sécurité est extrêmement critique et les releases incrémentielles ne sont pas permises
• Quand l'équipe est extrêmement grande et que les coûts de coordination l'emportent

Cependant, des méthodes de mise à l'échelle pour le Scrum à grande échelle (LeSS, SAFe, etc.) existent, il est donc prématuré de conclure immédiatement « trop grand pour ça ».

Résumé

• Agile est un état d'esprit et un ensemble de valeurs. Le cœur est « livrer des logiciels fonctionnels en cycles courts » et « accueillir le changement ».
• Scrum est un framework représentatif pour pratiquer Agile.
• Scrum est composé de « 3 Responsabilités, 5 Événements et 3 Artefacts » et répète des Sprints de durée fixe.
• Copier seulement la forme mène à un rituel vide. Comprendre les valeurs vient en premier, le framework vient après.

L'objectif n'est pas « de faire Scrum » mais « de livrer continuellement des produits de valeur ». Considérer le framework comme un outil pour cela est, je crois, la clé d'une relation durable avec lui.

Références

• Manifeste pour le développement Agile de logiciels
• Scrum Guide 2020
• Jeff Sutherland, « Scrum : L'art de faire deux fois plus de travail en deux fois moins de temps »