L’équipe était à juste titre fière du travail qu’elle avait accompli pour créer une Obeya de gestion de projet, et l’enthousiasme était évident sur les visages alors que nous nous rassemblions autour du mur du macro-planning. Mais les « surprises » désagréables à venir étaient tout aussi évidentes. Je pouvais les voir tapies dans les longs blancs qui apparaissaient par intermittence dans les lignes de production, mais aussi dans les « plans » pour fournir les entrants des livrables critiques. Je pouvais le voir car c’était une erreur que j’avais vue auparavant et que j’avais commise par le passé.

Cela se produit lorsque les équipes insèrent de longues périodes de temps « standard » ou « en bloc », qui consistent souvent uniquement en un point de départ et une date de fin avec une faible compréhension de ce qui se passe entre ces deux points. Les exemples de développement incluent la fourniture des spécifications, le codage et l’achèvement des tests, mais il en existe beaucoup d’autres.

La prochaine fois que vous verrez de grands espaces au contenu indéfini, où des monstres pourraient se cacher, demandez à l’équipe le travail qui y est effectué.

L’obeya aura généralement un post-it placé pour le début de la réalisation d’une spécification, puis un seul post-it placé 10 semaines plus tard, indiquant la date à laquelle 200 spécifications doivent être complétées et livrées pour alimenter le système. Ou pire, il y aura un post-it placé pour l’autorisation de démarrage du codage, puis rien ou presque avant 20 semaines plus tard, lorsque tous les fournisseurs devraient les avoir terminés et livrés. Ces énormes lacunes en matière d’information peuvent engendrer de sérieux problèmes pour l’équipe avant même qu’elle ne se rende compte qu’il existe un problème. Mon ancien patron, John Fleming (ancien vice-président exécutif de Ford), appelait cela « voyager avec espoir » et ce voyage n’a jamais été agréable.

C’est un peu comme naviguer dans une course de Boston à Miami ignorant tout, excepté votre destination finale et le temps moyen du voyage. Puis appeler vos sponsors dans un bar de Norfolk, quelques semaines plus tard, pour leur dire que vous travaillez sur un plan de reprise. À ce stade, qui s’en soucie ?

Même s’il est vrai que les meilleurs marins savent qu’ils ne peuvent pas contrôler l’océan (ce qui est une erreur souvent commise par les développeurs conventionnels), ils ne sont pas prêts non plus à mettre leur destin seul à disposition des vents et des vagues. Ils perfectionnent continuellement leurs compétences en matière de navigation, s’efforcent, à tout moment, de comprendre en profondeur leur itinéraire et leur position par rapport à la route envisagée. Par ailleurs, ils utilisent les meilleurs outils possibles pour augmenter leurs chances de réussite. De la même manière, le développement Lean-agile consiste moins à créer des plans très détaillés basés sur des choses que vous ne pouvez pas savoir au début d’un projet (comme le tente le développement conventionnel), mais davantage à développer une compréhension plus profonde et partagée du travail à réaliser, puis d’améliorer vos prévisions à mesure que sont comblées les informations manquantes. Cela signifie que pour construire un meilleur plan de développement, vous devez commencer par le travail à effectuer maintenant. Cela inclut les tâches, la séquence des tâches et les interdépendances entre les fonctions afin que l’équipe puisse reconnaître les problèmes qui se profilent et agir à temps pour rester sur la bonne voie. En termes Lean, l’équipe peut déceler une situation anormale, tirer l’andon et utiliser des contre-mesures efficaces en temps voulu.

Cela repose sur des jalons efficaces, avec des énoncés d’objectifs clairs et des critères de qualité permettant de mesurer la réussite et de guider l’équipe tout au long de son parcours. En fait, les équipes ont souvent besoin de plus de choses que des jalons. Les jalons servant souvent de points d’intégration clés, il convient de placer des indicateurs précoces entre les jalons afin de protéger l’intégrité de ces points et de ne pas affecter d’autres lignes de développement. Ces indicateurs devraient être des prédicteurs fiables du succès des jalons. Même si vous vous réunissez tous les jours, si vous ne reconnaissez pas une condition anormale, vous risquez de réagir de manière excessive à des problèmes mineurs et de ne même pas remarquer la tempête majeure qui se profile à l’horizon. Trop de discussions de stand-up meeting sont vagues et conversationnelles et ne contribueront guère à résoudre les problèmes sans ces principes fondamentaux.

On peut voir un autre exemple de « voyage optimiste » dans la façon dont certaines équipes de développement abordent la fourniture d’entrants pour les produits critiques. Les équipes définissent souvent des objectifs, puis agissent comme si des attributs tels que la charge, les délais, les coûts ou autres ne feraient qu’évoluer « naturellement » hors du travail de développement, pour se rendre compte, seulement à la fin du projet, qu’elles se seraient trompées. Pour atteindre les objectifs fixés, il faut combler nos lacunes de connaissances au cours du projet. La création d’une trajectoire de réalisation simple décrivant les progrès attendus du point de départ à l’objectif ultime, en fonction d’activités spécifiques conçues pour combler ces lacunes tout au long du projet, permet à l’équipe de disposer d’un outil visuel qui révèle les situations anormales. L’établissement d’un pourcentage d’atteintes objectives liées à ces activités est un moyen efficace de matérialiser la trajectoire de réalisation.

Alors la prochaine fois que vous verrez des espaces indéfinis dans le planning, où des monstres pourraient se cacher, demandez à l’équipe le travail qui y est effectué. Remplir ces trous noirs peut être difficile. Après tout, vous créez une nouvelle valeur et une grande partie de ce que vous faites n’a pas été réalisée auparavant. Il y a tellement d’inconnues. C’est bon. Défiez votre équipe. Que sait-elle ? Les équipiers comprennent-ils les tâches, leur séquençage ou leurs dépendances ? En d’autres termes, comprennent-ils vraiment le travail à accomplir ? Si ce n’est pas le cas, vous aurez peut-être un problème beaucoup plus important que la bonne planification.

Article de Jim Morgan paru initialement en anglais sur le site du Lean Enterprise Institute : Use Lean Development Principles to Avoid « Traveling Hopefully » Down the Wrong Path