Conseils pratiques : Scrum en latin et la messe en chinois

Après la démystification des points de complexité traitée dans le précédent article, observons deux exemples assez amusants du camouflage "Agile" : l’affichage mural incompréhensible et l’absence du graphique d’avancement.

Au-delà de la jolie couleur des murs de Post-It, l’affichage mural est un outil indispensable à l’agilité et aucune technologie ne peut le remplacer actuellement. Lorsque qu’un tiers intéressé par l’état du projet souhaite une vision précise et « temps réel » de son avancement, il n’a pas à déranger un chef de projet (qui en Scrum n’existe plus je vous le rappelle), ni à perturber le travail de conception-développement effectué alors par équipe

Platon, disciple de Socrate, était certainement Agile. Dans son allégorie de la caverne, il donne une représentation imagée de l’état de notre nature relativement à la connaissance et à l’ignorance. « Nous sommes alors soumis à la peur de la remise en cause de nos opinions, de nos croyances, de nos illusions. Pour sortir de l’ignorance, il est nécessaire de changer ses habitudes et ses certitudes confortables. Il faut mourir et renaître. Mourir à une certaine réalité pour renaître à une autre. » C’est malheureusement ce que refusent de faire ceux qui, confrontés à la nécessité d’un changement, tentent de l’éviter en maquillant la réalité qui ne leur convient pas plutôt que de changer cette réalité elle-même. Pour illustrer cette métaphore, je vous ai choisi quelques petits exemples issus de mes expériences liées aux tentatives d’« agiliser » les projets de développement de systèmes d’information.

La manipulation des responsabilités des acteurs

En premier lieu, je le constate régulièrement, des organisations «scrumisantes » passent encore un temps fou à redéfinir les rôles du Product Owner ou du ScrumMaster. Grande nouvelle : cela a déjà été fait par Schwaber et Beedle en 2001. De plus, on peut trouver cette information dans les 19 pages du « Scrum guide » en franglais, ou bien sur la page Wikipédia francophone dédiée à cette méthode. En revanche, si ces définitions ne vous conviennent pas, inutile de les remettre en question, il suffit d’adapter votre organisation pour en respecter la forme et, surtout, le fond.

Le camouflage linguistique des rôles exacts

En second lieu, je me refuse à comprendre la perversité de baragouiner en franglais. Je veux bien le reconnaître, cela sert de cache misère à des rôles aussi simples que la notion de « responsable du produit » et d’« animateur facilitateur », mais bon, le vernis, même épais, ne répare pas les crevasses. À l’évidence, si Scrum semble être pour certains un acte de foi, ses adeptes pourraient prendre exemple sur le concept de la messe en latin évacuée par Vatican 2. Laquelle, malgré son charme indéniable n’était finalement pas plus abstraite qu’un standup meeting de complaisance devant un kanban « bidonné ». Si je vous dis cela, c’est simplement pour en parler; mais j'attendrai pour écrire la suite la prochaine étape de dissimulation qui sera certainement plutôt un genre de Vatican 3 où la messe se ferait en chinois et la « scrumisterie » en latin.

Redevenons sérieux et soyons précis. Après la démystification des points de complexité traitée dans le précédent article, observons deux exemples assez amusants du camouflage « Agile » : l’affichage mural incompréhensible et l’absence du graphique d’avancement (BurnUp chart).

Parmi les valeurs Agiles se situent en tout premier plan les principes de transparence et de simplicité dans la communication. Il en découle naturellement une forme actuellement incontournable de mise en œuvre : l’affichage mural. Lequel doit être mis à jour en temps réel par les acteurs de l’action eux-mêmes et visualisable en permanence. L’observation de nombreux manquements à ces règles dans les projets de diverses entreprises m’amène à devoir préciser la raison d’être et le contenu du reporting Agile basique.

Le concept d’affichage mural

Au-delà de la jolie couleur des murs de Post-It, l’affichage mural est un outil indispensable à l’agilité et aucune technologie ne peut le remplacer actuellement. Lorsque les murs deviendront des écrans offrant quelques milliards de pixels, on en reparlera, ainsi que de la possibilité de s’affranchir des distances entre acteurs du projet.

