Réaliser une transformation agile tout en douceur

Les points clefs afin de faciliter l’application de l’agilité dans votre projet

Ça y est, votre organisation passe en mode agile. Votre boss en a entendu parler, il parait que c’est révolutionnaire et est convaincu qu’il faut faire la transition. Pourquoi ? Pour être à jour sur ces nouvelles méthodes de gestion de projet : C’est bien plus efficace, cela contentera les voix qui montent et qui demandent cette transition et puis … et puis c’est à la mode.

D’ici à la fin de l’année il faut que 80% des projets de l’entreprise soient gérés grâce à une méthode agile. Comment l’évalue-t-on ? « Hum … il faut faire des dailies, des démos et des rétros !  Et puis on fera des sprints pour mettre en place nos MVP ! »

Bon j’exagère un peu, mais parfois, quand on interprète les propos de nos managers on peut avoir envie de le résumer ainsi. En général, ce genre de réflexions peut arriver quand on analyse rétrospectivement les facteurs d’échec de la transition, ou quand on est énervé après une réunion déplaisante.

Car oui, le fait de passer à l’agilité pour provoquer un effet d’annonce pourra satisfaire nos managers mais pas forcément les opérationnels. Les incohérences générées vont se multiplier et les équipes ne sauront plus sur quel pied danser.

Notre article liste divers facteurs clefs de succès pour une transition agile tout en douceur.

1 - Des parties prenantes incluses dans la transition

La condition fondamentale du passage à l’agile dans une entreprise, sans qu’il faille sortir les rames pour recadrer le projet sans arrêt est que le management soit sensibilisé et fasse des demandes en cohérence avec la situation.
En général, face à une initialisation de projet, le management doit se positionner sur les modalités de delivery. Grossièrement il existe 2 possibilités :

• Veut-on un produit fini coute que coute à l’issu du projet ?
• Veut-on un « premier exemplaire » (MVP) du produit, dont le périmètre est encore flou mais à une date fixée ? Le projet se « renouvelant » sans cesse par la suite.

C’est ce choix idéologique qui va garantir la stabilité du projet ou grandement le fragiliser. Dans le cas d’une transition agile mal réalisée, c’est le premier choix qui est effectué. C’est une vision des choses qui implique la définition initiale du produit et qui va générer de nombreuses incohérences dans la partie opérationnelle du projet, puisque cela relève d’une vision traditionnelle avec une structure agile (watergile).

2 - Une facturation appropriée

Conséquence donc direct du positionnement idéologique des investisseurs, le choix du mode de facturation peut être déterminant dans la transition agile en cours. En effet, la gestion de projet en général, et a fortiori des projets informatiques, reposent sur trois piliers ou leviers sur lesquels on peut jouer pour s’ajuster : le budget, le délai et le périmètre fonctionnel.

On parle traditionnellement de« l’Iron triangle » dont la représentation est la suivante :

En gros, les méthodes traditionnelles ont tendance à fixer le périmètre fonctionnel quoi qu’il arrive et à « jouer » sur le budget et les délais. Cela se traduit le plus souvent par la rédaction d’un cahier des charges avec des spécifications détaillées au début qu’il faut développer, tester et mettre en production quitte à rallonger les délais et donc à augmenter les coûts, ou à augmenter la taille des équipes.

Les méthodes agiles, si l’on simplifie, inversent ce modèle en fixant les coûts et les délais mais en« jouant » sur le périmètre fonctionnel à livrer. Et de la même manière, cela se traduit par la définition d’un MVP (et non la spécification, c’est important dans le sens où l’on en dessine les grandes lignes, et c’est tout ! – d’où le fait que l’on dit que le périmètre fonctionnel n’est pas fixé) et la fixation d’une date de première release. Donc dans les faits on dit« A telle date, vous aurez un outil opérationnel, utilisable » et basta.

Quel rapport avec la facturation me direz-vous ?
Il existe, a priori deux grandes typologies de facturation :

• Forfait (obligation de résultat) : vous devez proposer un livrable à une date donnée et activerez la facturation à la réception
• Régie (obligation de moyen) : les acteurs du projet sont facturés au TJM de leur jours effectivement travaillés.

Si vous avez suivi, pour coller avec les modalités de gestion de projet, il est important de facturer au forfait en méthode traditionnelle et en régie en méthode agile.

Ainsi, si on vous demande (en tant que PO par exemple) de chiffrer finement toutes les fonctionnalités du MVP (et quand il ne s’agit que du MVP …) avant de commencer afin de fixer le scope à déployer, vous savez que le mindset est mauvais.

