Scrum Et Le Toyota Production System, Comment Construire Des Équipes Ultra Performantes

Selon Toyota, ce sont les collaborateurs et non pas les systèmes qui donnent naissance aux meilleurs produits. Il n’est pas possible de fabriquer de bons produits sans développer les compétences des collaborateurs. Pour cela Toyota a construit un système de production dont l’objet est le développement de collaborateurs exceptionnels : le Toyota Production System (TPS).

Jeff Sutherland et Ken Schwaber se sont appuyés en partie sur le TPS pour construire le framework Scrum, cadre de travail pour le développement de produits ou de services complexes.

L’objet de cet article est de montrer comment l’utilisation du Toyota Production System, comme système de construction de la connaissance, permet de révéler les sujets d’apprentissage sur lesquels travailler pour développer des équipes Scrum exceptionnelles.

Scrum : les origines

Les origines de Scrum remontent à un article fondateur publié en 1986 dans la revue Harvard Business review par Monsieur Hirotaka Takeuchi professeur à la Harvard Business School et Monsieur Ikojiru Nonaka professeur émérite à l’université Hitotsubashi de Tokyo : The new new product development game.

En 1993, en s’appuyant sur cet article et sur les principes du lean manufacturing, Jeff Sutherland, développe une méthode radicalement différente pour le développement de produits informatiques. En 1995, avec l’aide de Ken Schwaber, il formalise la méthode : Scrum est né. 

Scrum est une méthode de planification cadencée. Elle s’oppose à l‘approche traditionnelle de type batch considérant que la construction d’un système informatique nécessite d’avoir d’abord terminé son analyse avant de procéder au développement puis aux tests. Cette approche très lourde et couteuse a jeté bon nombre de projets dans l’impasse.

A contrario Scrum casse ce modèle en découpant la construction du produit en petits lots appelés sprints. Au cours d’un sprint, l’équipe analyse, développe et teste ce que le client considère comme ayant le plus de valeur pour lui. Un sprint dure entre 1 à 4 semaines. A l’issue du sprint, lors du sprint review, un incrément du produit est présenté au client qui peut ainsi apporter rapidement son feedback. L’équipe corrige et adapte le produit au fur et à mesure des sprints et des retours du client dont le besoin s’affine. Petit à petit le produit prend forme. Outre cette adaptation permanente aux besoins du client, Scrum apporte une structure formelle pour l’amélioration des pratiques de l’équipe en introduisant la notion de rétrospective. C’est un moment privilégié à la fin du sprint au cours duquel l’équipe revient sur ses pratiques afin de les améliorer lors du sprint suivant.

Scrum, le Toyota Way et le Toyota Production System

Si l’on regarde Scrum sous l’angle lean il est évident que la méthode plonge ses racines dans le Toyota Way et le Toyota Production System.

Du point de vue du Toyota Way, l’amélioration continue et le respect des personnes sont clairement représentés. La structure même de Scrum est une méta résolution de problèmes dont la structure est celle d’un PDCA (Plan Do Check Act) telle que Deming l’a défini. Le Plan avec le sprint planning, le Do avec le sprint, le Check avec le sprint review et la démonstration au client et le Act avec la rétrospective. Cette boucle d’apprentissage continuellement répétée tout au long de la construction du produit favorise la compréhension des besoins du client, le développement individuel et le travail en équipe.

Scrum s’appuie d’autre part sur certains principes du Toyota Production System notamment le management visuel et le Just In Time. A l’issue du sprint planning l’équipe dispose d’un backlog de user stories qu’elle rend visible en s’appuyant sur un management visuel de type Todo/Wip/Done ou d’un Kanban. La performance de l’équipe est mesurée sur sa capacité à livrer toutes les user stories à la fin du sprint au travers d’un indicateur de type burn down chart. Chaque sprint est une « Time Box » d’un mois ou moins au cours de laquelle un incrément de produit « Terminé », utilisable et potentiellement publiable est créé (Cf Guide Scrum). La construction du produit est découpée en petits lots dont la livraison est cadencée selon un rythme régulier, c’est la notion de Takt que l’on retrouve dans le pilier Just In Time du TPS.

