Qui a encore changé le système métrique

Un appartement familial tranquille. Tout à coup une partie  du plafond s’effondre. A y regarder de plus près, le trou est un cercle quasi parfait, scié depuis le dessus . Descendent un, deux puis trois agents du Central Service. Déjà,  ils ont fait prisonnier le père de famille et font signer le reçu à sa femme abasourdie. Il y est écrit « Archibald Buttle, terroriste ». Tout le monde s’en va. Des nettoyeurs placent immédiatement une pièce prévue pour exactement boucher le trou parfaitement circulaire.  Elle tombe. « M…. ils ont encore changé le système métrique »…

Evidemment nous sommes dans Brazil.  C’est pourtant bien comme cela que sont ressenties certaines métriques dont la finalité reste trouble surtout si votre management se sent jugé ou pire vous juge en fonction de telle ou telle métrique. ( article à venir )

Voici 3 questions que je me pose chaque fois que je pense à une métrique.

1. La métrique mesure t’elle une processus à priori pertinent. Le processus qu’elle mesure est il bien pensé (« je pense et puis je suis » ): Est t-il toujours d’actualité, rejoint il la vision  déclinée en stratégie de l’organisation ?

2. Contribue t’elle à optimiser la chaine de développement  de bout en bout.  Gare aux optimisations locales.

3. Est-elle suffisamment précise pour être utilisée pour prendre des actions par les  personnes qui travaillent suivant le processus mesuré.

4. La métrique permet elle de travailler par itération courte. Walter Shewart a inventé en 1939 le PDCA ( Popularisé par Deming) pour réussir par itération successive à modéliser plus aisément des  phénomènes électriques. Une itération n’a de sens que si elle est en rapport avec ce que l’on cherche à améliorer, donc au delà de quelques semaines, il y a de grande chance que d’autres phénomènes polluent le résultat. Méfiez vous de « lessons learnt » sur des projets waterfall de plusieurs années.

Evidemment on est pas toujours celui qui décide de tel ou tel métrique. et il est parfois difficile voire parfois considéré comme suspect une invitation à revoir telle ou telle métrique.

Une de fois de plus retour à la suprématie du pourquoi décrit par Simon Sinek.

L’unique finalité acceptable d’une métrique est d’aider l’organisation à améliorer sa façon de travailler.

La mesure est un processus qui n’échappe pas à cette règle, donc une bonne métrique est une métrique qui sait prendre en compte le feedback.Ce dernier point fait partie de ce qu’est une bonne métrique. Voici donc le 4ème principe, la métrique s’améliore et s’adapte.

Publicités

Y a t il un pilote dans l’avion ?

Si VOUS ÊTIEZ CE PILOTE.

Où mieux vaut il faire attendre votre avion ?

1. Sur le tarmac avant le décollage,
2. Dans le ciel avant l’atterrissage.

Il y a fort à parier que vous choisirez le choix 1, non ?..

Fort heureusement, les courts et moyens courriers ne décollent généralement que lorsque leurs créneaux d’atterrissage sont libres.

Poussons un peu plus loin: qui est le client final ? le passager.

Ensuite on peut envisager une meilleure compagnie qui fait attendre les personnes dans l’aéroport plutôt que dans l’avion voire même les informe pour qu’ils ne viennent à l’aéroport que lorsque l’avion est sûr de pouvoir partir.  Bien entendu cette compagnie répercute l’économie liée à la libération des salles d’attentes sur le prix du billet. Je ne sais pas si une telle compagnie existe (cela m’intéresserait beaucoup de le savoir) mais cela est sans doute atteignable, est-ce pour autant la perfection?

Non car dans tout ces scénariis, il y a toujours de l’attente qui s’ajoute à un temps « utile » de trajet lui même non instantané:

Commençons donc par la Mauvaise nouvelle, la téléportation individuelle immédiate d’un point un autre ce n’est pas pour demain. Il faut donc des avions et ces avions sont de plus en plus gros car la ressource la plus rare, c’est l’encombrement du ciel et le kérosène. L’avion privé (lot de petite taille) offre certes un meilleur temps de cycle mais cela reste réservé à une minorité et ces avions partagent le même espace aérien saturé sans parler du kérosène.

La bonne nouvelle: En tant que client, nous comprenons et souhaitons le meilleur compromis.

