Introduction
Les méthodes agiles offrent aux équipes de développement une grande capacité d’adaptation aux changements et imprévus qui ne manquent pas d’arriver sur un projet. Il peut être question d’opportunités à saisir pour apporter plus de valeur ou d’obstacles ralentissant le projet à surmonter.
L’objectif de cet article est de présenter différents problèmes qui peuvent ralentir la marche d’un projet vers l’objectif fixé et les solutions mises en place pour accélérer cette progression. L’article ne prétend pas être exhaustif. Il met néanmoins le doigt sur des problématiques courantes dans le monde du développement agile.
Cette réflexion est largement inspirée d’une situation réelle. Un projet mené dans un contexte assez tendu. Sans rentrer dans les détails, le projet était en difficulté en matière de budget et de délai.
Contexte
Il s’agit de la refonte d’une application existante qui constitue le cœur même de la stratégie du client. Le besoin de départ a été esquissé en epics qui reprennent globalement les fonctionnalités existantes auxquelles viennent s’ajouter de nouveaux besoins. L’objectif du projet étant de livrer un MVP (Minimum Viable Product) dans un laps de temps relativement court et avec un budget très limité.
En apparence, le projet est mené en mode agile : une équipe Scrum, un backlog du MVP, un développement itératif, une démo à chaque fin de sprint et j’en passe. Sauf que les contraintes imposées au projet à elles seules, à savoir un périmètre, un budget et un délai fixés d’avance, vont à l’encontre de l’agilité. Ce schéma s'apparente en fait à un forfait classique. Sans parler bien sûr des grosses lacunes, pour ne pas dire absences, au niveau du mindset agile chez le client.
Ralentisseurs et accélérateurs
1- Maturité agile
#Ralentisseur
Le client n’est clairement pas agile et cela se voit à travers ses méthodes, ses réactions et ses pratiques au quotidien. Connaître et utiliser quelques termes du référentiel agile ne rend pas une organisation agile ! Du coup, concernant le déroulement du projet, le client n’arrive pas à se détacher ou du moins relativiser des notions comme l’estimation en jours/hommes d’un périmètre ou l’engagement sur un délai et un budget de réalisation fixés d’avance alors que le besoin n’est pas encore complètement défini et détaillé. On se retrouve au final à faire une sorte de forfait déguisé en agile. En fait pas complètement car le périmètre est amené à évoluer forcément lors des échanges sur les User Stories (US) mais sans pouvoir remettre en cause les engagements de départ sur le délai et les charges. Agilité oblige selon ledit client !
#Accélérateur
L’agilité ne se décrète pas. C’est un état d’esprit et une culture qui nécessitent un long processus d’acculturation agile pour pouvoir s’installer au sein d’une organisation et se manifester dans les pratiques quotidiennes. C’est pourquoi, prétendre amener une organisation vers l’agilité le temps de réalisation d’un projet est pure utopie. Par contre, ce qui reste à portée de main, c’est l’injection de petites doses d’agilité dans le projet en question. Mais malgré cela, le projet reste soumis aux fortes contraintes provenant de l’environnement du projet : délai, budget, non alignement des objectifs entre le métier et les sponsors, absence de réactivité et feedback, etc.
Dans ces cas-là, les marges de manœuvres sont très étroites mais restent envisageables. Sensibiliser le client à l’agilité et multiplier les échanges face à face, montrer les gains et les succès durant le projet, cibler les parties prenantes et introduire la vision produit sont de bons exemples d’accélérateurs pour diffuser la culture agile et encourager son adoption. Mais, l’accompagnement de l’organisation par un coach agile reste la démarche la mieux conseillée pour une transition douce et progressive.
2- Rôle du Product Owner (PO)
#Ralentisseur
Le PO est le détenteur de la vision produit au sein de l’équipe. Par conséquent, c’est lui qui fixe le cap des développements. Son rôle est de gérer le backlog produit donc de définir les US et les prioriser pour embarquer le maximum de valeur métier. Il doit s’impliquer entièrement dans le projet, transmettre la vision produit et s'assurer qu'elle est bien comprise par les développeurs, accepter (ou pas) les incréments livrés selon les critères d’acceptation fixés et surtout collecter un feedback rapide pour ajuster le produit.
Si ce rôle n’est pas correctement tenu, il y a fort à parier que le projet dérive. Le cas classique, c’est quand le client désigne comme PO une personne qui n’a rien à voir avec le produit à développer. Le fait d’être un responsable hiérarchique ne changera pas la donne. Quand le PO nommé n’a pas la légitimité au sein de l’organisation ou les compétences et outils requis pour assurer son rôle ou encore manque de temps pour le faire, le produit sera fortement impacté tant sur la définition des besoins métiers et la valeur apportée que sur les délais et charges de développement.
#Accélérateur
Dans ce cas de figure, la réponse la plus objective, c’est d’affecter le rôle de PO à une personne qui a les compétences requises. Si ce besoin est identifié assez tôt en amont, un PO expérimenté pourra rejoindre l'équipe afin de prendre en charge le rôle et sécuriser le développement du produit. Une autre alternative serait de former et coacher le PO pressenti pour lui permettre de monter en compétence tout en sécurisant le projet. Sinon, une solution intermédiaire consistera à faire intervenir ponctuellement un PO expérimenté chez le client pour mener des ateliers de définition du produit et de découpage en US ainsi que la priorisation des développements. Enfin et dans tous les cas, le Scrum Master (SM) doit accompagner le PO en place et l’assister dans sa gestion du backlog produit.
3- Définition du besoin
#Ralentisseur
Face à des contraintes de délai et de budget très fortes, une vision du produit floue ou du moins incomplète, un rôle de PO mal assuré, il est très difficile de travailler dans des conditions sereines et de tenir les engagements sur la livraison. Le problème réside dans le fait que le besoin n’est jamais clair au début. Le PO commence par identifier les grandes lignes du besoin puis les affine au fur et à mesure des ateliers, des échanges et de l'évaluation du produit au cours de sa construction. Le travail de préparation des US par le PO doit être fait en continu et surtout en cohérence avec la cadence des sprints. Il faut alimenter l’équipe de développement avec des US bien définies pour bien avancer et être réactif face à leurs potentielles interrogations. La collaboration entre le PO et l’équipe de développement doit être active et permanente. Un manque de fluidité dans ces échanges aura un impact négatif sur l’avancement du projet.
#Accélérateur
Pour être efficace, il faut dès le début du projet s’investir pour définir les besoins, les prioriser pour apporter plus de valeur et délimiter ainsi le périmètre du MVP à développer. Pour accélérer le processus, il faut mobiliser le client pour faire avec lui des ateliers de définition des US du MVP et les détailler. Un PO expérimenté peut faire la différence lors de cette étape cruciale. Dans ces ateliers, il est indispensable de faire participer des opérationnels métier, des développeurs et un designer UX/UI. Cela permettra d’aligner tous les acteurs sur une vision commune et centrée sur la valeur apportée du MVP à développer, de réduire la perte d’informations en passant par des intermédiaires, de confronter la vision métier à la vision technique et d’avoir un feedback réaliste sur l’utilisation de l’application existante pour mieux comprendre les demandes. Si des besoins nécessitent plus de réflexion et de recul, d’autres ateliers peuvent être envisagés par la suite en cours de développement pour plus de clarification. Dans tous les cas, il faut favoriser le face à face pendant les échanges.
4- Notion de MVP
#Ralentisseur
Un MVP, comme son nom l’indique, signifie un produit couvrant de façon cohérente les besoins minimaux des utilisateurs cibles. L’objectif étant de mettre rapidement à disposition de ces utilisateurs, avec un effort réduit, un produit répondant à leurs principales attentes. Les feedbacks recueillis suite à l'utilisation du MVP permettront de valider (ou non) les hypothèses posées, d'affiner les besoins déjà identifiés ou encore de faire émerger de nouveaux besoins.
Mais dans un contexte de refonte d’une application existante, la question de l’opportunité d’un MVP se pose inéluctablement. Parler d’un MVP pour une application déjà utilisée a-t-il un sens ? En effet, les utilisateurs connaissant et utilisant le produit précédent n'accepteront pas un nouveau produit dégradant le service déjà rendu. Ils ne céderont pas sur le confort déjà acquis. Ce qui conforte le client dans le sens qu’il donne au MVP i.e. au minimum une nouvelle application iso-fonctionnelle à l’application existante. Cette situation pose une contrainte énorme sur le périmètre à réaliser ainsi que sur les délais et charges et réduit considérablement la marge de manœuvre concernant l'implémentation des US.
#Accélérateur
Quand il s’agit de la refonte d’une application existante, il faut bien faire valider l'adéquation entre le périmètre couvert par le MVP proposé et les besoins incontournables des utilisateurs. Une piste à explorer porte sur la possibilité de se délester temporairement de certaines fonctionnalités existantes ou du moins les alléger le temps de réaliser une première version du produit. C’est aussi une bonne opportunité pour revisiter l’application et décider des fonctionnalités à garder ou à supprimer en fonction des besoins à date. Car l’effort et le délai nécessaires pour développer un MVP n’ont rien à voir avec la refonte de toute l’application. Dans ce cas précis, tout l’enjeu est de sortir de ce piège où le client s’attend à avoir dans son MVP toutes les fonctionnalités déjà existantes et dans les délais fixés. Le premier levier à utiliser est la sensibilisation à la définition du concept de MVP. Le deuxième c’est la définition du contenu de ce MVP en tenant compte des contraintes de budget et de délai et en insistant sur les US ayant plus de valeur pour l’utilisateur. Il faut être vigilant quant à la tentation de glisser des fonctionnalités, certes bénéfiques, mais sans réelle valeur ajoutée pour le MVP. Et vu les contraintes de délai, Il ne faut pas hésiter à envisager dans la réalisation des approches simples voire simplistes à partir du moment où elles permettent de répondre aux besoins et ce, conformément au principe KISS (Keep It Simple, Stupid). Par exemple, au niveau de l’interface utilisateur, une stratégie possible pourrait être de recourir à des traitements manuels ou semi manuels pour certaines opérations en back office. Cela réduira énormément l’effort de développement.
5- Travail à distance
#Ralentisseur
L’écriture d’une US n’est pas une fin en soi. C’est plutôt le début d’un échange entre l’équipe de développement et le PO pour comprendre le besoin, identifier les règles de gestion à respecter et documenter les critères d'acceptation qui serviront à valider les développements réalisés. Cela nécessite une communication fluide, qui sera facilitée par la proximité des personnes et un haut niveau d'interactivité. Les acteurs ont besoin d’utiliser des moyens et outils divers et variés pour exprimer leurs idées et les mettre à l’épreuve d’autres idées (montrer une photo ou un schéma, faire un dessin ou un diagramme, reprioriser facilement des sujets en déplaçant quelques post-it, etc.). Toute dynamique de travail se trouve pénalisée lorsque le PO et l’équipe de développement ne sont pas co-localisés. Les échanges à distance perdent en interactivité et donc en qualité d’informations. La communication par téléphone ne se prête pas bien à un travail de co-construction actif et apaisé d’un produit dans un contexte déjà tendu.
#Accélérateur
La communication ne se limite pas à la parole mais s’étend au langage corporel et aux émotions dégagées lors d’un échange. Au téléphone, l’interlocuteur ne perçoit que la parole et la tonalité de la voix. Ce qui peut biaiser la communication et induire en erreur les acteurs au point où certains propos peuvent être mal interprétés et provoquer des crispations. Pour assurer un minimum de proximité et de convivialité, il faut privilégier des outils de communication visuelle comme la visioconférence. Sinon, le face à face reste la meilleure solution pour se parler et travailler ensemble. Par expérience, les échanges entre les personnes sont plus fluides et le risque d’incompréhensions mieux maîtrisé. De plus, les acteurs qui partagent le même espace physique peuvent utiliser plus de moyens et d’outils pour exprimer leurs pensées.
6- Pilotage par les risques
#Ralentisseur
Le client avec de fortes contraintes de délai et de budget a besoin d’être rassuré sur la capacité de l'équipe à livrer le périmètre attendu à la date convenue, ce qui passe traditionnellement par la fourniture d'une estimation de l'effort à réaliser. Mais avec l’influence de son mindset “cycle en V”, ce chiffrage est accueilli comme un engagement ferme sur un périmètre, un budget et un délai fixes. Or l’équipe de développement ne peut pas s’engager sur un backlog produit dont les items ne sont pas bien définis et qui est amené à bouger au fil des sprints. Si on ajoute à cela tous les ralentisseurs déjà cités, la probabilité de dérive du projet atteint son maximum. Cette situation est potentiellement source d’altération de la confiance client, de stress de l’équipe de développement et d’installation d’un climat de tension et de crispation qui peut facilement dégénérer en conflit.
#Accélérateur
Dans pareil cas, il faut anticiper les difficultés en s’appuyant sur le pilotage par les risques. Il s’agit en somme d’identifier les risques pouvant affecter le bon déroulement du projet, d’évaluer leur impact et de chercher des solutions pour les maîtriser. Plus tôt les risques sont identifiés, mieux c’est pour la prévention des dérives. Ces facteurs de risque doivent être ensuite suivis durant les sprints pour les circonscrire définitivement ou du moins atténuer leurs effets. Il va sans dire que le client doit être impliqué dans la prévention des risques qui le touchent directement.
La roadmap produit peut, à cet effet, révéler certains jalons à haut risque qu’il faudrait suivre de plus près et revoir régulièrement pour les affiner. Et si la durée du projet est courte, alors il est conseillé de partir sur des sprints courts de l’ordre d’une semaine, au maximum deux, pour avoir rapidement des retours utilisateurs permettant de valider ou d’ajuster les développements réalisés.
Conclusion
Chaque projet est unique mais les différents ralentisseurs évoqués dans cet article se retrouvent sur beaucoup de projets. Les accélérateurs proposés ici sont des pistes d’amélioration issues d’un contexte projet bien particulier et ne sont donc pas forcément généralisables. L’essentiel, c’est d’identifier assez tôt ces ralentisseurs pour pouvoir réagir à temps et ajuster le plan d’attaque selon le champ des possibilités offertes, toujours dans une démarche d’amélioration continue.
Mais mieux que cela, le client aura tout à gagner en changeant de posture, i.e. en passant d’une vision projet où on doit livrer un périmètre donné dans un délai convenu à une vision produit où le souci principal est la satisfaction de l’utilisateur final à travers des livraisons fréquentes de valeur, tenant ainsi compte du fait que le produit est appelé à vivre et à évoluer en fonction des besoins de l’utilisateur.
