SFEIR, la métamorphose Agile

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