Gestion de projet fleuve, s’adapter aux contextes

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 ?

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.