10 – Management visuel, Radiateur d’information

Sans un reporting mural simple, standardisé, visible et compréhensible par tous, pas d’agilité réelle. Utilisant les murs de la War room ou de la SWAT room, le Big Visible Information Radiator agrège en un point toutes les informations de réalisation et indique en temps réel l'état d’avancement, les freins ou obstacles.

Ce dixième cartouche de la boîte à outils méthodologique "Continuous Sprint 0 et au-delà" se situe dans la partie "au-delà". Plus précisément, il fait suite aux activités de Cadrage et de Design, dont l’aboutissement se matérialise dans le backlog de produit.  En clair, cet article traite d’activités de contrôle opérationnel – souvent oubliées – mais pourtant indispensables à la maîtrise d’une Réalisation en mode Agile réellement "Adaptatif". 

Le Radiateur d’information, sa raison d’être

Considéré comme la base indispensable aux développements Agiles, cet outil s’impose d’ailleurs comme le principal moyen de communication de SAFe durant les deux jours de sa planification d’incréments (PIP). Ces deux journées de synchronisation (par trimestre) s’avèrent évidemment insuffisantes à combler les attentes d’une agilité dévoyée dans un contexte se limitant à quelques pratiques d’amélioration continue.  Au final, il faudra pourtant se contenter de ce « mieux que rien » qui malheureusement fait de plus en plus les frais de la délocalisation des développements combinée à des restrictions budgétaires.

L’observation de nombreux problèmes liés à l’absence de l’affichage mural m’amène à préciser sa réelle raison d’être et son contenu minimum. Un Radiateur d’information efficace conjugue une surface et un positionnement permettant une vision globale et compréhensible de la construction du produit. Aisé à interpréter et à mettre à jour, ce "cockpit du développement" conserve le focus sur l’information opérationnelle, en facilite la compréhension, et permet de réduire les pertes de temps liées au reporting classique. L’équipe adaptera éventuellement une zone de cet espace en fonction de ses propres besoins de visibilité. Un ouvrage de 2001 traitait déjà de ces aspects : The Visual Display of Quantitative Information. Il est probable que cette vision ait eu pour source le principe de l’obeya appliqué par le Lean. Obeya en japonais signifie « la grande salle » dans laquelle s’obtient une approche coopérative et s’élaborent des décisions consensuelles. Depuis l’apparition du program increment planning de SAFe, qui, en deux journées de travail coopératif, concatène la vision et la roadmap de dizaines d’équipes-produit (Feature Team), l’affichage mural retrouve enfin toute sa cruciale raison d’être.

Dans le domaine des systèmes d’informations, le fondement de cette communication qualifiée "d’osmotique" a pour origine l’organisation de la SWAT Team et de sa War Room mises en œuvre par la méthode Rapid Application Development à partir de 1991. L’objectif principal du Radiateur d’information était alors d’offrir une compréhension intuitive, immédiate et obtenue d’un seul coup d’œil, des "pourquoi" et "comment" du développement en cours.  Pour certains, ces notions pratiques se couplent avec une vision plus coopérative de l’engagement des ressources humaines : "Sur les murs, il faut donner aux gens un sens de leur travail, qu’ils puissent intuitivement se positionner dans la mission de leur groupe, dans leur journée et dans l’espace d’exploration de leurs problèmes." Le management visuel permet alors de créer un espace de pensée portant bien au-delà d’un simple pilotage des plans d’action. Comme le précise Jean-Claude Grosjean «L’Information radiator est à la fois le symbole de l’Esprit Agile et sa représentation la plus concrète. Il donne de la visibilité à tous les acteurs en mettant le focus sur la transparence de l’essentiel. Il suscite l’intérêt et les échanges."

Le cockpit du développement

Parmi les quatre valeurs Agiles portées par le Manifeste se situent la communication et l’acceptation des changements ; l’affichage mural en représente la forme incontournable de mise en œuvre. La vision élémentaire de ce type de reporting comprendra basiquement trois éléments indissociables :

1. La liste des freins et des obstacles (pas de post-it car facilement destructibles),
2. Le kanban de production comprenant (à minima) les colonnes suivantes : fonctionnalités à  produire (Ready), tâches découpées, éléments en cours de production, éléments testés techniquement, éléments acceptés fonctionnellement (Done),
3.  Le graphique d’avancement  (Burn-Up chart) qui matérialise le résultat des sprints exprimé en unités d’œuvre engagées, réalisées et acceptées par le propriétaire du produit.
   

