Gestion de projet fleuve, s’adapter aux contextes

Noël-Arnaud Maguis 14 décembre 2021 ~ 7 minutes

En tant que consultant, démarrer un nouveau projet revient généralement à rencontrer une situation étrange. Parfois tout va bien et le bateau est calme et tranquille, mais souvent il y a des vagues. Dès le départ les choses peuvent s’annoncer compliquées et nécessiter un démêlage. Besoins imprécis, historique non documenté, bonne volonté de l’équipe en place, urgences récurrentes, technologie et monde fonctionnel à découvrir sont une toile de fond assez classique.

Fonctionnellement, le jeu va consister à créer un lexique de notion, rétro-documenter, à relier les points entre les différentes fonctionnalités et proposer un modèle cohérent avec la vision de l’entreprise.
Techniquement, choisir quoi construire, diviser proprement, supprimer, optimiser.

Avec un peu de chance, vous pourrez automatiser vos tests, vos déploiements et calmer votre relation avec l’infra de votre hydre vorace.
La bête, aussi complexe soit-elle, pourra être maîtrisée (ou abattue dans certains cas). Que mon propos soit clair, je n’entends pas par là que c’est facile ou rapide mais que la littérature converge sur ces deux domaines vers des bonnes pratiques.

Côté organisation et méthodologie en revanche, les choses peuvent se révéler beaucoup plus épicées pour arriver à un consensus. Trois grandes tendances cohabitent (cycle en V, frameworks agiles et Lean) et leur application devient complexe pour des équipes de grande taille ayant des typologies d’activités différentes¹. Il est assez facile d’arriver à des modèles mixtes où chacun est perdu, néanmoins quelques propositions existent :

Scrum nous propose Nexus et la proposition d’un product owner unique pour prioriser un backlog produit réparti sur plusieurs équipe ;
SAFe nous propose de synchroniser les cycles de travail de différentes équipes via une grosse étape de planification collective ;
Lean et son modèle de gestion par la mesure ;
et bien d’autres…

Généralement, une fois revues les structures classiques, vient le modèle Spotify². Il semble avoir fonctionné puis avoir évolué. Mais pourquoi ? Pour s’adapter oui, mais à quoi ? Et plus important, comment faire évoluer son modèle d’organisation sans que tout ne tombe ?

Modélisation de l’écoulement

Cette question me gratte depuis que j’ai démarré mon activité de consultant et a fini par me faire ressortir mes cours de physique. Nos différentes tâches de travail, demandes, réunions, pourraient être modélisées comme un écoulement de grains traversant une ou plusieurs personnes et soumises à la mécanique des fluides. Parfois l’écoulement est calme et maîtrisé, parfois totalement chaotique trois jours après.

Avec un modèle simple³ on tomberait sur le modèle de l’équation de Navier-Stokes sur les écoulements de fluide parfaits. Normalement tout va bien, de grosses têtes ont décrit le mouvement des écoulements, regardons un peu et la solution sera évidente. Voici le monstre :

Cette équation est insoluble sauf dans certains cas simplifiés⁴. C’est à mes yeux le point le plus important, on ne sait pas anticiper le déroulement d’un écoulement. Néanmoins, le job du physicien est de simplifier son modèle, quitte à le rendre un peu moins précis, et en travaillant un peu notre monstre nous arrivons au petit déterminant suivant appelé Nombre de Reynolds :

Nombre de Reynolds = ρvD/µ

D : Diamètre du tube
ρ : Masse volumique du fluide
v : Vitesse moyenne
µ : Viscosité

Ce nombre va nous servir à connaître la caractéristique dominante d’un écoulement pour rendre l’équation de Navier Stokes soluble (en rendant les forces de pression négligeables devant les forces visqueuses ou l’inverse). Si le nombre de Reynolds est petit, tout va bien, le flux sera prévisible et laminaire (une rivière calme). S’il est grand en revanche les choses vont se corser et l’écoulement sera turbulent (l’air sur une aile d’avion au décollage). Ce nombre et la simplification du modèle vont permettre ensuite son application au quotidien dans l’automobile, la santé, l’hydraulique…

Transposition

Quelques évidences quand on regarde ce nombre :