Un affichage mural efficient doit offrir la transparence d’une mise à jour « temps réel » des tâches débutées et achevées. De plus, son contenu sera naturellement validé lors du « double check » constitué par les déclarations des « stand up daily meeting ». Lorsque qu’un tiers intéressé par l’état du projet souhaite une vision précise de son avancement, il n’a pas à déranger un chef de projet, ni à perturber le travail de conception-développement effectué alors par équipe. Laquelle, n’est peut-être d’ailleurs même pas au complet à ce moment-là. Grâce au reporting mural, l’information souhaitée est immédiatement obtenue avec la certitude de sa fraîcheur.

Note : La conservation des mêmes informations sur un support électronique a un intérêt sécuritaire indiscutable, mais c’est la seule raison de doubler le travail initialement réalisé sur le mur. En revanche, toute autre forme de reporting exigé devra faire l’objet d’un Post-It valorisé en unités de valeur de production et son demandeur devra être conscient qu’il réduit d’autant le périmètre fonctionnel qui sera livré.

Le contenu de l'affichage mural

Un affichage mural basique comprend trois éléments :

La liste des freins et des obstacles (pas de Post-It, trop facilement éliminables après résolution de la problématique et donc ne permettant plus de « tracer » à posteriori les déperditions de temps et d’énergie ayant éventuellement pénalisé le projet - avec Scrum nous sommes en périmètre variable, je vous le rappelle).
Le kanban de production. Pour un projet de développement informatique, il comprend (à minima) les cinq ou six colonnes suivantes : fonctionnalités à produire, tâches découpées, éléments en cours de production, éléments testés techniquement, éléments acceptés fonctionnellement (la notion de « backlog de sprint » étant une simple facilité visuelle).
Le graphique d’avancement du projet (Burn-Up chart). Il matérialise la vélocité des sprints en termes d’unités d’œuvre produites et acceptées par le propriétaire du produit (done). Bien évidemment vous y intégrerez les notions de « livré utile » et de « livré abandonné » pour un « livré total » de préférence égal ou supérieur à la ligne de « vélocité théorique initiale ». C’est sur cette information que vous avez basé toutes les hypothèses sous-tendant l’organisation de votre projet et que le propriétaire de l’application aura calculé le retour financier espéré justifiant son investissement.

Cette partie du reporting est nécessairement standardisée

Certes, elle est utile à l’équipe, mais elle est aussi à destination des acteurs « hors projet » souhaitant disposer d’une vision de son avancement. Il en découle que tous les projets doivent respecter une structure de Post-It unique et les mêmes techniques d’affichage. Dans le cas contraire, imaginez la déception du dirigeant qui, passant sur un plateau où de nombreux développements sont en cours, constate des affichages différents qu’il ne comprend pas. Cette recherche d’uniformité implique aussi l’obligation d’une métrique en « journée idéale » et disqualifie les « points de complexité relative » (unité d’œuvre différente de « projet à projet »). Malgré l’effort ainsi décrit, le reporting du lotissement (Sprint) est tout à fait insuffisant et parfois même illisible et sans un graphique d’avancement du projet (BurnUp chart). Il faut en être conscient, c’est le seul outil de synthèse immédiatement assimilable par un dirigeant au premier coup d’œil.

Note : Une autre partie distincte d’affichage peut être spécialisée - par et pour l’équipe. En effet, chaque projet est souvent différent des autres en termes de contenu ou de préoccupations, que ce soit de l’équipe ou des autres acteurs impliqués. Une zone d’affichage complémentaire à l’affichage standard peut alors être élaborée en regard de ces spécificités. Ces aspects feront l’objet d’un prochain article que je cosignerai avec un autre coach Agile. Néanmoins, et il faut le garder en permanence à l’esprit, selon l’Agile Manifesto, la meilleure communication est celle du face à face. Dans cette optique, l’équipe dispose déjà pour sa communication de nombreuses possibilités : le contact direct informel, les réunions journalières, les réunions spécifiques à un problème particulier et les rétrospectives. Il faut donc avoir une excellente raison pour justifier d’une formalisation murale autre que les trois premiers points élémentaires précités. Dans le cas d’un manque de surface murale, l’usage de tableaux sur roulette est un bon moyen de multiplier la surface utilisable…