Se confronter, se comprendre, s’enrichir : Retour terrain

Cet article fait suite à un précédent article. 

La confrontation…  

Cet article est un retour d’expérience, sur une période où j’ai eu à interagir avec des équipes en pleine transformation agile et un processus de livraison très normé, hérité du mode Cycle en V. C’était la première grosse livraison ou les modes de fabrication et de livraison n’étaient pas similaires. Un test à balles réelles. 

De plus les équipes expérimentaient la fabrication en tant que Squad autonomes. Les Chefs de projets avec leur rôles transverses avaient été remplacés par des scrums masters centrés sur les squads. 

J’étais membre d’une équipe dont les rôles et responsabilités étaient d’organiser la qualification technique et la mise en production d’un « produit » complexe . Ce produit pesait plusieurs milliers de jours de budget et étaient construit par plusieurs dizaines de squads contributrice. 

Moi qui suis un adepte du « livrer petit et souvent », des boucles de feedback courtes et des équipes avec qui on peut partager une pizza j’avais de nombreuses appréhensions. 

…Un dialogue de sourd ?  

De prime abord on peut se dire qu’échanger avec des chefs de projet traditionnels aurait dû nous amener irrémédiablement à l’affrontement : parce qu’eux sont orienté coût fixe, délai fixe et que la variable d’ajustement est la qualité. Alors que côté Delivery, nous sommes plutôt Lean et amenés à considérer que la qualité est un des seuls critères non négociables … 

Bien sûr, le délai de livraison fut fixé. 

La capacité de production n’étant pas extensible à l’infini, nous avions des craintes quant à la qualité finale et l’opérabilité du SI après cette livraison… Mais en nous appuyant sur nos lectures, nos expériences passées, nous avons pu arriver à une opération réussie. Peu d’anomalies bloquantes, une ouverture de service sans heurts et un indice de satisfaction de 90% des utilisateurs du produit suite à la bascule. 

Selon Rick Dove, L’agilité c’est L’adaptation à un contexte incertain changeant et ambigu. Et bien là nous avons été servis, comme toute équipe de Delivery réceptionnant un projet en retard. 

 Ensuite, notre culture d’équipe et mes lectures m’ont aidé à voir plus clair. Notamment le livre Age of Agile de Stephen Denning, dans lequel l’auteur utilise trois lois pour proposer une définition d’une organisation ou un système Agile.

La loi de la petite équipe  

Afin de résoudre des problèmes complexes, il faut découper le travail afin qu’il puisse être géré par des équipes pluridisciplinaires. Et ce, avec des boucles de feedback courtes, plutôt que de créer une organisation complexe pour le résoudre.  

Cette opération de delivery a fonctionné grâce à un noyau d’acteurs soudés, se partageant les rôles et les responsabilités. 

Ce noyau évoluait au gré des besoins et des phases. Chaque membre avait une caractéristique commune : l’implication et l’envie du travail bien fait. 

La loi du réseau   

Plutôt que d’avoir une organisation en silo très hiérarchisée, il faut mettre en place des réseaux de petites équipes qui coopèrent vers un objectif commun. Le réseau est la somme de toute les équipes qui le compose.  

Les équipes produits parfois éparpillées se sont mises à collaborer en réseau de référent au fur et à mesure que l’échéance se rapprochait. 

Notre équipe prenant le rôle d’interface, de courroie d’entrainement. 

La loi du client  

Peter Drucker en 1954 a théorisé le fait que le client est le centre du monde, que les entreprises tournent autour et non l’inverse….  

Nous nous sommes adaptés à nos clients plutôt qu’être centrés sur notre Processus.

Se comprendre …  

La synthèse entre la gestion de projet traditionnelle et les méthodes de maîtrise de processus empirique est complexe, et donc nous avons choisi de nous recentrer dans un premier temps sur notre rôle principal :  la préparation du delivery en production.

Au début le produit était instable et son périmètre ressemblait à des sables mouvants. La vision des squads s’arrêtait à la fin du build. Dans leur DOD n’apparaissait pas la notion d’incrément potentiellement livrable en production. 

Aurions-nous pu rester bloqués ? En disant qu’on ne prépare la mise en production qu’à nos conditions de service, et que quand le produit est prêt à être livré ? 

Les équipes projets auraient pu se borner à dire qu’au-delà de la recette fonctionnelle, ce n’était plus leur problème. À ce stade, nous aurions pu frôler la caricature et camper sur nos positions respectives. 

Mais nous avons réussi collectivement à prendre de l’altitude pour dépasser l’obstacle. Nous avons assoupli notre processus de qualification pour prendre en compte les contraintes projets. Le dialogue avec les équipes produits, bien que perfectible, a eu lieu. 

Les équipes produits ont pris en compte nos besoins de visibilité et de traçabilité des livrables. Peu à peu, d’un rôle de contrôle Douanier, nous avons pu passer à un rôle de co-construction avec des relais dans les équipes produits. Nous sommes ainsi arrivés à une situation globalement maitrisée pour une MEP de cette ampleur. Ce fût un moyen de mettre à l’épreuve mes convictions et de les renforcer.  

Je me suis un peu inspiré d’Alexis Monville et de Michael Doyle en allant piocher pour me ressourcer, durant cette période, dans “I’m a software Engineer I’m in charge”. 

Nous avons également appliqué des bonnes pratiques de Chef de projet traditionnel.

Nous avons utilisé le RIDA (Relevé Information Décision Action), la gestion des risques et des supports de comité de suivi et de projet adapté au sujet Qualification et Bascule en production. 

Les points d’échanges récurrents ont été des boucles de feedback régulières. Cela nous a permis de fédérer les équipes produits parfois perdues dans les méandres des processus de livraisons (règles complexes, interlocuteurs non dédiés).

Or, vous savez comme moi qu’il n’y a pas de mise en œuvre de l’Agilité sans excellence et implication, et que donc la discipline est une base. Et puis, plus on conversait avec nos homologues projets, plus on a su adapter notre démarche et ainsi progresser. 

Ce que nous aurions pu mieux faire est en cours d’analyse. De toute façon, ce n’est pas le plus important, on ne peut pas changer le passé. Alors concentrons-nous à construire un futur rêvé…

Conclusion 

Dans le manifeste Agile, il est écrit : “Nous découvrons de meilleures façons de développer des solutions, par notre propre pratique et en aidant les autres dans leur pratique.”  

Et bien si vous êtes dans cette posture, vous allez aider les équipes avec qui vous allez interagir. 

Je terminerais ainsi : j’espère que vous aurez cela en tête, la prochaine fois que vous aurez à agir avec des acteurs dont les besoins et motivations vous semblent éloignées des vôtres.  

Enfin, comme le disait Abraham Lincoln : ”I don’t like that man, I must get to know him better”.