[chapo]Les géographies d’un grand groupe poussent à différents regroupements et compositions pour organiser des zones cohérentes où des cultures proches peuvent facilement s’exprime. Logiquement, on trouve dans ces organisations une zone germanique où l’on place ensemble Allemagne, Autriche et parfois la Suisse (ou au moins sa partie alémanique). C’est le cas chez L’Oréal et nous nous demandions dans quelle(s) ville(s) auraient lieu la formation. Entre Vienne, Munich, Berlin ou encore Zûrich, la zone ne manque pas d’attrait. Finalement, c’est dans la très économique (et un peu excentrée) capitale de la Ruhr, Düsseldorf, que la session fut programmée.[/chapo]
Pourquoi on le fait ? les différences culturelles
Regrouper des cultures voisines et sœurs permet aussi de dégager des tendances communes et parfois un peu différentes. L’agilité telle que nous la présentons et déployons chez nos clients est certes une question de conduite de projet, mais elle est aussi une approche différente du travail et de la collaboration. Ses impacts culturels sont généralement accueillis avec enthousiasme et bienveillance mais il arrive parfois que l’agilité suscite interrogation et scepticisme. C’est un peu ce que nous avons constaté au cours de cette session.
PM4IT se construit en deux phases : une approche méthodologique avec un processus clairement formalisé de gestion de projet, et des pratiques agiles qui viennent enrichir ce processus et diversifier les pratiques des équipes.
Le processus de la formation
Le processus est un cadre auquel on ne peut déroger, et il offre tel qu’en lui-même un cadre traditionnel et rassurant : les phases de qualification et de faisabilité précèdent les phases de design, build, test, déploiement, etc. C’est à ces conditions, en partant d’un premier niveau facile à appréhender, qu’un langage commun au sein d’une organisation mondiale peut s’élaborer, se construire et s’enrichir.
Face à cette approche très progressive, méthodique et centrée sur le processus, les équipes IT locales nous ont adressé le message suivant : « Le processus étant obligatoire, nous allons le suivre. L’agilité n’étant pas obligatoire, nous verrons dans un second temps, lorsque nous nous serons approprié le processus ».
Sur le fond, la démarche ne se discute pas. Certes, nous aurions préféré un peu plus d’allant et de volontarisme, mais c’est une décision qui se respecte. Nous l’avons prise comme le reflet d’une culture très ancrée dans le processus, par le poids de SAP dans l’entreprise. Mais aussi comme l’expression d’une certaine incompréhension vis-à-vis de l’un des messages clés délivrés : oui, le périmètre peut changer en cours de projet.
Une flexibilité mise à l’épreuve
Les participants de la session ont accueilli avec une certaine fraîcheur ce qui leur semblait relever de l’improvisation, voire de l’amateurisme. Un périmètre, lorsqu’on s’est engagé vis-à-vis du business, ça ne change pas comme ça. Surtout pas en cours de route. Difficile dans ces conditions d’aborder avec une audience perplexe les bienfaits de la priorisation par la valeur et de sa réévaluation en cours de projet.
Cette vision flexible est venue bousculer les habitudes de travail. L’existence d’un processus séquentiel et linéaire semblait annihiler toute possibilité de fonctionner en mode itératif. Nous avions beau préciser que les sprints ne sont ni plus ni moins que la multiplication où on retrouve ce processus à l’échelle microscopique. Et que cette multiplication offre une formidable opportunité d’optimiser la valeur d’un produit, cet apport semblait extrêmement lointain à nos interlocuteurs. Ceux-ci ont fini par conclure : « Cela nous intéressera… dans quelques années ».
De façon un peu caricaturale, on nous donnait parfois l’impression que, dès lors que le métier valide un périmètre, l’équipe IT se met en action et délivre ce qu’on attend d’elle. Cela sans état d’âme vis-à-vis de sujets tels que le time-to-market ou le benchmarking, qui poussent à la recomposition d’un périmètre. Eh, quoi, un processus est un processus ! Dans ces conditions, on imagine tout aussi mal le métier frapper à la porte de l’IT et demander des aménagements.
La culture du produit
La culture agile prône la prédominance des individus et des interactions entre ces individus sur le processus et les méthodes. C’est la première valeur du manifeste. Elle ne mentionne pas la nullité des processus, mais elle remet la collaboration et l’adaptation au centre du jeu. Est-ce le poids des grands projets passés, notamment ERP, qui empêchaient nos interlocuteurs de se projeter ?
On peut aussi deviner que la culture du produit, qui s’impose progressivement en Europe avec le design-thinking, n’ait pas encore trouvé sa place dans certaines DSI où la notion de projet prend encore toute la place. Or la plus-value de l’agilité, via la collaboration, est de mettre en avant l’importance du produit où la technologie est omniprésente et d’en travailler sans cesse la qualité.
Sans jeu de mot, PM4IT est la preuve que la culture du produit s’implante progressivement : processus plus léger, moins pensé de bout en bout, poches d’agilité… l’importance est de délivrer une valeur élevée qui se traduira par l’affordance du produit : un produit que ses utilisateurs auront spontanément envie d’utiliser et de recommander. Et cette valeur se travaille et s’optimise tout au long de la durée d’un projet.
Ces interactions constantes entre projet et produit se vérifient jusque dans l’incarnation même des rôles : le Project Manager dispose d’un Product Owner pour accompagner l’équipe de fabrication.
Retrouvez notre précédent épisode : Agilité autour du monde : Pologne, Lituanie, Lettonie, Ukraine et Israël
Hélène ABSALON – Publié le 06 Juin 2017
