Auteur : Nick Oostvogels (@NickOostvogels)
Source : 5 arguments against Kanban
Date : 29/06/2011

Traducteur : Fabrice Aimetti
Date : 03/07/2011

Traduction :

disagree.jpg

A chaque fois que vous songez à utiliser Kanban pour gérer vos flux de valeur, vous entendrez des arguments cinglants contre cette pratique. Ceci est normal et n'est pas lié à Kanban, cela arrive à chaque initiative de changement. J'ai compilé une liste de questions et d'arguments auxquels j'ai dû faire face lors de l'introduction de Kanban et je propose quelques moyens d'y répondre.

1. Il faudra plus de temps !


Les gens craignent que si l'on passe à un modèle de flux continu, sans timeboxes ou itérations, le travail prenne plus de temps au final. Après tout, la plupart des managers ont entendu parler de la loi de Parkinson qui stipule que le travail se développe de façon à remplir le temps disponible pour son achèvement.

C'est une préoccupation légitime. Une équipe moyenne aura des difficultés à se concentrer fortement autant qu'ils l'auraient fait dans un cycle itératif où il y a toujours une démo qui se prépare dans un proche avenir. Heureusement, il existe des moyens de travailler dans un flux continu et de toujours conserver une grande concentration. Par exemple, vous pourriez mettre en œuvre une cadence. Toutes les x semaines, nous faisons une démo à nos parties prenantes. Quoique vous ayez terminé à cette date, cela leur sera montré. Nos mesures seront utilisées pour définir les besoins. Si vos parties prenantes savent qu'en moyenne vous livrez 6 features par semaine, ils s'attendront à voir six features terminées lors de la démo hebdomadaire.

Une autre façon de stimuler la concentration est de visualiser la tendance de votre moyenne de lead time ou de temps de cycle. Lorsque le temps moyen est en hausse, quelque chose cloche et nous pouvons inspectez l'ensemble. Lorsque le temps moyen est en baisse, l'équipe est sur sa lancée et gagnera encore plus d'énergie en visualisant son travail.

Conclusion : des équipes très mûres garderont leur concentration d'après mon expérience. Nous pouvons aider des équipes de maturités basses et moyennes à se concentrer en utilisant des techniques telles que la cadence ou la visualisation.

2. Nous perdons notre capacité à planifier


Passer de l'estimation à la mesure déclenchera toujours cette réaction. Comment pouvons-nous prendre des engagements pour nos clients si nous n'avons pas d'estimation sur l'effort ?

La vérité c'est que rien n'a vraiment changé. En Agile, nous utilisons déjà la vélocité comme une mesure pour corriger notre planning. En Kanban, nous utilisons des mesures pour planifier.

Bien entendu, vous devez être en mesure d'extrapoler vos premières mesures pour créer un planning de livraison que vous pouvez régulièrement faire coller à la réalité. Il y a deux façons simples de faire cela. Découpez toutes les features de sorte qu'elles aient plus ou moins la même taille, ou attribuez-leur un poids relatif.

De cette façon, vous pouvez utiliser vos mesures de lead time moyen ou temps de cycle moyen pour calculer le temps nécessaire qu'il faudra pour terminer les fonctionnalités restantes de votre prochaine version.

3. Coûts élevés de refactoring de l'architecture


Si nous tirons une feature à la fois, personne n'aura le temps de penser à l'architecture du système et se contentera juste de construire au-dessus de l'existant.

Cet argument ne proviendra probablement pas d'une équipe Agile, car elle connaît déjà la faisabilité d'une architecture émergente. Ce n'est pas moins différent dans un modèle de flux que dans un cycle itératif. Des tâches techniques doivent être prévues dans chaque feature et le refactoring est un effort continu. Je ne dis pas que c'est facile, mais vous pouvez apprendre à le faire.


4. Les choses vont rester coincées, nous ne pouvons pas garder les limites de TAF (NdT Travail à faire)


Quand vous êtes porteur du message que seulement x features pourront être traitées et que les limites ne peuvent pas être dépassées, les gens commencent à paniquer. Ils savent par expérience que certaines features restent en cours pour une longue période parce qu'ils attendent quelque chose qui est en dehors de leur contrôle. L'idée de respecter la limite et de faire autre chose ne remet pas en cause nos croyances et la façon dont nous avons été élevés. Vous devez rester occupé tout le temps et faire de votre mieux !

Par contre ! Dans le cas d'un système à flux tirés comme Kanban, respecter les limites de TAF est une chose puissante. Si vous êtes coincé et ne pouvez pas démarrer une nouvelle tâche, un peu plus tard, le poste de travail aval va rester coincé aussi et ainsi de suite. Cela crée un problème immédiat pour l'ensemble du système, et ne se limite plus à vous seul. C'est sûr que les limites de TAF seront inconfortables au début, mais elles vont déclencher une action rapide ! Ensemble, vous allez trouver un moyen de désengorger le système et de terminer le travail, au lieu de simplement commencer une autre tâche et de ne rien finir.

5. Nos parties prenantes ne se soucient pas d'alimenter le flux


Elles veulent que toutes les features soient livrées aussi vite que possible.

Dans cette situation, allez à la cause racine. Pourquoi ne se soucient-elles pas de prioriser la file d'entrée ? Elles n'ont probablement pas vu la valeur que cela créait. Elles n'ont peut-être jamais eu la possibilité de changer et de s'adapter lorsque le développement commençait. Expliquez-leur que le planning est obsolète immédiatement après avoir été créé en raison de nouvelles idées, des changements de situation du marché, etc. Certaines features ne sont pas si urgentes que ça, tandis que d'autres peuvent devenir plus importantes. Être capable de changer rapidement le périmètre de votre prochaine version vous donne un énorme avantage concurrentiel parce que vous êtes en mesure de répondre aux attentes des clients avec plus de précision.

C'est la liste de mes cinq arguments contre Kanban et quelques options pour y répondre. Si en vous connaissez d'autres, je suis très intéressé.