Nigel THURLOW, Chief Agile Officer à Toyota Connected, le démontre magistralement dans sa formidable formation Scrum The Toyota Way. Cependant je pense qu’il est possible d’aller encore plus loin. Si Scrum est un outil de planification génial, c’est aussi, comme le dit Jef Sutherland un container pour d’autres techniques, méthodes et pratiques. Et dans ce sens un framework parfait pour le développement des personnes condition sine qua non pour la fabrication de produit à l’effet Wahoo. En effet les différentes expériences que je mène depuis ma rencontre avec le lean en 2008 avec Marie-Pia IGNACE et Michael BALLE montrent qu’une mise en pratique rigoureuse du Toyota Production System au sein même du sprint amène des résultats exceptionnels en termes d’apprentissage et a fortiori de production.

La question qui se pose dès lors, est comment mettre en œuvre les outils du Toyota Production System pour réaliser chaque incrément du produit, afin de révéler en temps réel, les obstacles auxquels l’équipe fait face chaque jour et lui donner les moyens de les résoudre ?

Il faut considérer le TPS comme un échafaudage dont le but est de rendre visible les problèmes au moment où ils apparaissent. Il faut d’abord construire le système puis le faire fonctionner :

1. Construire le bon management visuel
2. Tirer le flux
3. Identifier les bons problèmes
4. Résoudre les problèmes
5. En tirer les bons enseignements

Construire le bon management visuel

Tout part de là. Il est fondamental d’avoir un bon management visuel pour progresser. Il doit permettre de distinguer ce qui est ok de ce qui ne l’est pas. L’équipe délivre-t-elle au bon rythme avec le bon niveau de qualité ? L’équipe passe-t-elle son temps à corriger des anomalies ou des bugs ? Les user stories sont-elles bloquées en attente d’information d’autres équipes ou de la disponibilité d’un environnement de test ? D’un seul coup d’œil il doit être possible de voir si la situation est sous contrôle ou pas et si la performance globale de l’équipe s’améliore ou pas. Un bon management visuel doit comporter 4 panneaux : un mur client pour capturer les incidents clients, un panneau pour la performance comprenant des indicateurs de qualité, de délais, de coût, de productivité, un panneau de production et enfin un panneau consacré à la résolution de problèmes.

Tirer le flux

La mise en œuvre du Just In Time au sein du sprint commence par le calcul du Takt. En effet au même titre que Scrum cadence la construction du produit à un niveau plus macro, il est important de se donner un rythme de production, à l’intérieur même du sprint, pour réaliser les user stories à un rythme régulier. Il s’agit simplement de diviser le nombre stories par le nombre de jours travaillés dans un sprint : 20 user stories pour un sprint de 10 jours donne un rythme de livraison de 2 user stories par jour. Et ensuite de mettre la production en flux tiré. C’est à dire de se placer à la fin du processus et de tirer les users stories en commençant par celles qui sont le plus proche de la sortie. L’objectif de la journée étant fixé par le Takt. Dans notre exemple l’équipe choisi 2 user stories en commençant par celles situées à l’étape la plus proche de la mise en production. Comme dans un match de rugby l’équipe s’engage quotidiennement sur un objectif marquer des essais : ici il s’agit de sortir 2 user stories sélectionnées parmi celles le plus proche de la sortie tous les jours. Si l’équipe atteint l’objectif c’est parfait si elle n’y arrive pas c’est encore mieux : il y a quelque chose à apprendre, c’est une nouvelle occasion de s’améliorer et donc de faire du kaizen.

Identifier les bons problèmes

Voir les problèmes de qualité

Si le principe de découpage en petits lots est plutôt bien exploité par Scrum, le Jidoka, deuxième pilier du TPS l’est beaucoup moins. Le Jidoka consiste à introduire la qualité dans le processus de façon à ne pas propager les défauts d’étape en étape jusqu’au client. Plusieurs techniques comme l’arrêt au premier défaut, l’autonomation, les bacs rouges, l’andon permettent de découvrir les problèmes de non qualité avant qu’ils ne se propagent en production et pénalisent les utilisateurs de l’application ou du service.

