Se Confronter , se comprendre, s’enrichir 

La confrontation .. 

L’origine de cet article est un ressenti partagé lors d’échanges avec des collègues portant des valeurs Agiles comme moi. 

Je ressentais lors de ces échanges un soulagement, une liberté de parole que je ne retrouvais pas dans mon cadre de travail avec des collègues ayant des postures et des outils plus rigides et prescriptifs. 

Sans nier le fait que préférer des échanges avec des personnes ayant un socle de valeurs proches du notre est naturel je me suis demandé quel est le bilan de ces confrontations avec des personnes qui ont assez peu de convictions communes avec moi. 

J’examine dans cet article le cas particulier Agile vs Waterfall mais libre à vous de vous poser la question dans un cadre plus général…. 

…au risque de se compromettre ? 

De prime abord on peut se dire qu’échanger avec des chefs de projet traditionnels va nous amener irrémédiablement à écouter le point de vue de l’autre et à faire des compromis sur les valeurs et les principes des méthodes agiles en général et Scrum en particulier.  

Pourquoi ? Parce que l’Agilité se base sur des valeurs, des principes, de la confiance et du respect qui peuvent si vite être balayés d’un revers de main face à du “process”, du “reporting”, de la “planification”, un engagement de périmètre. 

Le compromis sur ces valeurs peut amener à des dérives méthodologiques …un simple cadre vidé de ses fondements. 

  • Qui n’a pas eu à se confronter à des estimations d’User Stories transformées en jour hommes et en dates d’échéances ? 
  • Qui n’a pas vu les engagements de l’équipe lors d’un sprint planifiés par le product owner ou la hiérarchie traditionnelle au-dessus ? 

A ne valoriser que le “framework », en se laissant envahir par une culture et des process dont les cadres ne servent qu’à rassurer, on peut assister à une course effrénée aux certifications  SAFe, ITIL, PMP, Scrum, et avoir oublié l’essence même de l’agilité :  

L’adaptation à un contexte incertain changeant et ambigu. 

Stephen Denning dans the Age of Agile utilise trois lois pour proposer une définition d’une organisation ou d’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 avec des boucles de feedback courtes plutôt que de créer une organisation complexe pour le résoudre. 

  • 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. 

  • La loi du client 

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

Se comprendre … 

Vous conviendrez également que faire une synthèse entre la gestion de projet traditionnelle et les méthodes de maîtrise de processus empirique est complexe, en effet :  

  • D’un côté on a une planification se basant sur un terrain stable et peu glissant, remplie de certitudes sur le contenu à réaliser  
  • De l’autre côté on a des méthodes et outils acceptant l’incertitude liés au contexte qui ressemble à des sables mouvants. 

Cela peut ressembler à une cause perdue, du gaspillage de temps et d’énergie… 

Pourtant où se situe le véritable gaspillage ?  

Quand il faut travailler itérativement ?

Quand les délais s’allongent les prix s’envolent et quand le contenu ne répond plus aux attentes le monde ayant changé le jour ou la solution est enfin accessible aux utilisateurs ? 

Rester bloqué

À ce stade, on frôle parfois la caricature sur les positions campées par chaque camp :   

  • Les Agilistes restant dans leur bulle et regardent avec dédain les autres avec leurs principes prescriptifs en attendant qu’ils aient fait leur révolution Copernicienne sur la gestion de projet. 
  • Les Chefs de projet et autres partisans du waterfall regardent les Agilistes et leur culte du post-it et leurs cérémoniaux étranges avec amusement parfois, avec du mépris le plus souvent pour ces hippies qui ne produisent rien comme documentation et ne respectent aucunes règles.

Ou prendre de l’altitude

Tous oublient que leur perception du monde est parcellaire et différente selon les interlocuteurs. 

Par exemple certains contextes projets sont adaptés au waterfall, ou cycle en V. 

Oui le monde est VUCA (Volatility, Uncertainty, Complexity, Ambiguity)  mais il y a des phases où l’incertitude est limitée, l’ambiguïté et la volatilité sont quasi nulles :  

– la construction d’un pont par exemple, l’industrie militaire, les évolutions réglementaires (RGPD, assurances) … 

Dans un contexte IT, utiliser Scrum pour une migration de données où on connaît la source et la cible peut paraître inadapté le contenu étant figé :  

Une phase de conception, de planification, de découpage en lot (population,… ), de test et des releases fréquentes pour un feedback des parties prenantes sur un environnement de Demo  semblent plus adapté. 

S’enrichir

Si nous sommes convaincus du bien-fondé de la culture agile, des méthodes et outils, pourquoi ne pas se mélanger aux autres pour diffuser cette culture et s’enrichir plutôt que se travestir ? 

C’est un moyen de mettre à l’épreuve nos convictions et pourquoi pas les renforcer. 

Je pense aussi que chez les chefs de projets traditionnels il y a des bonnes pratiques à prendre pour nous les agilistes. 

J’utilise pour ma part le RIDA (Relevé Information Décision Action), la gestion des risques et les supports de comité de suivi et de projet que j’adapte un peu (moins de PMO plus de démo…) pour communiquer sur l’avancement et ainsi laisser l’équipe dans sa bulle et ne pas gaspiller du temps en justification.

C’est aussi un moyen de lever les a priori sur notre culture de hippie où “personne ne respecte aucune règle.”

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 connaît ses collègues et leur contexte, plus on peut adopter notre démarche et ainsi progresser. 

Conclusion

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

Pouvons-nous nous couper des autres ? 

Pour moi la réponse est clairement non et être ouvert est une des caractéristiques de l’agilité. 

Je terminerais par cela et j’espère que vous aurez cela en tête la prochaine fois que vous croiserez un partisan du Waterfall, ou Cycle en V en citant Abraham Lincoln : ”I Don’t like that man, I must get to know him better”