J’utilise en cours Kanban cette allégorie  très simple à partir du livre Donald Reinertsen dans « The Principles of Product Development Flow: Second Generation Lean Product Development « ,
L’ayant lu en un weekend deux ans après sa sortie, cela reste avec du recul l’un des meilleurs ouvrages que je connaisse sur la gestion des files d’attente en développement.

En effet, même si j’admets (avec scepticisme) que cela puisse être différent dans d’autres domaines, cela colle (en simplifiant à l’extrême bien sur) à mon expérience en R&D dans des entreprises innovantes: Il n y a jamais assez de personnes suffisamment compétentes pour réaliser complètement toutes les idées du marketing, des standards, de la compétition parfois même celles du client.  Au pire, il est difficile d’honorer en temps et en heure l’ensemble des contrats négociés par, disons…, une force de ventes parfois volontariste ( Métier qui a aussi ses difficultés ). Il va de soi que la « ressource » critique est ici la compétence en qualité et quantité. C’est un fait.

Une bonne gestion des files d’attente permet toutefois d’améliorer grandement et le temps de cycle (temps entre la commande ferme et facturation après livraison) et la productivité donc d’augmenter largement le retour sur investissement dans votre entreprise.

Donc finalement c’est un sujet plus sérieux que son titre?  Peut-être pas,  je considèrerais comme sérieux l’absence d’une ou d’un pilote qualifié sur mon prochain vol.

Qu’apporte ce livre ?

Évidemment, Donald explique en quoi nos développements produit et particulièrement logiciel obéissent aux règles universelles des files d’attente. Il explique bien en quoi la variance (heureux que le parallélisme avec les avions n’aille pas jusqu’à là) fait partie intégrante de l’activité d’innovation.

Le chapitre sur l’impact de l’innovation sur la  variance et sa possible réduction par une bonne gestion des files d’attente, apporte un réel ballon d’oxygène en apportant des débuts de solution à l’épineux problème de prédiction dans l’innovation.  En fait je n’ai rien lu de mieux depuis que la baguette magique est tombé dans un puits sans fond.

Il réussit ensuite une analogie quasi parfaite ( le quasi étant lié à l’humain donc ce n’est pas un détail) avec les flux de donnée transitant en permanence et avec grande fluidité sur internet. Et pourtant contrairement à internet, il montre comment nous utilisons des algorithmes qui ressemblent plus à ceux des années 50 dès lors qu’il s’agit de réguler des processus de production de valeur.

La première partie est classique à qui connais kanban: Cela consiste à mettre en évidence ces files d’attentes. Simple mais assez rarement fait. ( un peu de pub pour les coach Lean et Agile qui ont une bonne habitude la dessus )

Le chapitre sur la taille des lots ( batch size) est rafraîchissant et restitue l’intérêt et les limites de la découpe des exigences en Epics, Stories Tâches voire en grande échelle des granularité supplémentaires (je reste persuadé là aussi qu’un bon coach sait aider les équipes )

En se focalisant non plus sur toutes les files, mais sur le coût (economics) lié à ces files, Donald montre quelque chose qui peut paraitre aussi simple que l’image des avions: Pourtant si en amont vous avez un carnet de commande plein à craquer (bonne nouvelle) et que ces client ont de bonnes raisons d’être impatients (vous êtes une source potentielle de file d’attente pour eux) , la tentation de démarrer au plus vite un petit bout pour tout le monde est plus proche de la règle que de l’exception. L’impact sur le temps de cycle est pourtant dramatique. (Que fait donc la R&D !-) ? )

Les développements à grande échelle ne sont pas en en reste, avec une analogie surprenante mais non nouvelle pour moi entre les organisations des armées modernes et le monde de l’innovation. (J’ai promis de détailler cela dans un futur article)

A noter que si y figurent les mot Kanban ainsi que lean6 sigma et  théorie des contraintes je ne souviens pas avoir lu le mot Agile  (ce qui est normal car agile est pour moi un état d’esprit) pourtant je recommanderais à une équipe scrum ou XP qui a du mal à finir ses stories dans un sprint à utiliser cet ouvrage comme une boite à outils.

En attendant je ne résiste pas à l’idée de  finir  cette article comme il a démarré et si « Principe of Product Developement Flow » était indispensable dans votre bibliothèque du parfait pilote d’entreprise?