Très souvent, il est demandé la mise en place d’un périmètre fonctionnel finement défini malgré l’adoption de Scrum, SAFe, Kanban ou autre, et c’est ce dont il faut se méfier.

N.B. : Il est à noter néanmoins qu’une facturation en régie fait reposer tous les risques financiers au client. Ainsi, il est intéressant malgré tout de voir quels peuvent être les compromis à proposer pour éviter le mode forfait traditionnel tout en rassurant le client sur son investissement.

3 - Une relation constructive entre l’équipe projet et les sponsors

De quoi parle-t-on ici ?
Imaginez : vous êtes dans une équipe où le Product Owner est seul maître de la conception technico-fonctionnelle. L’équipe est totalement auto-organisée. La dimension UX est prise en compte. Le PO n’est pas mis sous pression par sa propre hiérarchie pour appliquer une seule solution. Le projet a été commandité par la DSI, qui est sponsor, pour ses utilisateurs finaux.
C’est un exemple de ce vers quoi il faudrait tendre.

Mais il faut avouer, cela ne se passe jamais comme ça. Il y aura forcément un moment où cela va coincer. Par contre, il n’est pas rare de voir totalement l’inverse.

Le client, qui détient les cordons de la bourse va, très souvent, juger que pour avoir un retour sur investissement profitable, il devra s’impliquer dans la conception du produit (« Je paye, donc je décide de la solution »). C’est une des grosses erreurs souvent rencontrées qui est la confusion entre l’expression du besoin métier et sa concrétisation en termes de solution. Il existe alors deux variantes :

• Soit le PO est directement chez le client, voire est le client (hors de l’équipe donc) et viendra simplement transmettre sa solution à l’équipe de développement. Cette dernière réalisera, testera et demandera au client de valider avant mise en production.
  Dans cette configuration, les feedbacks arriveront toutes les 2 ou 3 semaines (en fonction de la durée des sprints) et, surtout, la dev team sera très peu consultée.

• Soit le PO est bien dans l’équipe MAIS qu’il n’a pas de pouvoir décisionnel. Le client propose donc une conception technico-fonctionnelle et le PO « challenge » cette solution mais sans réel pouvoir d’action (le PO a donc un rôle réel plutôt proche de celui du Business Analyst). Le problème est, dans cette configuration, que le client n’a pas forcément les mêmes enjeux que le PO : un outil complet à proposer, un budget à  limiter, voire des contraintes structurelles (politiques, d’image …).

En tout cas, ces exemples bafouent les principes selon lesquels l’équipe de réalisation doit être auto-organisée et responsable du produit livré.

La qualité intrinsèque au produit risque donc de baisser assez fortement. Mais surtout cela génère de la dette technique pour plusieurs raisons : les développeurs peuvent se sentir peu concernés par la qualité du produit ou les demandes peuvent être si peu cohérentes qu’elles ne peuvent être anticipées par une conception technique solide et structurée.

Enfin, on imagine assez bien que l’aspect UX pourrait également en pâtir dans le sens où le détenteur de la solution fonctionnelle devra livrer un outil où il n’aura que très rarement été challengé, ou contredit (peu d’intelligence collective).

4 - Définir une vision produit compréhensible

Problématique extrêmement importante en agilité, c’est pourtant un principe qui fait très souvent défaut. Etablir une vision produit, c’est la faculté du PO ou du PM à proposer une solution abstraite à une problématique métier. Phrase compliquée pour exprimer le fait que cette solution n’est pas inscrite dans le marbre mais qu’elle suit une sorte de« philosophie » à laquelle se rattacher sans arrêt. Elle est constituée de la réponse au besoin du métier ou des clients et peut être formulée sous diverses formes (phrases, cartes postales, tableau …)

Pourquoi est-ce fondamental ?

• Cela permet de fixer des objectifs clairs aux sprints.
  Grâce à une vision produit et une roadmap agile, les PO ou PM pourront structurer leur delivery en planifiant des sprints cohérents et porteurs de valeur

• Cela permet de faire la part des choses entre les besoins métiers et la solution fonctionnelle (hélas bien souvent confondus)
  Dotés d’une ligne directrice stable, les PO pourront interpréter les besoins métiers à l’aune de la vision/roadmap et donc d’effectuer les meilleurs choix conceptuels possibles. Leur valeur ajoutée sera donc maximisée car leur connaissance technique, fonctionnelle et métier sera utilisée à bon escient.

