Scrum ou Kanban? Non! Scrum ET Kanban

J’ai souvent entendu des équipes dire “On a dépassé Scrum, nous sommes passé en Kanban”

J’apprécie beaucoup Kanban, et je pense que c’est une bonne façon de piloter la production de valeur.

Mais, après avoir observé plusieurs équipes qui ont pris ce virage, voici ce que je vois, ou surtout ce que je ne vois pas :

• Pas de Limitation du travail en cours (WIP Limit)
• Des boards Kanban avec seulement 3 colonnes (À faire, En cours, Terminé)
• Des colonnes “Bloqué” ou “En validation” d’où on fait des allers-retours avec la colonne “En cours”
• Aucun calcul de l’âge des items ni encore moins du temps de cycle

Je ne suis pas certain qu’on puisse appeler ça Kanban? En tout cas, il n’y aura probablement pas beaucoup d’optimisation du flow.

Est-ce Scrum le problème ?

Peut-être que ces équipes ne voulaient pas vraiment faire du Kanban, mais qu’elles voulaient juste fuirent des choses qu’elles trouvent contraignantes en Scrum?

Des choses comme :

• Des estimations en heures ou en story-points d’un travail qu’on ne sait pas vraiment évaluer
• Un focus sur la vélocité dans les événements.
• Des Sprint plannings où on cherche à maximiser le nombre d’items dans le Sprint Backlog
• Des reviews où aucun feedback utile n’est remonté et les stakeholders ont plutôt des commentaires sur la vélocité et sur ce qui n’a pas été fait. Des questions du style “oui, mais quand est-ce que tout sera terminé?”

Dans ce cas, j’ai envie de dire aux Scrum Masters de ces équipes, courage, et au lieu de laisser l’équipe se sauver en un semblant de Kanban, prenez donc le temps de corriger votre Scrum.

• Il n’y a rien en Scrum qui oblige à faire des Story points ni même des estimations.
• Le Sprint backlog n’est pas obligé d’être complètement figé au début du Sprint.
• On peut faire du Scrum sans utiliser la vélocité.
• Ne pas parler de vélocité à la Sprint Review, mais plutôt de valeur, d’objectifs, de retours utilisateurs. Montrer des KPI produits.
• Encourager les discussions sur ce qui est intéressant à faire ensuite plutôt que de combien de temps ça a pris pour faire ce qui est là.

Scrum est là pour créer un cadre soutenant pour les équipes, non pas pour la stresser et presser le citron. Assurez vous d’utiliser Scrum comme un outil de gestion de produit plutôt qu’en mode gestion de projet. Sortez du micromanagement du temps, donnez une vraie autonomie et ayez confiance en l’équipe et alors les développeurs et développeuses ne se sentiront plus contraints par Scrum.

Faut-il vraiment choisir entre les deux?

Et est-ce que ça veut dire qu’il ne faut pas faire du Kanban?

Au contraire. Nous ne sommes pas obligés de faire un “OU”, c’est-à-dire soit Scrum OU soit Kanban. Il est tout à fait possible de conserver les bienfaits de Scrum, et de les combiner avec l’optimisation de flow de Kanban.

Je garde de Scrum :

• Avoir un objectif de Sprint qui permet un focus pour le Sprint et de favoriser le travail en équipe sans prédéfinir à l’avance tout ce que l’équipe devra faire,
• Des dailys pour créer une vraie entraide entre les développeurs·euse·s,
• Une définition de terminé qui apporte de la transparence et rend explicite la qualité de notre produit,
• La Sprint review pour se sortir la tête de notre bulle de développement une fois à toutes les fins de Sprint et prendre contact avec les parties prenantes et les utilisateurs du produit,
• Les rétrospectives qui permettent à temps régulier de parler de parler de sujets variés comme les processus, les relations entre personnes, le flow de travail

Je prends Kanban pour :

• Optimiser le flow de valeur grâce aux métriques de Cycle Time, et Throughput,
• Apporter de la transparence sur l’avancement en représentant clairement notre définition de terminé dans le workflow,
• Arrêter de faire des estimations, faire du right-sizing, apporter de la valeur en continu (Flow),
• Une vrai auto-organisation du travail par l’équipe

Pour en savoir plus sur la combinaison Scrum ET Kanban, je vous invite à lire le guide “Scrum with Kanban” disponible en plusieurs langues.

Vous pouvez aussi jeter un oeil sur l’article “Améliorez votre pratique de Scrum en y intégrant des pratiques Kanban !” de ma collègue Sabrina de Pyxis Suisse :

En espérant que vous pourrez profiter du meilleur des deux mondes.

Scrum On!

Christian