Au-delà de ce minimum se trouveront présentées diverses autres informations telles que : objectifs avec valeur métier, risques principaux et plans d’actions, dates clés, modélisations diverses, descriptions sommaires de processus, définitions des états du développement (ready, done, etc.), et d’une manière générale tout ce qui peut apporter un plus à la compréhension ainsi qu’à l’engagement des ressources humaines. En pratique, le Radiateur d’information s’avère nécessairement standardisé, car les données présentées se partageront avec des acteurs "hors équipe" souhaitant disposer d’une vision de l’avancement du produit en cours de réalisation. Il découle de cet impératif que tous les "projets-produits" doivent impérativement respecter le même format de techniques de rédaction et même de structures de post-it. Une autre partie, distincte, de l’affichage basique, peut présenter une spécialisation technique propre à l’équipe, mais cet aspect doit demeurer l’exception. Une zone complémentaire à l’affichage standard sera alors élaborée en regard de ces spécificités. Dans tous les cas, il faudra garder en permanence à l’esprit que la meilleure communication reste celle d’un face à face direct et immédiat (première des valeurs Agiles).

La qualité d’un affichage mural impose sa MAJ permanente

La mise à jour du Kanban ainsi que des autres informations doit impérativement se faire en temps réel. Attendre, même une simple journée, pour s’aligner sur le stand-up meeting s’avère une erreur. D’une part le modèle de pilotage s’écarterait de la réalité, et d’autre part les acteurs pourraient très bien ne pas se trouver plus tard en mesure d’apporter l’information manquante. Les autres avantages de l’affichage mural en temps réel sur les anciennes formes de reporting sont nombreux. Par exemple, lorsque ces informations sont conservées dans des outils automatisés, il est rare que les dirigeants et autres "stakeholders" y accèdent. Lorsque ces derniers souhaitent obtenir une vision de l’avancement, ils interrogent généralement le chef du projet. Lequel dérangera alors à son tour l’équipe - en admettant que tous ses membres soient présents - pour obtenir l’information à jour. Avec le reporting mural en temps réel (figure suivante), une personne sensibilisée à sa lecture dispose de l’information complète et actualisée, accessible d’un seul coup d’œil et sans perturber le travail de réalisation. 

Note : la notion de "temps réel" doit être prise au sens propre. La tâche "encours" sera passée à "testée technique" à l’instant même de sa finalisation. L’engagement de la tâche suivante s’effectuera au moment même où la ressource débutera son exécution.

La mise en œuvre du principe venant d’être décrit représente un niveau de professionnalisme sans commune mesure avec les trois colonnes habituelles du "ScrumBan" (en attente, en cours, terminée). Lesquelles néanmoins sont souvent suffisantes au Métier lorsqu’il pilote la production de sa liste des fonctionnalités (backlog). Dans les salles dédiées modernes, l’ensemble des murs se trouve magnétisé afin de fixer des post-it aimantés. Ces surfaces, le plus souvent blanches, s’utiliseront aussi comme paperboard géant. En ce qui concerne le "daily stand up meeting" - une rétrospective quotidienne dont le but est d’obtenir un feedback au plus près de la situation - cette réunion se tient devant cet affichage qu’elle explicite. De ce fait, la transparence de la réalité des préoccupations rencontrées n’est pas camouflable ou adaptable. Détail d’importance, la liste des "Freins et obstacles" s’avère toujours la première information à coller sur le mur (n’attendez pas des jours après les premiers ennuis pour le faire, sinon vous en arriverez à une situation conflictuelle parfois inimaginable et souvent destructrice des relations de bienveillance).

Je vais maintenant vous détailler le cheminement d’une personne hors équipe (généralement un manager ou un représentant du métier) souhaitant disposer d’une idée de la situation encours lorsque les premiers signaux faibles caractéristiques d’un problème en devenir lui parviennent. 

