Comment réussir un projet Agile dans une organisation qui n’a pas cette culture ?

Il n’est pas toujours facile pour une entreprise d’effectuer sa transition vers l’agilité. Le processus de transformation organisationnelle et culturelle est long et, très souvent, de petites équipes pilotes initient cette transformation et sont tenues de travailler en agile dans un environnement qui ne l’est pas encore. 

En prenant l’exemple de nos clients utilisant SCRUM, il est possible de lister les différentes typologies de difficultés que leurs équipes sont susceptibles de rencontrer dans cet environnement, et les pistes de solutions que nous sommes capables de proposer pour réduire ou contourner tout ou partie de ces difficultés. 

Les obstacles rencontrés par ces équipes sont principalement de trois ordres :

• des difficultés managériales (liées au reporting, au suivi et à la gouvernance)
• des difficultés au niveau des directions opérationnelles (liées à la conception du produit)
• des difficultés au sein de l’IT (liées à des silos organisationnels)

Au niveau managérial, une incompréhension de la notion de produit et des habitudes bien ancrées d’un certain format de reporting peuvent créer des malentendus en termes d’attentes des instances de gouvernance, et entrainer des problèmes de communication. 

• Le passage d’une culture projet à une culture produit est difficile. Très souvent, le pilotage continue d’être effectué par rapport au budget (et non par la valeur générée). Les directions ont besoin d’être rassurées et continuent de privilégier une stratégie prédéfinie par rapport à une stratégie évolutive, demandent à être rassurées par la présence d’un chef de projet, et évaluent encore la réussite non par rapport à l’efficience du produit mais par sa livraison.  
• Quand le framework agile est intégré, bien souvent la forme est privilégiée sur le fond car elle est rassurante. Par exemple, la direction va s’attacher au respect exact des cérémonies SCRUM sans réellement s’attacher à leur signification. Et bien souvent, des formats « traditionnels » sont toujours attendus en parallèle des formats SCRUM (lotissement et spécification en plus de la roadmap et des user stories). 

Au niveau des directions métiers, la notion de MVP est rarement comprise et il peut parfois être difficile pour les équipes SCRUM d’avoir accès aux utilisateurs cibles du produit. 

• Le concept du MVP est contraire aux pratiques usuelles des entreprises qui privilégient le concept de produit « fini ». Les notions d’itération et d’évolution permanente du backlog produit mettent souvent en difficulté les directions opérationnelles car elles intègrent les notions de doute et d’erreur.  
• Il peut être également difficile de faire accepter aux directions opérationnelles de ne pas se baser pour définir le produit sur l’idée qu’elle se font de leurs utilisateurs, mais d’aller chercher cette définition à la source directement auprès des utilisateurs.  

Au sein des services IT, des silos organisationnels peuvent exister (par outil ou par domaine) et freiner l’équipe. 

• Une équipe produit autonome et pluridisciplinaire est parfois mal comprise et mal perçue dans une direction organisée en services, souvent liés à des outils ou des domaines de compétence 
• Le cas échéant, l’existence d’un legacy important peut générer des dépendances vis-à-vis de personnes ou de services et limiter grandement l’autonomie de l’équipe. 
• Enfin, l’intégration du devOps au sein de l’équipe est souvent impossible et freine les livraisons. 

Face à ces multiples freins, il est d’usage de penser que ces dernières peuvent être contournées ou surmontées par la réassurance, la pédagogie, et l’intégration en amont de certaines contraintes dans la roadmap projet. 

Au niveau managérial nous conseillons à nos clients de communiquer le plus possible sur ce qu’est et ce que n’est pas l’agilité, et de rassurer sur le fait qu’agilité ne signifie pas flou artistique.

En amont

• Il est très important d’être transparent auprès de la direction sur ce qu’est et ce que n’est pas l’agilité (se concentrer sur les problématiques utilisateurs, apprendre rapidement, penser impact plus que livrables – et non pas une solution miracle pour produire plus vite et moins cher, et intégrer des changements de direction permanents). Encourager ou entériner des attentes intenables pénaliserait l’équipe sur le moyen et le long terme. 
• Il peut également être intéressant de proposer des variations des slides de reporting groupe adaptées à l’agilité et à la culture produit. 
• Il est primordial de bien expliciter les rôles des différents membres de l’équipe : le PO ou le Scrum Master ne sont pas des Chefs de projet et l’équipe doit être perçue comme un ensemble cohérent.

En phase de réalisation