• Cela permet également de cadencer les releases aux utilisateurs et en particulier de définir correctement son MVP.
  Le MVP représente une première tentative de solution répondant à la philosophie de la vision. Il permet de valider les orientations stratégiques et peut être un jalon de GO/NO-GO pour la suite du projet.

• Enfin, cela permet d’optimiser sa capacité d’adaptation, et ce dans 2 situations particulières :

1. En évitant d’effectuer un cadrage initial complet, il est possible de rebondir facilement à un imprévu métier, organisationnel voire technique.
2. Par ailleurs, cela permet de proposer une conception technico-fonctionnelle robuste car aussi bien le PO que les développeurs gardent en tête leur objectif final

5 - Evaluer et anticiper les risques inhérents à une transition agile

Malgré une transition agile bien effectuée et des collaborateurs bien formés, il est indispensable de vérifier la bonne adéquation entre les pratiques réelles et la théorie. Non pas qu’il faille obligatoirement s’y conformer entièrement, mais il y a une base qu’il faut respecter, et qui prend la forme des 12 principes agiles et des 4 valeurs (voir ici par exemple). Or, on se rend compte rapidement qu’une formation de 2 jours ne peut permettre d’effacer des années d’expérience.

En fait, il faut partir du principe qu’une équipe, même très bien organisée, ne sera pas d’emblée suffisamment mature afin de proposer des pistes d’amélioration efficaces (voir loi de Tuckman).
Il faut pourtant lui laisser la main pour identifier et mener elle-même ces pistes d’amélioration, aidée par le Scrum Master.

Ainsi, les équipes peuvent se confronter à diverses situations dans le cadre de leur amélioration continue :

• Trop peu matures, elles ne comprennent pas totalement les enjeux liés à la transition. Les propositions opérationnelles ne sont pas forcément bonnes mais peuvent évoluer dans le bon sens, aidées pour le coup par le Scrum-Master. (certains problèmes ne pourront pas être réglés, mais ne sont pas considérés)
• Suffisamment matures, elles commencent à entrapercevoir l’impact des décisions managériales sur leur quotidien mais ne voient pas comment remonter le point. Les Scrum-Masters ne s’adressant pas forcément au bon niveau hiérarchique et ne peuvent pas faire évoluer les pratiques. (blocage donc)
• Totalement matures, elles comprennent que ce qui leur est demandé d’un point de vue opérationnel n’est pas en phase avec le management. (Conflit induit)

Dans ces 3 cas, il me semble qu’il manque un coach pouvant aussi bien se reposer sur des Scrum-Masters au niveau des équipes que de s’adresser au management et de challenger leurs choix si besoin. Cela permettra d’éviter certains de ces écueils ci-dessous (liste non-exhaustive) :

• Excès de contrôle et perte de confiance de la part du management envers les équipes, notant une perte de productivité ou une potentielle démotivation. C’est à ce moment que fleurissent les divers comités (COPIL, COSUI, CORUN, etc.) ainsi que les indicateurs qu’il faut y présenter.
• Perte de confiance de la part des équipes envers leur management, notant une incohérence dans les demandes (d’ailleurs exacerbée par une hausse du contrôle)
• Perte de repère des équipes nuisant à leur efficacité
• Etc

En synthèse, il me semble très important de s’entourer d’experts méthode, au moins pour les premiers mois, et de leur laisser le bénéfice du doute sur les pratiques en train d’être mise en place. Cela permettra à tous les collaborateurs d’avoir le temps d’appréhender les nouvelles règles de travail et de gagner en autonomie et en raisonnement.

Conclusion

Il existe encore beaucoup de situations pouvant mettre à mal une transition agile. Cela peut aller de la suppression des rétrospectives car les équipes et le management jugent que plus rien de « bon » n’en ressort, au cadrage basique spécifiant un périmètre fonctionnel à voir mis en production à une date définie. Très souvent le fait d’avoir des PO, des Scrum-Masters, des cérémonies agiles et des sprints semble suffisant pour se définir agile, or cela n’est non seulement souvent pas le cas, mais il est tout à fait possible d’effectuer une transition avec succès sans tous ce qui est cité ci-dessus. A fortiori, rien ne sert d’utiliser une méthode définie si l’on n’en comprend pas les tenants et les aboutissants.

Alors, à l’occasion d’une discussion sur ce qu’est l’agilité ou d’un entretien pour une nouvelle mission, il peut être intéressant de se souvenir de ces points : Comment pense le management ? Comment est facturé le projet ? Comment se positionne l’équipe projet ? Est-ce que le PO décide de la solution ? Suit-il une vision produit ?