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 suites à 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, 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 aussi 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és, de flexibilité mais nous a donc aussi fait perdre la protection apportée par les sprints, cette protection nous permettant de se 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 :

Passer su Scrum au Kanban – Attention à l_éparpillement

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 de 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

 

Publié par

3 réponses sur « Passer du Scrum au Kanban – Attention à l’éparpillement ! »

  1. On commence seulement mais j’ai peur que les travers que tu décris ici nous concerne aussi 😀
    Je vais m’assurer qu’on n’oublie pas les grosses fonctionnalités 🙂

    Aimé par 1 personne

  2. Je valide ce que tu as décrit dans l’article. Pourtant, je veux bien ajouter selon mon expérience par rapport à l’utilisation du kanban :
    *Le planning et la charge quotidiens ne peuvent pas être fixés d’avance => cela demande une réactivité maximale
    *Le regroupement des tickets relatifs à une fonctionnalité doit devenir primordial
    *Les anciennes exigences majeures du client ne doivent pas être oubliées surtout par rapport à l’ergonomie et au métier global
    *Les tests automatiques doivent devenir une nécessité et plus un moyen de réduire le temps
    *Les communications entre les différents départements du projet doivent être sauvegardées
    *Le client doit être présent pour toute clarification

    Pour résumer, avec kanban et ses aventures quotidiennes, il y a un autre goût du travail qui déchire la routine des sprints, essentiellement, si on tient compte des risques

    Aimé par 1 personne

  3. J’ai eu le soucis sur un précédent projet.

    La personne qui vient te ‘parler à l’oreille’ pour te demander de corriger ceci ou cela. Sans formaliser le bug ….

    Pour régler ça nous avons mie en place deux actions :
    1- Un interlocuteur unique => Le scrum master qui fait une première analyse
    2- une réunion une fois par semaine pour prioriser les bugs remontés par le client.En indiquant des délais de livraisons en fonction des dév en cours.

    Comme tu as dit en conclusion, il ne faut pas perdre de vue les fonctionnalités et les évolutions.

    Aimé par 1 personne

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s