• Il peut être judicieux de rassurer la direction sur les points d’invariances identifiés quand cela est possible (date de sortie et / ou budget). 
• Communiquer les hypothèses testées et les metrics mesurés pour chaque cycle permet de mettre en avant la valeur utilisateur attendue et de faciliter la transition vers une culture produit. Effectuer cette communication le plus possible en présentiel permet également de diminuer la communication par mail qui peut vite devenir chronophage. 
• Être transparent sur les accidents et les contraintes rencontrées, et proposer tout de suite une solution, un réajustement, un contournement expliqué et motivé permet de rassurer : le produit est évolutif mais « sous contrôle ».  

Framework et reporting 

• Il est primordial de veiller à ne pas détourner les cérémonies / outils de leur usage de base pour en faire des réunions / outils de reporting et de contrôle (exemple : le daily meeting SCRUM n’est pas un outil de contrôle des tâches effectuées par l’équipe, même chose pour les outils de management visuel…). Préserver l’équipe est un levier très important de succès. 
• Donner accès en lecture aux outils de suivi du produit et être ainsi transparent sur l’avancement permet également d’instaurer un climat de confiance. 
• Enfin, ne pas hésiter à consacrer du temps pour expliquer les outils existants (burn-up chart, burn-down chart, backlog…) en one to one aux différents managers et sponsors. Le gain de temps à long terme est intéressant et ces actions permettent d’éviter la création de reportings « parallèles » reprenant des formes auxquelles le management est plus habitué.  

Au niveau des directions métiers, la pédagogie est essentielle : une explication poussée des concepts de MVP et d’itérations est souvent nécessaire pour ne pas compromettre les premiers sprints. Si l’accès direct aux utilisateurs n’est pas envisageable, il est possible de mettre en place des stratégies de contournement. Nous sommes en mesure de vous accompagner sur la mise en place de ces stratégies grâce à notre savoir-faire en change management. 

• En amont du lancement, il est primordial de bien s’entendre avec les directions métiers sur la notion de MVP afin de ne pas se laisser piéger par la définition d’un MVP « fourre-tout » incluant toutes les fonctionnalités imaginées pour le produit, dans leur version dégradée.  
• Il est également important de bien établir que ce sont des hypothèses qui sont testées à chaque itération : elles nécessitent donc de définir objectif et mesure pour chacune – on ne teste pas toutes les hypothèses avec la livraison d’un produit fini, sans quoi l’effet tunnel est inévitable. 
• Pour aider les directions opérationnelles dans la constitution d’un MVP, il est important de définir les cibles visées par le produit, surtout quand le produit remplace un produit déjà existant (ce ne sont pas « tous les clients » ou « tous les marchés » qui sont ciblés). 
• Il est préférable de s’assurer dès le départ de la faisabilité de tests utilisateurs – pour ne pas figer les hypothèses des équipes / référents métiers comme invariants. Si ces tests ne peuvent être mis en place, intégrez le plus possible le produit aux différentes actions / communications utilisateurs existantes dans l’entreprise (panel / rencontres clients, sondages et études…) afin d’obtenir le plus de feedback. 

Au niveau de l’IT, bien intégrer la contrainte des silos existants en amont permet de faciliter le travail de l’équipe et minorer les conséquences des dépendances existantes.  

• Intégrer, même de façon partielle, les équipes legacy au projet (présentation, feedback, participation aux démos, reviews…) permet de minimiser le sentiment d’exclusion et la peur du remplacement.  
• Etablir une cartographie fonctionnelle en amont du projet permet d’identifier les éléments sur lesquels l’équipe ne sera pas autonome et les potentiels goulots d’étranglement. 
• Intégrer l’équipe à l’ensemble des points gérés côté IT (architecture, infra…) et pas seulement le scrum master ou le PO permet d’éviter l’écueil du « chef de projet » comme unique interlocuteur. 
• Enfin, intégrer dans la durée des sprint le temps imparti aux actions de l’équipe devOps permet de minimiser les risques d’échec, quitte à proposer des sprints plus longs que ceux envisagés au départ. 

Ces quelques propositions permettent de faciliter la mise en œuvre d’un produit en agilité au sein d’une entreprise qui ne l’est pas encore. Elles ne peuvent cependant palier à un changement organisationnel et surtout culturel. Ce contexte non facilitant doit donc être pris en compte à chaque étape de réalisation du produit.  

Ce sujet vous intéresse ? Contactez-nous pour avoir plus d’information.

Article rédigé par Sandrine Baron, Product Owner chez World of Digits Paris et en collaboration avec les équipes ADNEOM.