1. En mode classique, notre "partie prenante" envoie des messages auxquels elle obtient parfois des réponses aussi généralistes que "bidonnées". Ensuite, elle se décide à rencontrer un responsable du développement pour obtenir un point actualisé. Comme le chef de projet ne produit son rapport d’avancement que tous les mois dans le meilleur des cas, il devra certainement rechercher une info récente. Pour ce faire, on dérangera toute l’équipe qui sera généralement et malheureusement incomplète (absences diverses). L’information obtenue sera donc relativement inutilisable en l’état. Il faudra donc attendre le retour des absents. Entre temps les premières données seront devenues partiellement obsolètes, d’autant que d’autres ressources ne seront alors plus présentes. Je n’irai pas plus loin, mais vous avez compris.
2.  En mode Agile, en premier lieu on observe le graphe d’avancement exposant les sprints déjà terminés. En cas de mauvaise surprise, on cherche les éventuelles raisons des problèmes dans la liste des freins et obstacles. Ensuite, éventuellement, sera analysé le kanban où se présente - mis à jour en temps réel – l’état du sprint en cours. Sans cette démarche, qui en aucun cas ne doit déranger l’équipe engagée dans le développement, nous plongeons droit dans le principe du "grand dérangement". 

De plus, sans la présence de ce management visuel basé sur un affichage mural compréhensible, il est très rare que les parties prenantes externes à l’équipe se donnent la peine de consulter des outils leur étant souvent inconnus et d’accès relativement complexe (même si l’usage de Jira et de Confluence gagne régulièrement du terrain). Au final, le contexte favorise alors la continuation du grand "flou" jusqu’à la découverte de la réalité.

Pour SAFe en particulier (sujet détaillé dans le cartouche 9), la notion de "product management" implique sur l’ensemble des quatre niveaux que tout est Vision en backlog, et que tout est roadmap en Kanban. Il serait aussi possible d’écrire que tout est synchronisation et cadence, que ce soit de planification comme d’exécution.

Note : Les notions de rentabilité se trouvent gérées par les epics owners et les business owners tel que décrit dans le cartouche 02 (Justification économique, lean start-up / Canvas).

Grâce à la puissante simplicité d’une métrique simple mais formelle, la maîtrise des évolutions d’un contrat Agile devient tout à fait possible. Cela inclut changements comme abandons de travaux en cours, ou même achevés. Cette opportunité d’atteindre un principe fondamental Agile se base sur l'évaluation initiale du périmètre connu à produire. Une technique comme le jeu d'estimation consensuelle (Planning poker game) sera utilisée à cet effet. Ce principe exprime en unités d'œuvre (telles les "points standardisés SAFe" ou les "journées non idéales" par exemple) un engagement de l’équipe sur des objectifs globaux. Ces éléments évalués représentent la base du contrat initial passé entre le métier et l’équipe. Le contenu fonctionnel pourra ensuite être modifié - en permanence et même en cours de développement - par le Métier (afin de respecter les première, deuxième et quatrième des valeurs agiles sans perte de contrôle de la vélocité). Ces aspects seront traités dans le prochain cartouche numéro 11. Le Post-it nécessaire à la mise en œuvre de cet avantage se trouve sur la figure suivante (basée sur mon "tampon à post-it" personnel que je vous conseille de faire reproduire). Par contre, il s’avère très rare que la fonctionnalité complète et tous ses cas de tests y soient détaillés. Dernier détail pratique, l’aspect éphémère de ce simple autocollant impose une conservation des descriptifs de fonctionnalités sur un support plus pérenne (Excel ou un outil spécialisé).

Note : L'acceptation du mode adaptatif permet au client de modifier ses exigences en cours de projet (deuxième, quatrième et sixième des principes du Manifeste Agile), mais aura pour conséquence l'éventualité d'un périmètre variable. Dans la plupart des projets conséquents ou stratégiques, des contraintes de planifications plus nombreuses seront prises en compte afin d'optimiser le pilotage de la réalisation.

Le fond du problème est structurel et stratégique

Un problème majeur posé par l’adoption de l’agilité dans les grandes entreprises se situe dans la structure même de leur organisation. Lesquelles sont habituellement issues d’un passé informatique très proche et même parfois de la réalité d’un présent consacrant un abîme géographique entre la localisation des métiers et celle des développeurs. Cette situation représente classiquement l’héritage direct d’une vision des développements de SI organisés en projets suivant le mode "cascade" ; c’est-à-dire séparant la production d’un document (descriptif du besoin obtenu dans une première phase) du développement global envisagé dans une phase suivante (souvent dans un autre lieu avec d’autres personnes). Les exigences premières des projets de digitalisation avaient rendu cette vision basée sur une documentation détaillée "à distance" obsolète et dangereuse, d’où l’émergence dans les années 90 des méthodes itératives et adaptatives. Il est donc d’autant plus étonnant que certaines entreprises, et parfois parmi les plus concernées par cette problématique, s’engagent encore actuellement dans le maintien d’une telle aberration par absence de réelle volonté de transformation.  

Autre point majeur, dans une entreprise, quelle que soit sa taille, lorsque le siège regroupe physiquement informatique et métiers, l’adoption de l’Agile n’est généralement pas un problème sous peu que les partenaires s’engagent dans cette voie de la performance par l’échange direct. En revanche, si ces entités sont géographiquement distantes, il devient évident que les technologies actuelles de communication tentant de réduire cette fracture, ne correspondent malheureusement pas encore aux exigences du pilotage des projets Agiles et du management visuel. D’ailleurs à ce sujet, le pilotage n’est pas la préoccupation fondamentale, celle-ci demeurant toujours l’impératif de « spécification-codage-tests-validation » en mode de contact direct et immédiat. À défaut de pouvoir obtenir le regroupement global d’entités gigantesques, il faut alors décentraliser la fonction informatique au cœur du métier ; et ce pour chaque métier. Autant le dire tout de suite, ce genre de restructuration, pourtant vitale, n’est ni si simple à imaginer, ni aisée à mettre en œuvre.

Conclusion pragmatique "au pied du mur"

Pour Catherine Berliet, Directrice Cabinet Conseil Éponyme : en synthèse, les avantages du management visuel sont sans conteste une capacité à :

• Inscrire et transcrire une visibilité de l’activité,
  
• Pointer rapidement les dérives des processus en cours,
  
• Souligner les deltas entre les attendus et les livrables,
  
• Identifier les causes racines des freins et des obstacles,
  
• Représenter l’organisation, ses flux, ses process et interconnexion,
• Apporter une vision à 360° de l’activité,
• Instaurer une boucle de feed-back continuelle.

Selon Jean Claude Grosjean (sur son blog QualityStreet au sujet de l’affichage mural) « Il permet aussi de faire prendre conscience aux équipes qui utilisent des outils électroniques comme Jira pour gérer leur Taskboard, que l’Esprit Agile, le Management Visuel, et les bénéfices de l’Agilité vont au-delà du simple tableau Kanban… » comme l’exprime la figure suivante  - très sommaire - mais qui couvre en synthèse l’ensemble de ces problématiques : du Cadrage et de la Conception, au management de la Réalisation et à son reporting).

En clair, selon moi, ces outils ne sont que de simples palliatifs à l’incapacité de mettre en œuvre une agilité réelle. Ne l’oublions pas, la première des quatre valeurs fondamentales s’énonce ainsi "Les individus et leurs interactions plus que les processus et les outils" et se décline en deux principes :

1. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
2. La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Au final, selon mes expériences, aucune des contraintes basiques dont voulaient s’affranchir les méthodes agiles originelles n’ont disparu. Imaginer autre chose, c’est simplement ne rien avoir compris à l’essence même de l’Agilité… Après la priorité numéro 1 - qui consiste à doter l’équipe des environnements de travail et de production - le "reporting mural" représente un impératif de vision et d’organisation vital pour la performance. En clair, rien n’est plus utile à la maîtrise d’un réel pilotage des développements. Ne nous y trompons pas, ces nécessités de mur physique et de Post-it papier perdureront aussi longtemps que la technologie ne permettra pas de fournir des écrans muraux tactiles d’une définition suffisante pour se substituer parfaitement à un type d’affichage paraissant ancestral - mais toujours indispensable à la mise en œuvre de l’Agilité. D’ailleurs, lorsque nous disposerons de ces murs composés de milliards de pixels, la distance entre les acteurs d’un projet disparaîtra du même coup, puisque tous sembleront présents au même endroit, qu’ils se situent dans la pièce, dans l’immeuble voisin ou sur un autre continent. 

Ici le lien de l’interview par OeilDeCoach où j’explique l’origine de ma démarche méthodologique.