Scrum et Kanban, tirer le meilleur des deux

Première conférence de la journée #scrumday organisée à l’espace conférence de microsoft.
Les locaux sont sympas, wifi gratuit.

Cette session fait partie de la track pratiques agiles, elle est animée par Antoine Vernois, Claude Aubry, Fabrice Aimetti.

Les présentateurs portent chacun un T-Shirt à l’effigie de la méthodologie qu’ils vont défendre, le premier porte un T-shirt kanban, le second Scrum et le dernier scrumban.

J’ai choisi cette présentation car j’ai travaillé sur des projets scrum et fait du support via kanban, mais je souhaite voir ce que les deux combinés peuvent apporter.

Scrum, diviser pour maitriser

L’idée de base est de couper en petits bouts un produit (Product).

• découper les équipes,
• découper le produit en petites fonctionnalités (User stories),
• découper le temps (Sprint),

Au final, une équipe réalise une fonctionnalité composant un produit lors d’une itération

Kanban, observer l’ensemble

Le Kanban est un mode de gestion des flux créé par l’industrie automobile japonaise (Toyota).
Terminer ce que l’on commence
Il faut limiter le nombre de tâches en cours, pour éviter les goulets d'étranglements dans certaines étapes du workflow.

Les deux sont agiles

Les deux méthodes sont agiles, même s’il y a des différences de mises en oeuvre.
Scrum est plus strict que Kanban, par exemple dans la méthode kanban les colonnes du tableau sont modifiables pour coller au mieux à l’organisation, scrum ne le permet pas.
Avec kanban on peut également ajouter une nouvelle tâche à condition de prioriser à nouveau les taches a faire en fonction des limites par colonne que l’on s’est fixé.
Avec Scrum, il est en théorie impossible d’ajouter un tâche à faire en cours de sprint, il faudra attendre le début du prochain, voir la comparaison avec une machine à laver

Réaction aux perturbations

Scrum : niet, attendre la fin du bloc de temps pour que ce soit pris en compte, quelque fois on peut pas dire non (manager), alors négocier pour sortir une autre item à la place moins prioritaire
Kanban : différent : ajout dans la colonne à faire, donc si limite dépassé alors priorisé, si des choses sont en cours, alors il faut d’abord finir l'étape associé à l’item

Les cérémonies agiles

Scrum : les cérémonies s’enchâinent toujours de la même façon

Planification / sprint / revue de sprint / rétrospective, livraison et enchainement sur le sprint suivant.

kanban

La livraison est sur demande (à la fin d’une tâche par contre).
Pas de début et de fin d’itération.
Des rétrospectives sont planifiées toutes les 4 semaines.

scrumban : jouer sur les rythmes

En mêlant les deux méthodologies, on peut assouplir le process Scrum :

Ne pas systématiser les rétrospectives à cheque itération.
Désynchroniser le processus de livraison, en faisant du déploiement continu.

Tableaux agiles

Si une seule équipe

kanban : Si une seule équipe : mais différents produits (identification par couleur ou par couloir)
scrum : Soit un seul produit en même temps soit un mélange des deux, mais si le temps de switch d’un produit à l’autre est couteux, alors on privilégiera une séparation par sprint.

Les colonnes :

scrum : colonnes imposées (A faire, en cours, fini = états du workflow) et row / story
kanban : colonnes non imposées (possible de s’inspirer de scrum), a adapter en fonction des besoin

technique d’estimation et planification

Scrum : faite par l'équipe en jour et heure, mais toujours difficile d’estimer, sans être dans le concret.
alors on utilise des points plutôt que des points
Story = on utilise des points relatifs
taches ; pas d’estimation en heure, on va suivre juste le nombre de tache

kanban : pas de taches, juste des éléments apportant de la valeur
Culture de produire des éléments de même taille (vision industrielle)

Indicateurs

Scrum : le burndown chart permet de voir si l’on va tenir ses engagements, vélocité : permet de faire des product release en fonction des nombres de point / story et du produit

kanban : diagramme de flux cumulé, en fonction des limites des tâches par colonnes que l’on s’est fixé, on pourra réduire le temps moyen qu’une tâche met pour être terminée

Conclusion

Plutôt d’opposer les deux méthodlogies, il faut essayer de tirer le meilleur de deux.
Il est possible de sortir du cadre strict de scrum ou de Kanban

Ne soyez pas dogmatique
Il faut essayer/pratiquer pour voir ce qui fonctionne dans l’entreprise et dans vos équipes

Soyez agiles, Soyez agiles, Soyez agiles !

Ma conclusion

Finalement un peu déçu, car la conférence a fait une brève introduction des deux méthodologies Scrum et Kanban, on n’atteint pas l’objectif donné par le titre de la conférence, tirer le meilleur parti des deux.

Les intervenants connaissent leur méthodologie, mais çà manque de retours d’expérience sur le mélange des deux.

Je reste cependant d’accord avec la conclusion, on doit pouvoir se permettre de sortir du cadre strict d’une méthodologie et essayer, itérer pour améliorer le processus.

En savoir +

Scrum et kanban, tirer le meilleur parti des deux