Les équipes les plus avancées utilisent les techniques de l’extrem programming comme le Test Driven Development et l’intégration continue pour implémenter certaines parties du Jidoka. Cependant toutes les équipes n’ont pas le niveau de compétence requis pour mettre en œuvre ces techniques d’une part et d’autre part celles-ci ne couvrent pas tout le processus. La question qui se pose dès lors est comment identifier les problèmes de qualité dans le processus quel que soit le niveau de maitrise de ces pratiques ? Une réponse est l’introduction de la technique lean des bacs rouges à chaque étape du processus de production.

Chaque fois qu’un problème de qualité est découvert à une étape du processus l’information est stockée dans le bac rouge. L’analyse rigoureuse et systématique de son contenu permet à l’équipe de mieux comprendre ce qui bloque le flux et de déclencher les actions immédiates pour protéger le client et les résolutions de problème nécessaires à plus long terme pour supprimer définitivement ces obstacles.

Voir les problèmes de flux

L’utilisation du flux tiré met en évidence toute une série de problèmes liés à la dynamique du processus de développement : les problèmes de surcharge, de surproduction ou de synchronisation avec d’autres processus comme le montre la figure ci-dessous.

La résolution de problème

L’unique but de ce qui est décrit précédemment est donc de créer un échafaudage pour mettre en évidence ce que ne maîtrise pas l’équipe. Ainsi, la mise en œuvre du flux tiré et du Jidoka va révéler sur le management visuel différentes sources de problèmes :

• ceux de qualité que l’on retrouve dans les bacs rouges et qui sont le plus souvent une expression d’un manque de compétences,
• ceux de synchronisation avec d’autres flux quand les users stories attendent dans la colonne work in progress,
• ceux de surproduction ou de surcharge quand les user stories s’accumulent dans une colonne ready ou en cours.

En rendant visible ces obstacles en temps réel l’équipe dispose de boucles de feedback très courtes qui lui donnent la possibilité de réagir extrêmement rapidement pour remettre les user stories défectueuses dans le flux (correction = protection du client). Elle peut ensuite prendre du recul pour traiter le problème définitivement (résolution = suppression définitive du problème). Pour se faire, le lean préconise une approche scientifique de la résolution de problèmes avec le PDCA (Plan Do Check Act).

Tout l’intérêt de la méthode réside dans l’accumulation d’occasions d’apprentissage et dans une démarche consciente de résolution de problèmes. Les collaborateurs ne réussissent pas par coïncidence mais grâce à l’analyse systématique des problèmes, de la recherche des causes profondes, de la mise en œuvre de contremesures adéquates, de leur test et d’une réflexion sur ce qu’ils en retirent. Ce travail répété est un accélérateur formidable de la performance individuelle et collective. Le traitement des bacs rouges permet d’identifier précisément les causes des problèmes de qualité qui relèvent le plus souvent de problèmes de compétence. C’est une opportunité pour le Scrum Master ou le Team Leader de mettre en place des matrices de compétences et des dojos de formation pour travailler des gestes particuliers, comme écrire des user stories plus pertinentes, un code plus propre…

L’analyse du flux, de la surproduction et des attentes offre une meilleure compréhension des adhérences du projet ou du produit avec le reste de l’écosystème. Les collaborateurs construisent une collaboration intensive non seulement au sein de leur équipe mais ce qui est plus intéressant encore, avec leurs homologues travaillant sur des sujets connexes. La résolution de problème n’est plus alors une affaire individuelle mais une affaire d’équipes au sens large. Petit à petit c’est l’organisation entière qui fonctionne mieux. Les processus se simplifient au fur et à mesure des améliorations conduites collectivement.

Les résultats

Sur 20 équipes observées, qui se sont appropriées la démarche, nous avons mesuré une amélioration très significative de la performance.

Amélioration de la qualité de la production

Ainsi, dans le domaine de la qualité, les stocks d’incidents non traités ont diminué en moyenne de 59%. Dans le même temps les volumes de nouveaux incidents ont baissé de 37%. Ceci a eu pour effet une augmentation moyenne de la satisfaction client de 25%.

Accélération de la production de valeur

Que ce soit dans la résolution d’incidents, du développement de petits changements ou la réalisation de nouvelles user stories l’accélération est aussi remarquable. Le lead time est divisé en moyenne par 6,5 et la production est multipliée par 3.

Impact économique