Si je diminue ma vitesse, mon nombre de Reynolds va être plus petit et rendre mon flux de travail plus maîtrisable.
Plus mon fluide est léger (tâches moins complexes, mieux définies), plus l’écoulement est maîtrisable.
Plus mon diamètre est large (pour moi l’équipe qui reçoit le flux), plus j’ai de chance que ça se passe de façon laminaire. Mais attention, on ne parle ici que d’un flux, pas de plusieurs mélangés.
La viscosité, c’est la capacité du liquide à être gluant et de coller aux parois. Ça pourrait être vu de plein de façon différente, mais je la perçois dans mon quotidien comme la capacité à se déplacer dans l’existant (une bonne vieille application à retoucher sans documentation aurait pour moi une viscosité haute). D’un point de vue théorique, la viscosité est reliée aux interactions des grains les uns entre les autres.

Pour appliquer ces règles à des flux complexes avec beaucoup de ramifications, nous allons les trancher à leurs différentes interfaces et les étudier morceau par morceau pour séparer les activités et les flux de manière cohérente… Ce qui donnerait les quelques règles suivantes pour rester dans un régime gérable.

L’interface entre un tronçon et un autre doit être claire (pour qu’il y ait une réelle continuité par exemple entre le flux de création des besoins métiers, celui de réalisation et celui de la gestion de la production).
Les entrants dans un flux de travail doivent être de taille/type régulier.
La vitesse moyenne doit être régulière (idéalement éviter des éléments qui doivent circuler très rapidement et d’autres très lentement dans le même flux, sans quoi ça peut valoir la peine de les séparer).
Des flux de travaux ne doivent pas être mélangés (on évite au maximum le multiproduit et la multiactivité).
L’équipe doit être de taille adaptée à la taille du flux (les étapes où l’équipe est la plus restreinte en nombre de personnes seront déterminantes pour le comportement du flux).
La complexité de l’environnement ne doit pas évoluer de façon soudaine.

À partir de là, les différents modèles Nexus, SAFe et autres ne seraient plus que des propositions pour gérer des flux de travaux suivant ces règles adaptées à des contextes précis, et le modèle Spotify une adaptation à leurs contraintes de l’époque avant eux aussi d’évoluer.

Conclusion

Quelques pistes peuvent permettre de choisir des modèles traditionnels et d’essayer de nouvelles choses :

Kanban et toute la méthodologie Lean a montré sa capacité à être utilisé dans des industries de haute précision occupant des milliers d’employés sur le même flux de travail.
Les méthodologies prédictives (cycle en V) savent se montrer très efficaces quand le besoin change peu entre le début et la fin d’un projet.
Les méthodes agiles ont fait leurs preuves dans des contextes changeants et de grande taille.

L’équation que je vous présente ici n’est pas une solution, mais un socle qui m’a permis de réfléchir à des situations complexes. Supprimer des goulots d’étranglement, mélanger des typologies d’activités ou encore créer des silos dans des équipes multiproduits n’ont pas attendu d’être pointées du doigt par un modèle pour être qualifiées de mauvaises pratiques. Néanmoins quand le doute pointe le bout de son nez, elle aide à trancher. Son point le plus important à mes yeux est de ne pas négliger l’importance d’avoir des interfaces nettes et des entrants de qualité pour chaque tronçon de flux de travaux complexes.

Une autre question est posée par les équations de Navier Stokes, celle de choisir volontairement de travailler dans un environnement où le flux de travail est organisé pour être chaotique et imprévisible de façon durable. À ce jour je n’en ai jamais rencontré en entreprise mais serait intéressé de pouvoir découvrir via la communauté si des précédents existent.

↑ Les plus curieux pourront jeter un œil au PMBOK version 7 sorti en 2021, qui abandonne le dogme du 100 % cycle en V prédictif pour aller vers plus d’adaptations au contexte. Une révolution pour ce gardien du temple de la gestion de projet prédictif.
↑ Des Équipes de 10 personnes maximum regroupées elles mêmes dans des Tribus hébergeant plusieurs Équipes travaillant sur le même thème. Le tout traversé transversalement par des Chapitres (nombre dépendant du nombre d’équipes) hébergeant une ou plusieurs personnes de chaque équipe pour assurer une vision globale du projet. Dernier élément, des regroupements de personnes aux profils similaires appelées Guildes pour aider au développement des compétences. Ce modèle a été inventé par Spotify et a aujourd’hui évolué vers d’autres formes.
↑ Fluide parfait non déformable.
↑ Des recherches sont en cours pour lui trouver une solution, mais elle ne sera pas triviale. C’est une équation non linéaire, qui peut vous aider à occuper vos dimanches soirs. 😁