Ce que j'ai appris chez Toyota

Essai de la nouvelle Toyota Mirai à hydrogène avec Pierre Masai

J'ai rencontré pour la première fois Pierre Masai, DSI de Toyota Motors Europe (TME), il y a quelques années lors de la conférence annuelle Lean IT à Paris. Pierre est un défenseur de l'agilité qui s'est engagé à promouvoir Scrum dans l'ensemble de l'infrastructure informatique. À son invitation, j'ai récemment passé la majeure partie de deux jours à Bruxelles à rencontrer des responsables et des développeurs et à présenter ce que nous avons appris au sujet de Scrum. J'ai décidé de commencer par demander comment Toyota aborde les trois méga-défis que nous identifions dans notre Formations Scrum et Scrum@Scale ateliers :

1. L'entreprise dispose-t-elle d'un carnet de commandes clair pour chaque équipe à chaque sprint ?
2. L'entreprise peut-elle arriver à Done avec des fonctionnalités utiles à la fin de chaque sprint et Done signifie-t-il déployable ?
3. L'entreprise peut-elle facilement remanier son organisation pour tirer parti des conditions du marché et optimiser la fourniture d'un produit de valeur aux clients ? Il est essentiel de disposer de petites équipes interfonctionnelles soutenues par la direction.

Comme toutes les entreprises qui passent du développement traditionnel de produits à une méthode de travail agile, Toyota est confrontée à ces défis. Elle aussi a besoin des priorités clairement visibles. Ils trouvent aussi des cas où tout est prioritaire et où les gens travaillent sur beaucoup de choses à la fois. Cela produit beaucoup de déchets. Dans les entreprises où plusieurs choses sont prioritaires et où tout le monde travaille sur plusieurs choses à la fois, le multitâche est la norme. Comme l'a montré Gerry Weinberg dans Gestion de la qualité des logiciels : Pensée systémiqueLes personnes ou les équipes qui travaillent sur cinq choses à la fois subissent une perte de 75% due au changement de contexte. Il semble que plus l'entreprise est grande, plus ce problème est grave. Au niveau de l'équipe, il est difficile de faire avancer les choses à la fin d'un sprint. L'efficacité des processus est terrible. Eux aussi ont besoin d'une définition plus rigoureuse de DONE afin que des fonctionnalités utiles puissent être déployées à la fin de chaque sprint. Tous les tests doivent être effectués au cours du sprint. Tous les bogues doivent être corrigés au cours du sprint. Il faut beaucoup plus de temps pour corriger un bogue des semaines plus tard, et pour les produits complexes, il faut jusqu'à 24 fois plus de temps pour tester et corriger. En outre, toutes les équipes ne sont pas aussi petites ou aussi polyvalentes qu'elles pourraient l'être. Cependant, Toyota dispose d'avantages distincts que la plupart des entreprises n'ont pas lorsqu'elles opèrent une transition agile. Toyota a un héritage d'excellence fondé sur le système de produits Toyota et sur la discipline Hoshin, un système de planification stratégique qui permet d'améliorer la qualité des produits :

1. Sélectionne un objectif clé.
2. Aligne les plans de mise en œuvre à tous les niveaux.
3. Mettre en œuvre, réviser et améliorer le plan de manière continue.

Au fur et à mesure que Toyota renforce la rigueur du système Hoshin, un plus grand nombre de personnes effectuent un travail de plus grande valeur.. Ils s'attendent à ce que les choses soient faites en peu de temps, idéalement en une seule pièce à flux continu. Taiichi Ohno a mis en place le système de produits Toyota pour utiliser de petites équipes interfonctionnelles qui améliorent radicalement l'efficacité des processus. Le résultat net est que Les bénéfices par voiture de Toyota dépassent ceux des trois grands constructeurs automobiles de Detroit. Malheureusement, Toyota a historiquement mis en œuvre une gestion de projet traditionnelle en cascade dans le domaine des technologies de l'information. Lorsque je leur ai rappelé leur héritage et que je leur ai demandé ce que Taiichi Ohno dirait s'il voyait les vestiges du processus en cascade qui existent encore aujourd'hui chez Toyota, ils ont répondu : "Il serait outré !". Ce que j'ai appris chez Toyota, c'est que Hoshin et la colère du fondateur sont de puissantes incitations à rendre l'informatique Toyota agile. -- Jeff Sutherland

Remarque :  Le processus de planification hoshin suit les principes de Deming. Planifier, faire, vérifier, agir  cycle. Le PDCA est une méthode générique d'amélioration continue, ce que la planification hoshin vise à être. Scrum est basé sur le cycle PDCA de Deming et sur le cycle PDCA de Takeuchi et Nonaka. développement de nouveaux produits. Elle intègre Hoshin sous la forme d'une équipe Product Owner qui aligne l'ensemble de l'organisation sur un carnet de commandes hiérarchique. Cette capacité à se concentrer permet d'accomplir un travail plus utile. Dans le cas de Toyota, elle lui permet d'atteindre une rentabilité supérieure sur ses produits, ce qui est l'objectif de l'équipe Product Owner dans l'équipe Scrum.