Passer du Scrum au Kanban – Attention à l’éparpillement !

Pour la première fois de ma carrière, je travaille en Kanban sur un projet (Je l’avais déjà expérimenté pour de la résolution de bugs).

Nous, l’équipe agile, avons décidé de passer en Kanban notre projet qui fonctionnait très bien en Scrum avec des sprints de 2 semaines. Cette décision, ce risque, a été pris suite à certaines limitations que nous avons rencontrées avec la mise en service de notre application et donc, un changement de contexte.

L’application étant en service, nous avons commencé à avoir des remontées d’utilisateurs, des anomalies, des demandes d’évolutions et d’améliorations de l’ergonomie… Nous voulions répondre rapidement à ces demandes mais le mode projet en Scrum nous limitait à une réactivité allant, au mieux de 2 à 4 semaines.

Nous avons alors choisi de passer en Kanban afin de proposer une meilleure réactivité à nos utilisateurs. Cela était possible grâce à notre chaine de livraison continue permettant de livrer en production sur demande en moins de 30 minutes avec une qualité assurée.

Le passage en Kanban nous a donc permis de :

• Répondre à un besoin utilisateur en moins d’1/2 journée
• Montrer et communiquer sur notre réactivité
• Avoir des fonctionnalités dès qu’elles étaient validées et ne pas avoir à attendre la fin d’un sprint

Tout semblait bien se passer, néanmoins après quelques semaines, nous avons remarqué que certaines études ou grosses fonctionnalités prioritaires n’avancent pas aussi vite qu’elles auraient dû.

Le problème ?

Nous l’avons rapidement identifié, nous passions beaucoup de temps sur des petites fonctionnalités, des bugs utilisateurs, des petites améliorations ergonomiques… Tout ce temps n’était donc pas consacré aux fonctionnalités ou études qui demandaient plus de temps, d’investissement et de concentration… Mais qui apportaient par ailleurs une plus grande valeur ajoutée au produit.

1 petite fonctionnalité qui prend 30 minutes à développer et fait plaisir aux utilisateurs, leur simplifie la vie, c’est bien ! 1 petit bug à corriger en 30 minutes c’est bien aussi ! Au passage, on peut faire un petit changement d’affichage qui prend 30 minutes aussi… Il ne faut pas oublier que 30 minutes c’est le développement, avec l’ajout de la chaine de livraison continue, on arrive aux alentours de 1 heure (ou 1h30 avec les spécifications, la conception et exécution de tests spécifiques) de travail par changement.

Au final on arrivait rapidement à 10-15 heures de travail (10 fonctionnalités) par semaine ce qui fait entre 1.5 et 2 jours de travail par semaine sur des fonctionnalités non prévues initialement… Et bien sûr le temps passé sur ces fonctionnalités est du temps qui n’est pas passé sur les grosses fonctionnalités !

Le passage en Kanban nous a offert plus de liberté, de flexibilité mais nous a donc aussi fait perdre la protection apportée par les sprints, cette protection nous permettant de nous concentrer sur nos grosses fonctionnalités.

Au final, après avoir identifié ce dysfonctionnement, nous avons décidé de faire plus attention aux modifications que nous prenons immédiatement en compte afin d’assurer une bonne évolution des fonctionnalités qui devront façonner notre application.

Nous sommes encore en Kanban mais travaillons beaucoup plus sur la priorité qu’auparavant et faisons encore plus attention à ce que nous ajoutons dans notre liste « En cours ». Nous avons également décidé de réduire le nombre de fonctionnalités simultanées dans la colonne « En cours ».

Si je devais faire maintenant un tableau comparatif entre Scrum et Kanban, je donnerai celui-ci :

En bref, Le Kanban est un outil très pratique pour les applications en production. Néanmoins, si l’équipe n’est pas assez mature elle peut vite se retrouver à travailler sur des détails et oublier les fonctionnalités les plus importantes pour l’évolution de l’application.

Conclusion :

En Kanban, encore plus qu’en Scrum, la faculté de taxonomie du testeur est primordiale. L’équipe se doit d’assurer l’avancement de fonctionnalités consommatrices en temps mais apportant beaucoup à l’application. On peut vite passer des mois à ne faire que des changements mineurs au détriment des développements plus importants. Pour cela il faut, comme en Scrum, bien prioriser et sanctuariser les User Story prioritaires et donc ne pas forcément répondre tout de suite à des retours utilisateurs. Ce n’est pas parce que l’on peut faire un développement rapidement qu’il faut le faire aussi tôt que possible.

Et vous, avez-vous testé ces méthodes ? Quels sont vos retours ?

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles