Par les temps qui courent et avec le développement du DevOps, la tentation est de vouloir aller toujours plus vite. Mais est-ce bien toujours ce que le client demande ?
La pratique régulière de la voix du client (donnez-moi exactement ce que je veux, quand je le veux, où je le veux, soyez fiables, ne me faites pas perdre mon temps) aide à se fixer les bons objectifs. En effet, à quoi bon s’améliorer là où le client ne nous attend pas ?

Ceux qui pratiquent l’agilité avec succès le savent : il faut fournir la valeur attendue par le client au bon moment. Ceux qui cherchent à éliminer les gaspillages vous diront que produire de la valeur trop tôt est au minimum de la surproduction et pourra même aboutir à des retouches si le client affine sa vision de la valeur entre temps.

Alors pourquoi chercher à réduire le délai sans tenir compte de la voix du client ? L’une des explications est le « time to cash » : on est payé lorsqu’on livre et à la limite, peu importe si le client n’est pas tout à fait prêt… Il n’a qu’à se dépêcher un peu.
On aboutit dans ce cas à des projets de déploiement qu’on voudrait imposer en 6 semaines au client, là où sa roadmap s’étalait sur 18 semaines. Ladite roadmap s’étalait sur 18 semaines pour une bonne raison : il veut vérifier la faisabilité de son idée, la développer, vérifier sa bonne intégration à son système d’informations, faire ses tests d’industrialisation puis enfin, déployer en production. Ce que le client attend dans ce cas est que son fournisseur lui mette à disposition exactement les briques dont il a besoin précisément toutes les 3 semaines. Il n’attend certainement pas qu’on lui mette le couteau sous la gorge pour qu’il se lance dans la transformation de son organisation afin de faire en 6 semaines ce qu’il souhaite faire en 18 !

On voit dans cet exemple que les défis lancés au fournisseur sont d’être à l’heure aux rendez-vous fixés par le client, de ne pas le retarder avec une mauvaise qualité, de ne pas l’importuner pour notre seul bénéfice et de ne pas lui faire perdre son temps en le désorganisant avec tout ce qui précède. Objectif bonus du fournisseur : produire avec le minimum de gaspillages pour réduire ses délais et ses charges. Bénéfice collatéral : la charge de pilotage d’une organisation qui livre en flux tiré est allégée au profit de la résolution de problème et de l’amélioration continue. Rien à voir avec l’accélération pour la beauté du sport !

On est payé lorsqu’on livre et l’essentiel est de passer l’étape du PV de recette, même avec réserves. Le client n’a qu’à mieux spécifier, mieux « recetter », et surtout le faire vite à défaut de le faire bien. De toutes façons, passés les 2 mois contractuels de validation du service rendu, tout ce qui devra être corrigé sera facturé une deuxième fois, soit en bug non détecté dans les temps, soit en évolution. Notons bien que dans ce cas, le client est souvent une victime consentante, préférant la non qualité immédiate à un effet tunnel bien plus angoissant. Traduction : si on doit corriger une chose, c’est qu’au moins elle existe !
A ce titre, j’ai récemment été témoin des dérives de la recherche déraisonnable d’une réduction du délai de fabrication.
Une équipe de 7 développeurs en mode Scrum était chargée de réaliser des User Stories pour son client. Objectif de chaque sprint d’un mois : moins de 50 bugs par sprint… Autant d’épingles plantées dans les poupées vaudou de Jeff Sutherland et Ken Schwaber. Sur le dernier sprint livré, ils étaient « à la cible » avec seulement 48 bugs.
Sur les 7 développeurs, 4 codaient pendant que les 3 autres (toujours les mêmes d’un sprint à l’autre) corrigeaient les bugs du sprint précédent, donc en mode « I build it, you run it« . N’importe qui découvrant la situation depuis l’extérieur de l’équipe identifiait immédiatement que son problème n’était pas la vitesse, mais la qualité. En effet, en plus de ses US, l’équipe produisait environ un bug toutes les 3 heures ouvrées ou 12 bugs par développeur et par sprint. Malheureusement, quand l’équipe n’a pas mis en place de bacs rouges et que les rétrospectives sont bâclées, on décide de lui ajouter un développeur pour livrer plus vite.
Sur la release suivante, le nombre de bugs identifiés fut de… 60 ! Situation nominale : 5 développeurs x 12 bugs par sprint. Dans un ultime sursaut désespéré, le Directeur des Opérations ajouta un développeur pour corriger les bugs, faisant passer l’équipe à 9 personnes. Il fut remercié 60 bugs plus tard.

La conclusion de ces 2 exemples est que la recherche du délai le plus faible pour elle-même n’a pas de sens économique, pas plus pour le fournisseur que pour le client : c’est le client qui donne le rythme,, épissetou ! Elle doit être précédée d’une étude minutieuse des attentes du client et de la qualité à chaque étape de la  fabrication. L’IT ne fait pas exception à cette nécessité, bien au contraire ! Une fois les attentes du client identifiées et la qualité obtenue, le sujet n’est probablement pas le délai, mais plutôt la durée du touch time (le temps durant lequel l’on travaille effectivement sur la pièce) et la vitesse d’exécution.

A moins bien sûr d’être en capacité de vendre au client les moyens d’aller plus vite sur ses propres livrables : le fournisseur qui intègre son client. En voilà une innovation !