Agilité, Scrum et Kanban

Pourquoi l’agilité

Imaginez la refonte du site d’une boulangerie menée « d’un bloc » : trois mois de cahier des charges, trois mois de réalisation, puis une livraison finale. Au moment de la mise en ligne, on découvre que la commande de gâteaux en ligne, jugée essentielle au départ, intéresse peu les clients, alors que tout le monde demande les horaires des jours fériés. Six mois de travail, et un retour client qui arrive trop tard.

Une démarche agile inverse la logique : on livre tôt une première version utile, on observe l’usage, on ajuste la suite. Le Manifeste agile (2001) résume cet état d’esprit : les individus et leurs interactions, un produit qui fonctionne, la collaboration avec le client et l’adaptation au changement passent avant les processus, la documentation exhaustive, la négociation contractuelle et le suivi d’un plan figé. Ces derniers gardent de la valeur, mais moins que les premiers.

Scrum

Scrum est le cadre agile le plus répandu. Il découpe le temps en sprints de durée fixe, un mois au plus (souvent deux semaines). Chaque sprint produit un incrément utilisable.

Trois responsabilités :

• le Product Owner maximise la valeur du produit : il tient et ordonne le Product Backlog et tranche les priorités ;
• les Developers (toutes les personnes qui réalisent : développement, design, rédaction, tests) construisent l’incrément et s’organisent eux-mêmes ;
• le Scrum Master aide l’équipe et l’organisation à appliquer Scrum et lève les obstacles. Ce n’est pas un chef de projet qui distribue les tâches.

Cinq événements :

1. le Sprint lui-même, qui contient tous les autres ;
2. la planification du sprint : pourquoi ce sprint (objectif), quoi, comment ;
3. la mêlée quotidienne (Daily Scrum), 15 minutes pour les Developers ;
4. la revue de sprint : on montre l’incrément aux parties prenantes et on adapte le backlog ;
5. la rétrospective : l’équipe améliore sa façon de travailler.

Trois artefacts : le Product Backlog (liste ordonnée de tout ce qui pourrait améliorer le produit, avec l’objectif de produit), le Sprint Backlog (l’objectif du sprint, les éléments choisis et le plan pour les réaliser) et l’Incrément, qui doit respecter la Definition of Done (définition de « terminé »).

Kanban

Kanban part du travail tel qu’il se fait aujourd’hui et l’améliore progressivement. Ses pratiques :

• visualiser le flux sur un tableau : une carte par élément, des colonnes par étape (À faire, En cours, En revue, Terminé) ;
• limiter le travail en cours (WIP, work in progress) : par exemple trois cartes au plus dans « En cours ». Quand la colonne est pleine, on termine avant de commencer ;
• gérer le flux : on mesure le temps de cycle (du début à la fin d’une carte) et le débit (cartes terminées par semaine) ;
• rendre les règles explicites (que signifie « En revue » ?) et améliorer en continu.

Kanban n’impose ni sprints ni rôles : les cartes entrent dans le flux dès qu’il y a de la place.

Lequel choisir ?

Situation	Plutôt
Construire un nouveau produit ou une refonte, par étapes	Scrum
Flux continu de demandes imprévisibles (support, maintenance, petites évolutions)	Kanban
Équipe débutante qui a besoin d’un cadre et d’un rythme	Scrum
Équipe qui veut d’abord rendre visible et fluidifier son travail actuel	Kanban

Beaucoup d’équipes combinent : sprints Scrum avec un tableau limitant le travail en cours. L’essentiel est de livrer souvent, de rendre le travail visible et de s’améliorer régulièrement.