Trois cadres dominent la pratique. Ils sont nés à des moments différents, de préoccupations différentes, et chacun a une obsession propre. Les confondre conduit à en attendre ce qu'ils ne promettent pas.
Chacun son obsession
Extreme Programming, formalisé en 1999 par Kent Beck, est obsédé par la qualité technique. Tests d'abord, programmation en binôme, intégration continue, remaniement permanent du code. C'est le plus exigeant des trois, et le seul qui parle vraiment de la façon d'écrire du code.
Scrum, formalisé en 1995 par Ken Schwaber et Jeff Sutherland, est obsédé par le cadre d'inspection. Il ne dit presque rien de la technique. Il installe un rythme, des responsabilités et des rendez-vous qui obligent à regarder la réalité à intervalles fixes.
Kanban, appliqué au travail intellectuel par David Anderson à partir de 2007, est obsédé par le flux. Pas de sprint, pas de rôles imposés : on rend le travail visible, on limite ce qui est en cours, et on regarde où ça bloque.
Trois cadres, trois usages
| Extreme Programming | Scrum | Kanban | |
|---|---|---|---|
| Apparition | 1999 | 1995 | 2007 sur le travail intellectuel |
| L'obsession | La qualité technique | Le cadre d'inspection | Le flux |
| Le rythme | Itérations courtes | Sprints de durée fixe | Flux continu, sans sprint |
| Les rôles | Non prescrits | Trois responsabilités | Aucun rôle imposé |
| Ce qu'il impose | Des pratiques d'ingénierie | Des événements et des artefacts | Deux règles, visualiser et limiter |
| Bon quand | La dette technique étouffe | L'équipe n'a aucun rythme | Le travail arrive en continu |
Ils ne s'excluent pas. Beaucoup d'équipes tiennent un cadre Scrum, des pratiques XP et un tableau Kanban.
Lequel choisir
La question est mal posée, mais elle revient toujours, alors voici une réponse utilisable. Si votre équipe n'a aucun rythme et ne sait pas où elle en est, Scrum apporte le plus vite un cadre lisible. Si le travail arrive en continu et ne se découpe pas en sprints, comme en support ou en exploitation, Kanban est plus honnête. Si le produit croule sous la dette technique, aucun des deux ne suffira sans les pratiques d'XP.
Et dans tous les cas, le cadre ne fait rien tout seul : il crée les occasions de voir. Ce que l'équipe fait de ce qu'elle voit relève de la posture.
Sur les cadres à grande échelle
Nous ne les enseignons pas. Notre parti pris est assumé : avant de faire fonctionner l'agilité sur dix équipes, il faut qu'elle fonctionne sur une. Déployer un cadre d'échelle sur des équipes qui n'ont pas de pratique solide produit une couche de coordination supplémentaire, pas de l'agilité.
C'est un point de vue, pas une vérité, et nous le disons plutôt que de le taire.