Vous avez probablement entendu la grande nouvelle : le multitâche est un mythe. Et pourtant, pratiquement tout le monde est coupable de passer d'un projet à l'autre en même temps - tout en répondant à des courriels, des conversations en voiture, des appels téléphoniques, etc. Lorsqu'on nous presse de livrer plus rapidement, nous nous surchargeons souvent en essayant d'assumer plus de tâches, ce qui dilue par inadvertance notre concentration et nous ralentit - beaucoup.
Chez Fortezza Consulting, j'aide les équipes à améliorer considérablement leurs performances - parfois de 3x ou plus. L'élément clé est la monotâche : Se concentrer intensément sur la livraison d'un travail de qualité, une pièce à la fois. L'impact de la monotâche est dramatique au niveau individuel, et transformationnel au niveau organisationnel.
Dans les organisations complexes et rapides, la monotâche est impossible à mettre en œuvre sans une approche disciplinée. C'est là qu'interviennent les objectifs en matière d'encours (WIP, work-in-process). Poursuivez votre lecture et regardez l'enregistrement de ce webinaire pour découvrir le raisonnement Lean et Kanban qui explique pourquoi les objectifs d'encours fonctionnent et comment les appliquer à l'échelle de l'entreprise.
Lean, Kanban et WIP
Un principe clé du Lean et du Kanban consiste à visualiser le flux réel du travail. En visualisant leur travail, les équipes sont en mesure d'identifier en permanence les possibilités d'amélioration. Les tableaux Kanban aident les équipes à visualiser la priorité, le statut, les membres de l'équipe assignés, les dates d'échéance, et plus encore, de n'importe quel élément de travail. Ils peuvent également voir les problèmes qui bloquent le flux de travail - comme les goulots d'étranglement et les bloqueurs - et peuvent travailler à l'amélioration de leur processus afin d'obtenir un flux continu. C'est grâce à ce processus d'amélioration continue que les équipes peuvent atteindre leurs objectifs de performance.
Un autre élément important de la pratique de Kanban consiste à utiliser un système de traction, c'est-à-dire que les équipes tirent le travail dans leur système au fur et à mesure de leur capacité (plutôt que de se voir "pousser" du travail sans tenir compte de leur charge de travail). Pour disposer d'un système de tirage, les équipes doivent avoir un backlog hiérarchisé et un processus clair de hiérarchisation. Cela permet à n'importe quel membre de l'équipe de pouvoir introduire dans le système des travaux classés par ordre de priorité, au fur et à mesure de ses capacités.
Il permet également à l'équipe de mettre en place des limites d'encours - ou idéalement, des objectifs d'encours. Limiter les en-cours permet aux équipes de se concentrer sur l'amélioration de la qualité et de la rapidité de leur travail. Les objectifs d'encours débloquent un nouveau niveau de performance grâce au pouvoir de la monotâche, favorisant une culture d'expérimentation et de collaboration qui peut être un catalyseur pour atteindre des objectifs de performance toujours plus élevés.
Ce que vous apprendrez
Dans ce webinaire, je présente le concept des cibles WIP et leur application à l'échelle de l'entreprise, et j'aborde des questions clés telles que :
- Comment reconnaître quand il est temps d'optimiser l'encours ?
- Comment savoir quel est vraiment le bon objectif d'encours ?
- Comment utiliser les objectifs d'encours pour favoriser une plus grande autonomie et autogestion des équipes ?
- Comment aider à la fois les dirigeants et les travailleurs du savoir à opérer le changement d'état d'esprit nécessaire ?
- Comment mettre à l'échelle l'application des cibles WIP dans toute l'entreprise ?
Vous apprendrez comment favoriser l'expérimentation et la collaboration et atteindre des niveaux de performance sans précédent avec votre équipe.
Regardez l'enregistrement
Feuilletez mon jeu de diapositives ici.
10 Common Questions about WIP Targets
Q : Pour une équipe de 20 programmeurs jumelés, êtes-vous en train de dire qu'ils devraient simplement choisir un objectif de WIP d'équipe de 10 ?
R : Oui ! Pour ceux qui ne sont pas familiers avec la programmation en binôme, cela signifie simplement que deux développeurs de logiciels (programmeurs) font équipe l'un avec l'autre pour chaque tâche. Il est donc logique qu'une équipe de 20 ait un objectif d'encours d'équipe de 10.
Toutefois, si un ou deux membres de cette équipe de 10 sont des experts chevronnés qui peuvent mieux aider à améliorer le flux de l'équipe en "flottant" vers n'importe quelle paire de programmeurs qui pourrait avoir besoin d'aide pour accélérer les choses, alors cette équipe peut trouver un avantage à explorer un objectif de WIP d'équipe de 9, ou peut-être même 8.
Q : Avec autant d'équipes disposant chacune d'une grande autonomie, comment faire évoluer ce système dans une grande organisation avec un certain niveau de cohérence ?
R : L'aspect qui exige une cohérence non négociable est la culture "Comment pourrions-nous... ?", fondée sur la discipline de la tâche unique, et tout ce qui peut être fait pour promouvoir et renforcer cette culture.
Si chaque équipe individuelle propose des objectifs d'encours d'équipe radicalement différents, mais que chacun d'entre eux est basé sur une solide discipline de tâche unique, alors vous venez probablement de réaliser quelque chose de vraiment étonnant.
L'étape suivante pour les environnements centrés sur les projets consiste à élever le concept d'objectifs d'encours d'équipe au niveau du portefeuille de projets (encours au niveau du projet). Faire en sorte que l'encours au niveau des tâches et l'encours au niveau du projet correspondent à la capacité est la meilleure recette que je connaisse pour obtenir des gains spectaculaires dans le débit des projets achevés.
Q : Comment puis-je susciter l'adhésion de mes équipes ?
R : J'aime commencer en invitant les gens à jouer au jeu à tâche unique décrit sur la diapositive ci-dessous - il ne faut qu'environ 10 minutes pour jouer, et peut-être 10-15 minutes pour discuter de l'expérience et des enseignements, donc moins de 30 minutes au total.
En général, les gens sont assez étonnés de la différence en termes de vitesse et de fiabilité. Ensuite, partagez avec eux mon histoire sur les puzzles du Rubik's cube, et demandez-leur s'ils sont d'accord pour dire que la différence de vitesse est probablement encore plus grande lors de l'exécution de tâches de connaissance complexes. Puis demandez : "Et si nous ne pouvions jamais atteindre que la moitié d'un environnement idéal de concentration sur une seule tâche ?" et "Et si nous ne pouvions le faire que pour nos ressources les plus anciennes, les plus expertes, les "goulots d'étranglement" qui travaillent aux tâches les plus complexes ?"
Préparez-vous à un mélange de réactions, allant de la plus grande intrigue au plus grand scepticisme. Le but n'est pas nécessairement de convaincre qui que ce soit de quoi que ce soit au cours de cette première conversation, mais seulement de lancer la conversation. Demandez ensuite de poursuivre la conversation, peut-être en ajoutant le jeu à l'ordre du jour d'une prochaine réunion d'équipe, ou en demandant si quelqu'un a vu la dernière étude sur la monotâche. La clé ici est de ne pas considérer cela comme un processus d'"adhésion" dans lequel vous "vendez" ou poussez quoi que ce soit, mais comme un véritable début de conversation du type "Comment pourrions-nous... ? Vous pourriez bien recevoir des suggestions intéressantes et créatives qui n'ont rien à voir avec la monotâche, mais qui pourraient néanmoins valoir la peine d'être essayées.
Q : Comment pouvons-nous motiver les gens à s'engager dans des projets et des équipes plus transversaux ? (c'est-à-dire. les ventes internes impliquées dans les projets de manutention, les ingénieurs de production impliqués dans les projets de qualité, la qualité impliquée dans les projets de vente, etc.)
R : J'aime placer l'ensemble de l'équipe interfonctionnelle sur un seul et simple tableau ToDo/Doing/Done lorsque c'est possible, puis utiliser les types de cartes pour refléter tout le spectre des compétences requises. Même si vous évoluez dans un environnement très segmenté, par phases, cela peut être une véritable révélation pour les personnes des différentes fonctions de voir le travail que chacun a devant lui. Et avec Planview AgilePlace, il est facile de filtrer par type de carte lorsque vous avez juste besoin de vous concentrer sur la fonction de votre équipe. Il est également facile d'effectuer une analyse pour déterminer où se trouvent les plus gros goulots d'étranglement dans le processus de bout en bout.
Si un tel conseil transversal unique n'est pas réalisable, alors j'adore que Planview AgilePlace propose Card Connections pour montrer la connexion entre les cartes - que ce soit sur le même conseil ou sur plusieurs conseils différents. Cela peut demander un peu de frais supplémentaires pour que les gens rendent ces connexions explicites, mais après que quelques personnes aient commencé à le faire, cela devient un peu contagieux.
Un autre élément très important à ce sujet - les éditions Advanced et Enterprise de Planview AgilePlace offrent également d'excellents outils d'analyse pour la création de rapports transversaux. Ainsi, pour les personnes qui prennent en charge plusieurs conseils d'administration, nous pouvons exécuter des rapports de tâches uniques pour voir combien de tâches elles jonglent à un moment donné, puis demander "Comment pouvons-nous aider à rapprocher ce nombre d'une seule tâche à la fois ?" Sans cette fonction de rapport, vous devriez vérifier les tâches de chaque utilisateur multi-panneau sur chacun des panneaux qui lui sont attribués.
Q : La première question que les équipes me posent est "quelle devrait être notre limite de WIP ?". Quel est le bon conseil au-delà de "si bas que ça fait mal".
R : Je vous encourage à commencer par l'idée que la recherche d'un environnement centré sur une seule tâche est souhaitable - et si les gens ne sont pas d'accord sur ce point, alors voyez ma réponse à la troisième question (sur l'obtention de l'adhésion de vos équipes).
Une fois que les gens commencent à voir qu'il pourrait vraiment être un facteur clé de la vitesse et de la fiabilité, alors tout ce que vous avez à faire est de vous assurer que l'objectif d'encours n'est pas plus élevé que le nombre de travailleurs. Au fur et à mesure que l'équipe se rapproche de véritables comportements monotâches, vous pouvez alors la mettre au défi d'expérimenter ses propres objectifs d'encours, qui devraient toujours être inférieurs au nombre de travailleurs.
La clé ici est de s'assurer que tout le monde sait que, aussi loin de l'objectif que l'équipe puisse être aujourd'hui, avec un WIP empilé, ce n'est pas grave tant que le tableau reflète fidèlement la réalité, et tant que nous nous remettons réellement en question en nous demandant "Comment pourrions-nous travailler les niveaux de WIP pour nous rapprocher de notre objectif de tâche unique ?".
Résistez à la tentation, en tant que leader, de dire "Hé, comment se fait-il que vous ayez 5 tâches ouvertes - je vous ai dit que nous devions faire une seule tâche !". Si vous faites cela, vous verrez soudainement un tableau avec une harmonie artificielle : Le tableau affichera comme par magie une discipline parfaite pour une seule tâche du jour au lendemain, même si cela ne reflète probablement pas du tout la réalité... si cela se produit, vous aurez fait un grand pas en arrière et devrez peut-être recommencer.
Q : Nous avons de gros volumes de produits qui passent par notre système. Nous avons mis en œuvre le Lean, mais nous avons du mal avec le traitement des pièces uniques.
R : Si je comprends bien le problème ici, c'est que les volumes élevés poussent constamment les niveaux d'encours bien au-delà de la capacité, et que la "capacité" dans ce contexte est mieux atteinte par le traitement de pièces uniques, conformément à la notion de flux de pièces uniques du Lean.
Si ce traitement en une seule partie est exécuté principalement par des humains dans cet exemple, alors nous savons que notre cible d'encours doit refléter un comportement de tâche unique, et donc mon conseil de laisser l'équipe expérimenter différentes cibles d'encours est valable. Si ce traitement en une seule partie est principalement automatisé ou exécuté par une machine, il est important de comprendre si le traitement en une seule partie est vraiment ce qui permettrait d'obtenir un débit maximal. Par exemple, pour une autoroute à une voie, une voiture à la fois est généralement optimale, mais pour une autoroute à 12 voies, nous avons la capacité de traiter 12 voitures en parallèle.
Q : Cela peut-il aussi s'appliquer au développement de produits physiques ?
R : Tant qu'il s'agit d'un environnement centré sur l'homme ou sur le savoir (par opposition à un environnement centré sur la machine ou principalement automatisé), cela fonctionne aussi bien avec des produits physiques qu'avec des logiciels ou d'autres éléments finaux "invisibles". En fait, elle fonctionne probablement mieux pour les produits physiques, étant donné qu'il est souvent plus facile de voir où se trouve le goulot d'étranglement avec les produits physiques - il suffit de regarder à quelle étape du traitement les produits de travail physiques (c'est-à-dire les "stocks") s'accumulent le plus, et c'est généralement là que se trouve le goulot d'étranglement de bout en bout.
Q : Les calculs de limites d'encours nécessitent-ils un temps de cycle ? Et de combien de données avez-vous besoin ?
R : Techniquement, oui, mais certaines organisations compliquent excessivement les choses. Pour garder les choses simples, j'aime utiliser des diagrammes de flux cumulatifs comme celui présenté sur cette diapositive :
Il indique les temps de cycle - il s'agit simplement de la dimension horizontale ou de l'axe X, que Planview AgilePlace calcule pour vous. Il existe d'autres rapports Planview AgilePlace qui se concentrent plus explicitement sur les temps de cycle. Tant que le tableau reflète la réalité, les temps de cycle sont capturés sans problème. La clé ici est que la pente de la CFD doit être de plus en plus forte, ce qui ne peut se produire que si les temps de cycle diminuent (en supposant que la capacité globale reste stable).
J'ai vu de nombreux exemples d'équipes poursuivant une réduction de X% du temps de cycle, et peut-être même revendiquant le succès d'une certaine réduction de l'objectif, alors que le flux global semble à peu près le même - c'est un indicateur fort que l'objectif "optimum local" peut avoir été atteint seulement au détriment du flux global ou "mondial".
Q : Comment gérer et dimensionner l'encours de fabrication ?
R : J'espère avoir couvert la "question de l'échelle" de manière adéquate sur la diapositive ci-dessous, mais sinon, voici un résumé rapide.
Tout d'abord, propager par "copier/coller" au sein de plusieurs équipes, avec des champions au niveau de la direction renforçant la culture "Comment pourrions-nous... ?" dès qu'ils en ont l'occasion ; également, comme mentionné dans ma réponse à la troisième question ci-dessus (sur l'obtention de l'adhésion de vos équipes), envisager de consolider en un nombre de plus en plus restreint de conseils, en se rapprochant de plus en plus d'une véritable vue de processus de bout en bout pour chaque processus majeur de votre organisation.
Deuxièmement, pour les environnements centrés sur les projets, élevez la notion d'objectifs d'encours au niveau du projet et évaluez si des volumes plus faibles de projets simultanés entraînent une augmentation du débit des projets achevés (conseil : il est extrêmement rare qu'une réduction de l'encours d'un projet n'entraîne pas une augmentation du débit - je ne l'ai vu qu'une seule fois, et c'était après une réduction agressive de l'encours d'un projet qui était simplement allé un peu trop loin).
Troisièmement, envisagez d'appliquer les concepts d'échelonnement de la gestion de projet en chaîne critique comme un excellent moyen de cibler les niveaux optimaux d'encours de projet (apprenez-en davantage sur la gestion de projet en chaîne critique dans mon nouveau livre, The CIO's Guide to Breakthrough Project Portfolio Management).
Q : Comment mesurer l'encours dans la phase précédant le travail de développement ?
R : J'aime identifier le travail de "phase précédente" comme différents types de cartes sur le même tableau, avec une construction simple de type ToDo/Doing/Done. De cette façon, nous avons une image réelle des niveaux globaux d'encours de l'équipe, et nous pouvons même repérer les fonctions ou sous-équipes qui sont plus proches de la discipline de la tâche unique que les autres, et leur demander de partager la façon dont elles y sont parvenues avec les autres fonctions ou sous-équipes.
De plus, pour les membres de l'équipe ayant une formation croisée, il est plus facile de voir si un membre de l'équipe de test, par exemple, souffre d'un obstacle qu'un membre de l'équipe de développement pourrait aider à surmonter au nom de l'amélioration du flux global de l'équipe. Cela est conforme aux principes Scrum d'une équipe intégrée qui s'améliore de plus en plus grâce à une collaboration et une formation croisée efficaces, tandis que les individus conservent leurs rôles principaux et leurs domaines de spécialisation.
