Qu’est-ce qui vous a poussé à choisir la méthode Kanban pour vos projets ?

Dimitri Baeli : Avec Kanban nous supprimons les itérations courtes, à l’inverse de Scrum et de ses sprints où nous avions un mois pour réaliser un lot de fonctionnalités fixées. L’intérêt et la volonté étaient de livrer plus souvent, mais surtout de pouvoir lisser la prise de commande de nouvelles fonctionnalités tout au long de la semaine, et non à date fixe.

La lecture du livre The Principles of Product Development Flow de Donald G. Reinertsen et Continuous Delivery : Reliable Software Releases through Build, Test, and Deployment Automation de Jez Humble et David Farley ont changé ma vision de l’organisation des développements.

Faire des lots les plus petits possibles et les livrer dès qu’ils sont prêts est devenu mon objectif, en rupture complète avec les pratiques normalisées de Scrum et autres planifications à date. La date quotidienne est fixe, la taille des équipes également, il reste donc simplement à se concentrer sur le contenu. En fixant le délai et le coût, nous pouvons nous concentrer sur le contenu et la qualité du produit. C’est le réel changement : adapter le contenu à la capacité des équipes, et pas le contraire.

Quels sont les points positifs que vous avez retenus de l’application de Kanban chez LesFurets.com ?

Dimitri Baeli : J’ai pu observer plusieurs améliorations dans nos équipes et dans le déroulement de nos projets :

  1. Une stabilisation du rythme des équipes : fini le rush de fin de sprint, moins de stress lors des releases.
  2. Beaucoup moins de dialogues de sourd sur la planification des releases, dead lines et estimations. Cela disparait presque…
  3. Une bien meilleure observation de l’existant en production et moins de plans basés sur un futur produit. La clef est que chaque fonctionnalité est maintenant un incrément fonctionnel indépendant sur la production, contrairement au découpage en lot d’une release.
  4. Une fonctionnalité bloquée ou qui prend du retard n’empêche pas une release
  5. Un réel état d’esprit de commencer par finir : regarder le tableau Kanban par la droite et se dire : « Que dois-je finir pour commencer autre chose : »
  6. Une compréhension de l’intérêt de limiter l’encours de travail, demander toujours plus ne fait pas avancer plus vite.

Quels sont les limites du kanban dans l’IT selon vous :

Dimitri Baeli : Je vois peu de limites dans l’IT actuellement.

Si cette question concerne la limite de couverture de Kanban sur les besoins de l’IT, ou les domaines, je dirais que Kanban est une méthode de livraison de valeur en continu, qui est très orientée production/fabrication : « do the things right and fast ». Elle manque cependant d’une dimension produit.

Côté management c’est plutôt la capacité de l’organisation à s’adapter à ce changement de paradigme qui peut poser un problème et quelques appréhensions. Ceci dit, ce problème n’est pas exclusif à Kanban.

Quels sont les avantages de la mise en place du Kanban vis-à-vis des méthodes agiles ?

Dimitri Baeli : Même si l’état d’esprit reste très proche, je vois quatre grandes familles de pratiques et de méthodes complémentaires :

  • Software Craftmanship & Clean Code : travailler proprement le code
  • Scrum : une standardisation et popularisation de l’agilité
  • Kanban : standardisation du travail en flux
  • Lean : standardisation de l’avantage compétitif à s’appuyer fortement sur la satsifaction des clients et l’amélioration continue sur le terrain

L’agilité vient pour moi en opposition au Waterfall (one big piece) qui ouvrait une collaboration sur les spécifications d’un ensemble.

Scrum a permis la collaboration avec le client sur la base d’un produit fini (working software, welcome change) avec une solution qui marche bien.

Kanban quant à lui peut être vu comme l’étape suivante d’une ouverture sur l’amélioration continue de l’organisation sur la base d’une pratique qui révèle les limites. Lean constitue encore une étape supplémentaire pour une organisation qui apprend.