Chez Planview AgilePlace, nous disposons d'un processus très complet d'assurance qualité, mais parfois, des problèmes liés à des circonstances imprévues ou incontrôlables (comme les fournisseurs de DNS, les services d'hébergement, etc.) peuvent entraîner un problème critique affectant notre logiciel, ce qui peut avoir un impact important sur nos utilisateurs. C'est pourquoi nous choisissons d'arrêter la ligne lorsque des problèmes critiques surviennent - pour arrêter, évaluer et résoudre le problème, et apprendre comment l'empêcher de se reproduire.
Nous prenons ce genre de questions très au sérieux, car un souci constant d'offrir une valeur ajoutée aux clients est au cœur de tout ce que nous faisons. Lisez pour savoir comment nous utilisons les concepts Lean au niveau organisationnel pour aborder les problèmes potentiels de front, les traiter rapidement et les utiliser comme des opportunités pour rendre notre produit - et notre personnel - plus fort.
Aborder les problèmes potentiels de front
Tirez le cordon d'Andon
Un mécanisme de contrôle de la qualité bien connu de Toyota est le cordon Andon. Le cordon est un moyen d'alerter les autres en cas de problème sur la chaîne de production ; chacun a le pouvoir de tirer le cordon. Le fait de tirer sur le cordon arrête immédiatement la production et diffuse un signal, alertant les autres qu'il y a un problème critique qui nécessite une réponse immédiate.
Dans la production allégée, un superviseur aiderait alors le travailleur à examiner le problème et à déterminer les prochaines étapes. À l'AgilePlace de Planview, les équipes et les dirigeants travaillent ensemble pour résoudre le problème et apprendre comment l'empêcher de se reproduire.
Tirer le cordon d'Andon est encouragé dans les environnements Lean car cela empêche les défauts d'atteindre les clients, et crée une opportunité d'améliorer le système pour éviter de futurs défauts.
C'est pourquoi nous employons un cordon virtuel Andon à Planview AgilePlace. Toute personne de l'entreprise qui trouve un problème possible dans notre produit peut appeler notre cordon Andon virtuel. Bien que la plupart d'entre elles proviennent du Développement de produits, tous nos départements utilisent notre propre produit pour gérer leur travail. Ils ont donc également la possibilité d'attirer l'attention sur d'éventuels problèmes.
Lorsque cela se produit, nous veillons à ce que toute l'entreprise soit mise au courant de la situation. Les notifications sont envoyées à tout le monde via Slack ainsi qu'un courriel à toutes les mains. Nous veillons à ce que ces notifications ne comprennent que les informations connues, afin de nous assurer que nous identifions correctement le véritable problème et que nous trouvions une solution appropriée et durable.
Swarm Around the Issue (Obeya)
Une fois que la communication initiale est diffusée à l'ensemble de l'entreprise, nous voyons une chose étonnante se produire : les employés de différentes équipes et départements commencent à offrir leur aide. Il est assez courant qu'un chef de produit d'un segment de produit non affecté dise : "Je suis disponible pour vous aider à tester si vous avez besoin de moi."
Les chefs d'équipe et les chefs de produit se réunissent normalement dans une salle (pour ceux qui sont locaux) et lancent une session de partage d'écran avec leurs homologues distants. C'est ce que nous appelons généralement un scénario de "salle de guerre" ; dans la production allégée, on parle de obeya. Toutes les personnes qui doivent prendre des décisions critiques pour résoudre le problème sont immédiatement disponibles.
Nous faisons cela pour accélérer la communication et la prise de décision, ce qui est essentiel pour résoudre le problème rapidement. Les personnes chargées de résoudre le problème n'ont pas besoin d'attendre une autorisation ou des informations supplémentaires avant d'agir, puisque toutes les personnes avec lesquelles elles doivent communiquer sont facilement accessibles. Elle permet également de s'assurer que tout le monde est sur la même longueur d'onde concernant le problème en question, sa cause sous-jacente, la résolution choisie et tout critère de réussite établi.
Go to the Gemba
Une légère variation du concept de "war room" est que nous ne rassemblons pas tous les membres de l'équipe de leurs différentes pièces dans une grande salle de conférence. Habituellement, ils se réunissent dans la salle de l'équipe affectée et s'y installent. Cela reflète l'esprit du concept Lean gemba, qui signifie littéralement "l'endroit réel".
Il s'agit de l'idée selon laquelle, lorsque vous essayez de résoudre un problème, vous vous rendez à l'endroit où le problème existe. Dans un scénario de fabrication, cela signifie généralement l'atelier, mais dans une entreprise SaaS, cela se traduit par la salle d'équipe où le travail est effectué. Il est important de noter que nos dirigeants sont toujours présents dans la "salle de guerre", car c'est là qu'ils peuvent voir la situation le plus clairement et offrir les meilleurs conseils. Apprenez-en davantage sur le rôle du leadership Lean ici.
Rendez le travail visible
Lorsque l'équipe est en place pour résoudre le problème, elle affiche immédiatement une carte sur notre tableau Kanban de la feuille de route du développement des produits. Ce conseil a une voie spécifique tout en haut pour ce type de questions. Nous nous efforçons de rendre le problème et le travail qui en découle aussi visibles que possible pour l'ensemble de l'entreprise, afin que chacun comprenne ce qui a mal tourné et comment l'éviter à l'avenir. Il permet également aux employés en contact avec la clientèle d'être en mesure de communiquer efficacement des informations pertinentes aussi rapidement et précisément que possible.
Limiter l'impact en aval
Limiter les autres encours
La carte est étiquetée avec les équipes qui sont affectées par le problème et toutes les autres cartes pour ces équipes sont bloquées pour montrer que cette carte est la première et seule priorité de tout le monde jusqu'à ce qu'elle soit résolue. Le blocage d'autres cartes permet également aux autres équipes de savoir clairement quel travail est affecté par le problème.
Ce couloir est considéré comme un couloir d'accélération, ce qui signifie que l'équipe doit travailler sur les cartes de ce couloir avant de reprendre ou de commencer tout autre travail, afin de déplacer la carte sur le plateau aussi rapidement que possible. Nous avons également fixé une limite de travaux en cours (WIP) de 1 sur la voie d'expédition pour que l'équipe se concentre sur la résolution du problème avant de s'attaquer à autre chose. Cela permet d'éviter le changement de contexte et de garantir que tout problème affectant nos clients est résolu aussi rapidement que possible.
Arrêtez la ligne (Jidoka)
L'étape suivante est la plus difficile pour toute organisation : arrêter la ligne. En Lean, ce concept est appelé jidoka. Elle suit la théorie selon laquelle, pour obtenir la meilleure qualité pour votre produit et la meilleure opportunité d'amélioration continue, vous devez arrêter toute production lorsqu'un problème survient et résoudre le problème avant de reprendre le travail.
Arrêter la chaîne peut sembler fou à beaucoup, puisqu'aucune valeur ne peut être fournie par une partie de l'organisation si toutes les activités s'arrêtent - mais ce genre de pensée est à courte vue. Si vous ne parvenez pas à résoudre les problèmes au fur et à mesure qu'ils surviennent, vous vous retrouvez avec une dette technique insurmontable, qui empêche votre organisation d'aller de l'avant.
La seule façon de traiter les problèmes dans un environnement d'amélioration continue est de considérer chaque problème comme une opportunité d'amélioration, et un tremplin pour une croissance durable.
L'idée en pratique
C'est essentiel pour la qualité, car le travail effectué par d'autres équipes peut non seulement interférer directement avec les efforts déployés pour résoudre le problème, mais il peut également créer du travail en aval pour les personnes de l'équipe qui résout le problème. Par exemple, disons que l'équipe A travaille à la résolution d'un problème critique. Pendant ce temps, l'équipe B met en œuvre des changements qui nécessitent une révision ou un autre type d'implication des membres de l'équipe A.
Avec un peu de chance, l'équipe A se concentre entièrement sur la résolution du problème critique. Si l'équipe B continue à mettre en œuvre le travail qu'elle effectue, elle risque de créer encore plus de travail pour l'équipe A une fois le problème résolu. L'équipe A ne sera pas au courant des décisions qui ont été prises, elle devra donc passer du temps à monter en puissance, et pourrait manquer certaines des informations dont elle a besoin pour effectuer le travail correctement, ce qui pourrait affecter le succès de la mise en œuvre.
Imaginez maintenant que cela se produise avec quelques autres équipes pendant que la ligne est arrêtée. Vous pouvez vous retrouver dans une situation où le travail fait la queue, attendant les membres de l'équipe qui s'occupent du problème. Plus ce travail reste en suspens, plus il risque de devenir obsolète et de présenter des problèmes une fois mis en œuvre.
C'est le risque de ces problèmes en aval qui justifie l'arrêt de tous ces autres travaux pendant un problème d'"arrêt de la ligne". Régler les problèmes plus tard, en aval de tout processus, est presque toujours plus coûteux. Nous devons réaliser que le coût de l'arrêt de la ligne et de la sous-utilisation peut souvent dépasser le coût de la perte de productivité pendant les problèmes d'arrêt de la ligne.
Cela ne signifie pas que quiconque ne travaille pas sur la question reste simplement inactif. C'est l'occasion pour eux de travailler sur des projets d'amélioration continue, pour autant que ces projets ne créent pas d'effet négatif en aval sur ceux qui travaillent sur la question. Ces membres de l'équipe oisive peuvent travailler sur l'automatisation, les tests, le développement professionnel, etc. Nous demandons à nos équipes de conserver un backlog de ces types de projets afin qu'elles puissent facilement les reprendre lorsqu'un arrêt de la ligne se produit. Une facette importante de ce type de travail est qu'il doit également pouvoir être facilement mis en pause lorsque la ligne reprend.
Pratiquer l'amélioration continue
Une fois le problème résolu, nous veillons à ce que la résolution soit communiquée à l'ensemble de l'entreprise. Cependant, nous ne recommençons pas immédiatement la ligne. La résolution du problème immédiat n'est que la première partie. Dans un effort d'amélioration continue, ou kaizen dans la terminologie Lean, les équipes concernées organisent une rétrospective pour examiner le problème et l'efficacité de notre processus pour le résoudre.
Au cours de cette rétrospective, les membres de l'équipe s'efforcent de trouver la cause profonde du problème en utilisant des techniques telles que le 5. Whys. Ensuite, ils discutent des améliorations possibles de notre processus de développement de produits pour éviter des problèmes de ce genre à l'avenir. Il est très important que l'équipe reparte avec des éléments concrets pouvant être mis en œuvre immédiatement, ainsi qu'une idée de ce à quoi ressemblera le succès - et un calendrier pour savoir quand nous pourrons commencer à voir ces avantages. Les résultats de la rétrospective sont enregistrés et examinés avec les équipes et organisations concernées.
Utilisez les métriques à bon escient
Chaque incident "stop the line" est suivi et diverses données sont collectées au cours du processus de résolution. Nous utilisons ensuite ces données pour comprendre comment nous gérons ces incidents. A quelle fréquence se produisent-ils ? Combien de temps nous faut-il pour les résoudre ? Combien de fois restons-nous bloqués pendant la résolution du problème ? Quels sont les domaines de l'application qui posent le plus de problèmes ?
Ces mesures sont périodiquement examinées par la direction du développement de produits afin de déterminer s'il existe des possibilités d'amélioration aux niveaux supérieurs de notre processus. Il est impératif d'utiliser ces mesures avec précaution, car la dernière chose que l'on souhaite, c'est de décourager les employés d'arrêter la ligne quand c'est nécessaire (pour en savoir plus sur l'utilisation judicieuse des mesures ici). Cela pourrait être le cas si la direction réagissait mal aux mesures concernant la fréquence ou la durée des incidents "stop the line".
Les mesures concernant ces incidents rares, mais significatifs, doivent être considérées comme des opportunités d'amélioration. Nous voulons encourager tous les employés à tirer le cordon Andon et à potentiellement arrêter la ligne s'ils constatent des problèmes majeurs dans notre produit, car c'est ainsi que nous pratiquons l'amélioration continue. Il est de la responsabilité de chacun de créer un environnement dans lequel les employés se sentent en sécurité.
Les valeurs fondamentales d'AgilePlace
Les valeurs fondamentales d'AgilePlace sont l'amélioration continue, le respect des personnes et une concentration sans relâche sur la fourniture de valeur au client. Arrêter la ligne pour résoudre les problèmes au fur et à mesure qu'ils se présentent est un excellent exemple de vivre ces valeurs.
Nous faisons preuve de respect envers nos clients en abordant immédiatement tout problème qui pourrait les empêcher d'utiliser notre produit. Par respect pour nos pairs, lorsque nous avons un problème d'arrêt de la ligne, nous interrompons toute activité qui augmenterait la charge de travail des personnes concernées. Nous leur permettons de laisser tomber tout ce qu'ils sont en train de faire afin qu'ils puissent se concentrer entièrement sur la résolution du problème critique.
Nous nous efforçons également de créer un environnement où chacun se sent à l'aise pour porter un problème à ce niveau critique. C'est, bien sûr, un défi - car personne ne veut être le dénonciateur. Mais c'est essentiel si nous espérons continuer sur la voie d'une croissance saine et durable.
Nous arrêtons la ligne afin de pouvoir pratiquer l'amélioration continue au niveau de l'organisation. Avec la résolution de chaque problème d'arrêt de la ligne, nous devenons plus intelligents, notre produit s'améliore et nous sommes mieux à même d'empêcher les problèmes de se produire en premier lieu.
Tous ces efforts sont ancrés dans notre engagement à offrir de la valeur au client, qui guide chacune de nos décisions.
Lectures recommandées
Pour en savoir plus sur la façon dont les principes Lean améliorent la qualité, la productivité et la santé organisationnelle, consultez ces ressources :
- Le 2016 Lean Business Report [ebook]
- Amélioration continue dans Lean [blog]
- Leadership, culture et outils Lean [webinaire]
