Pour entamer ma journée au ScrumDay, et parce que je n'avais pas encore pu
assouvir ma curiosité sur les principes Kanban, je me suis rendue à la
conférence Scrum et Kanban, tirer le meilleur des deux, animée par
Antoine Vernois, le renommé Claude Aubry et Fabrice Aimetti. Présentation
plutôt interactive avec passage de témoin entre les 3 animateurs, mais qui a
parfois manqué de peps. ROTI 3/5.
Le pitch : Scrum est la méthode agile la plus populaire. La
transition à Scrum représente souvent un changement radical pour certaines
organisations. Venant directement du Lean, le Kanban appliqué au développement
de logiciel s’affirme comme une pratique alternative intéressante, en
particulier pour les activités de support. La présentation, faite par les
traducteurs du minilivre de Kniberg et Skarin, montre comment tirer le meilleur
de Scrum et Kanban, selon le contexte.
Scrum et Kanban sont toutes les deux des méthodes Agiles, basées sur l'empirisme (mode itératif), Scrum étant plus cadré, Kanban plus ajustable. Chaque itération se décompose ainsi :
- Planifier (au plus près du début de Faire car il est facile d'estimer ce qui peut être fait dans la période immédiatement à venir),
- Faire (en projet informatique, Scrum s'adosse souvent à XP - eXtreme Programming)
- Livrer (avec revue de sprint),
- Améliorer le processus (Kaizen, Inspection et Adaptation : feedback et rétrospective)
...et reprendre au début.
Les différences majeures entre les deux méthodes sont :
- d'abord la fréquence différente des actions listées
ci-dessus :
quand Scrum impose un enchainement de l'ensemble de ces tâches, Kanban
permettra de planifier chaque action à des fréquences différentes (et qui
resteraient logiques, ex : livrer chaque semaine, planifier tous les 15
jours, rétrospective tous les mois)
- ensuite la gestion du périmètre du sprint :
Scrum aurait tendance à vouloir se conformer au périmètre initial du
planning, tandis que Kanban permettrait le remplacement d'une tâche par une
autre (si équivalente en terme de complexité et si non entamée) en cours
d'itération et selon la priorisation
- - puis la gestion du taskboard :
réinitialisé à chaque itération Scrum via le planning game, il est en Kanban
plus simplement conservé et alimenté au fil de l'eau. Cependant, pour conserver
un volume "à faire" stable par itération, en Kanban, des règles de limitation
de l'en-cours sont mises en place pour que le stock de chaque état d'en-cours
soit fluide et ne risque pas de devenir un point de blocage. On en profite pour
rappeler que les tâches doivent traitées intégralement (état "done").
La gestion des perturbations :
Nos 3 animateurs conseillent Scrum pour une équipe projet qui est ainsi,en
cours d'itération, à l'abri de toute perturbation extérieure (impactant la
prochaine itération), tout en recommandant plutot Kanban pour les équipes de
support ou opérationnelles : la gestion des perturbations est prévue
(impact immédiat).
Dans le cas d'une équipe gérant plusieurs projets, le taskboard est unifié. Des
codes couleur ou des couloirs peuvent être mis en place, et les sprints
successifs seront :
- en Scrum, composés de tâches d'un seul projet, pour éviter les perturbations liées au switch de projet/de produit
- en Kanban, composés à l'envi, mais de façon équilibrée, de tâches d'un seul
ou de plusieurs projets selon les priorités.
Le parallèle entre ces deux méthodes finit par nous mener à la conclusion
logique : il faut adopter la méthode choisie à la réalité du
projet.
Antoine Vernois, Claude Aubry et Fabrice Aimetti concluent par ces quelques assertions :
Soyez agiles pour la mise en oeuvre du projet
Essayez les choses par vous même
Ne soyez pas trop dogmatiques
Soyez et restez Agiles