A titre d’exemple, dans une business unit composée de 40 personnes, l’équivalent de 5 collaborateurs est en charge de la correction d’incidents. A titre expérimental, le manager décide de créer une équipe dédiée à la réduction d’incidents. En 6 mois cette nouvelle équipe, grâce à la mise en œuvre du TPS, éradique les incidents et passe d’un stock permanent de 80 incidents et un volume quotidien de nouveaux incidents de 3 à un stock de 0 et un volume mensuel de nouveaux incidents de 2. Le coût de résolution des incidents s’effondre. Il passe de 720 000 € par an à 0 € (5 personnes * 600 € * 240 jours). Le manager a gagné en 6 mois plus d’un demi-million d’euros sur son budget de RUN _sans compter les gains économisés grâce à l’amélioration de la qualité_ qu’il peut réaffecter à la production de valeur. Ce gain de productivité lui permet d’accélérer le traitement des petits changements qui s’accumulent et produire ainsi plus de valeur pour ses clients. 

Conclusion

Le système de management lean a pour objectif de développer des collaborateurs exceptionnels pour fabriquer des produits exceptionnels. Le System de production de Toyota, le TPS, est un ensemble de pratiques dont l’unique but est de mettre en évidence les faiblesses du processus pour que les collaborateurs puissent les résoudre en développant leurs compétences. Scrum est la mise en œuvre du Just In Time pour la production de système informatique. La méthode cadence la construction du système au travers d’un enchaînement d’incréments qui ont la forme de PDCA : (Plan) Sprint planning, (Do) le sprint, (Check) le sprint review, (Act) la rétrospective.

Cependant l’application du TPS ne doit pas s’arrêter là. En effet à chaque étape de la démarche, les collaborateurs peuvent progresser individuellement ou collectivement sur toute la chaîne de fabrication, qu’il s’agisse du Product Owner, des développeurs, des architectes ou des testeurs. Il est donc fondamental pour le développement de chacun de disposer d’un système qui révèle les problèmes là où ils surgissent, en temps réel pour leur donner l’occasion d’améliorer la situation : leurs compétences, le processus ou encore l’interaction entre différents services.

Le TPS offre les outils nécessaires pour cela :

• le management visuel à condition qu’il montre les différentes étapes du processus (un Kanban),
• le flux tiré qui cadence la production et donne un feed-back immédiat sur la capacité à respecter les délais,
• les bacs rouges qui donnent un feed-back immédiat sur la qualité de ce qui est produit.

Grâce à ce système les équipes se concentrent sur les problèmes opérationnels qui les empêchent de réussir leur objectif de la journée. Elles développent leurs compétences, résolution de problèmes après résolution de problèmes, grâce à une méthode d’analyse scientifique rigoureuse. Chaque PDCA les rapproche d’un idéal de production dans lequel toutes les user stories traversent le processus de fabrication du produit de manière fluide jusqu’en production. La mise en œuvre du Jidoka révèle les problèmes de qualité qui sont généralement liés à des problèmes de compétences. Le Just In Time quant à lui montre les problèmes de flux et les adhérences avec le reste du système ce qui déclenche la résolution de problème entre équipes.

Petit à petit les user stories sont mieux décrites, leur taille diminue, les développeurs produisent un code de meilleur qualité plus maintenable, plus robuste, plus fiable. Les intégrateurs trouvent moins de défauts et ont plus de temps pour se consacrer aux tests aux limites ou à l’automatisation. Le travail collaboratif avec les autres équipe permet de simplifier le système et de fluidifier les échanges.  Globalement l’équipe développe de nouvelles compétences et s’approprie de nouvelles pratiques. La capacité de l’équipe augmente au fur et à mesure de l’amélioration de la qualité, la production accélère, les coûts diminuent. Le client sourit :-)

A propos de l'auteur

Pierre Jannez est coach Lean IT Senior spécialisé dans l'amélioration des performances des équipes IT. Il s’est intéressé aux pratiques agiles à partir de 2001 et les a déployées pendant une dizaine d’années chez Nokia puis Nokia Siemens Networks au sein de l’équipe de développement française : extrem programming, TDD, continuous integration, BDD, continuous delivery, Scrum. En 2008, lui et son équipe découvrent le lean. Les premières applications donnent des résultats immédiats, la qualité et les délais s’améliorent significativement. Depuis 2010, il se consacre à l’application du Toyota Production System au domaine de l’IT au sein du cabinet Operae Partners.