Mon projet doit-il partir en agile ? Une question que se posent beaucoup de chefs de projet, responsables produit et managers.
C’est effectivement fondamental et structurant, cela engage le cadre de fonctionnement d’une à plusieurs dizaines de personnes voir plus et qui peut signer le succès ou l’échec de votre projet. Il existe tout un tas de matrices d’éligibilité vous fournissant un grand nombre de paramètres à prendre en compte, avec une note d’éligibilité à la fin. Et vous ne les suivrez sans doute pas car ce type de décision est aussi une question de feeling.
Est-ce que je le sens ou non, à quel point ai-je besoin d’agilité par rapport à nos démarches habituelles ? Et dans ce cas, rien ne vaut une bonne discussion pour clarifier son esprit.

Je vous propose, dans cet article, de partager l’échange que j’ai eu avec un chef de projet, dans une entreprise que j’accompagne, qui se posait cette même question.
J’avais la chance d’avoir en face de moi une personne disponible, ouverte, en questionnement sur elle même, qui nous a permis d’étudier sincèrement le contexte.

Le contexte

La discussion a eu lieu avec David*, le responsable d’un projet technico-technique, concernait la « refonte technique » d’un produit existant. Bien que David et son management aient identifié ce projet comme plutôt Cycle V compatible, ils se posent, malgré tout, la question de ce que l’agilité pourrait apporter.

Pour ce projet, le management doit livrer un premier lot (6 mois de développement) permettant de faire des tests de performance de la nouvelle solution et ainsi rassurer les clients sur la capacité du nouveau système à tenir bon.

Ils ont créé une roadmap avec des objectifs mensuels que j’ai trouvé logique (logique par rapport au livrable attendu au bout de 6 mois).

Ils souhaitaient ne pas « partir en agile » car cela aurait signifié embarquer la MOA et augmenter le cycle de prise de décision… pour un projet technico-technique effectivement tant qu’à faire… mais à mon sens l’agilité n’indique pas que « tout projet agile doit embarquer la MOA ».

Voici donc la conversation…

*Le prénom David a été changé pour maintenir l’anonymat de mon interlocuteur

Le contenu du produit

J’ai déjà commencé par questionner le contenu du produit. C’est une refonte technique et il est donc prévu de reprendre les spécifications fonctionnelles de l’ancien produit, tout simplement.

Moi : Donc ce sera exactement la même chose ? Il vous suffira de reprendre la spécification et développer à partir de ça. C’est génial, la spécification doit être aux petits oignons !
– Si, il y a quand même quelques éléments qui vont sans doute bouger car le produit a quelques années.
– Ah et vous connaissez tous les ajustements à faire ?
– Non je ne pense pas.

Le chiffrage

Ensuite, j’ai demandé s’ils étaient sereins sur le chiffrage, le nombre de choses à faire et la date.

David : Ça devrait passer mais c’est serré, faut être honnête.
– Et s’il y a des imprévus comme ces sujets pas totalement connus ?
– On a pris une marge de risque
– Ah cool, oui c’est logique. Et l’équipe est attitrée pour ce projet ?
– Non, ils travaillent déjà sur un autre chantier qui lui implique la MOA et est en agile c’est pourquoi on se posait des questions pour cette refonte.
–  Et vous savez comment ça va s’articuler ?
– On fonctionne au capacitaire, on a alloué un pourcentage pour le projet 1 et le reste pour le projet 2 donc on gérera en fonction de l’estimation de capacité pour chaque lot.
– Et donc s’il y a une grosse urgence sur l’autre projet de l’équipe ça se fera dans cette capacité allouée ?
– Je suppose oui.
– Bon ben tout est prévu alors. Si je récapitule : vous connaissez la majeure partie des fonctionnalités, vous avez chiffré, vous gérez la répartition de l’équipe, vous gérez la marge de risque par rapport aux imprévus. Donc vous êtes sereins, tout est géré.
– Oui, enfin, on est tendus quand même, ça passe tout juste.
– Même avec la marge d’erreur ?
– Oui, on a quand même beaucoup de choses à faire. D’autant que certains développeurs peuvent être mobilisés pour gérer les urgences sur le produit actuellement utilisé.
– Ah ? Donc il y a peut être un risque alors. Si vous êtes serrés niveau timing et qu’il y a une incertitude sur les fonctionnalités exactes, les potentiels coups de pression de la part de l’autre projet et celui de voir disparaître un ou deux devs plusieurs jours.
– Oui il y a un risque.

La réponse agile à la gestion du risque

Je lui ai alors déroulé les propositions d’un fonctionnement agile pour répondre à cette situation.

 Moi : Alors je vais donc juste vous donner une piste d’agilité. Face au risque que vous posez ici, les démarches agiles proposent de prendre le périmètre, le découper peut être plus finement qu’en lots d’un mois et prioriser le tout pour assurer de répondre à ce qui est fondamental en premier et gagner en sécurité ton besoin d’octobre.

Si je comprends bien l’objectif, pour cette livraison, c’est de faire des tests de performance. L’idée serait de prendre les sujets qui permettent rapidement de tester les gros sujets de performance puis de faire évoluer votre produit tout en étant en capacité de toujours tester s’il y a de l’impact sur les performances.

– Effectivement, on pourrait faire ça.
– Comme ça, avec un peu de chance, vous saurez très vite si vous êtes sur la bonne voie ou non.
Dans votre roadmap, avez-vous vu des sujets qui, selon vous, n’avaient rien à voir avec un sujet impliquant la performance ?
– Oui, l’idée est d’avancer sur la refonte globale donc il y a d’autres sujets.
– Ma proposition d’agiliste serait donc de les déprioriser le plus possible puisque l’objectif est de tester la performance. Le risque serait d’avoir trop d’objectifs et là, effectivement, ça va être difficile de prioriser.

Le dénouement

David [après mûre réflexion] : …je pense comme vous qu’il faut que nous restions sur l’objectif de performance et là je me dis qu’on embarque des choses inutiles pour octobre et qui pourraient être dépriorisées pour plus tard. Je pense qu’on est en train de se tirer une balle dans le pied avec notre manière de faire et qu’on y arrivera jamais. Par contre ça va demander de reprendre toute la spécification, de découper les éléments et c’est un sacré boulot.

– Et qui doit le faire ?
– Moi.
– Ah effectivement je comprends, il faut peut être que vous laissiez reposer la réflexion pour mesurer l’effort que ça représente et l’intérêt que vous vous pouvez y trouver.
– Je me dis que ça va être beaucoup de boulot au départ mais que je vais moins stresser tout au long du projet. En fait, vous m’avez convaincu, il faut qu’on bascule comme vous le proposez.

Adhésion du management

Bien souvent, la décision de partir en agile ne peut pas être uniquement de la responsabilité des personnes de terrain. Les décisions stratégiques, les engagements envers les clients sont prises par les couches hiérarchiques supérieures. De fait, la décision de partir en agile doit être sponsorisée par le management sous peine de créer une tension forte entre les opérationnels qui souhaitent fonctionner avec l’incertitude et un management qui a déjà verrouillé la roadmap.

J’ai donc conclus mon échange avec David par :

“ Je vous propose qu’on en reparle avec votre management et des membres de l’équipe pour que tous soient convaincus et pas que vous et moi. Si le management s’est déjà projeté et ne souhaite pas revoir son plan, ce ne sera pas la peine. Il est important qu’il soutienne la démarche pour embarquer plus de monde.”

Nous avons eu par la suite différentes discussions avec le management où j’ai suivi la même réflexion : “à quel point sommes nous sereins pour réussir l’objectif ? quelle marge avons-nous pour être sûrs de terminer à temps ?”. Les réponses ont été les mêmes et il a bien été décidé de partir sur un mode de fonctionnement plus agile en priorisant les sujets pour maximiser les chances d’atteindre non pas un objectif de périmètre mais l’objectif business derrière. L’objectif n’étant ni de produire le logiciel, ni de valider les performances mais bien de rassurer les clients sur la capacité du système à tenir bon.

Conclusion

Si je devais résumer la question qui vient après “Mon projet doit-il partir en agile ?”, ce serait “Êtes-vous totalement certain d’atteindre votre objectif à la date que vous avez choisie malgré les imprévus ?”.

Lorsque vous lancez votre projet, questionnez toujours les types d’imprévus que vous pourrez rencontrer et leur volume. Questionnez par exemple :

• Est-ce qu’il y a un risque qu’un autre projet, avec qui vous avez une dépendance, ait du retard ?
• Est-ce qu’il y des composants techniques ou des choix d’archi qui sont nouveaux et donc avec un risque de surprise
• Est-ce qu’il y a des personnes clé dans le projet qui pourraient être indisponibles à un moment et comment ça impacte le projet ?
• Quelle chance que les utilisateurs aient d’autres idées ou besoin quand on va leur présenter les premiers écrans ?
• Quel est le risque d’être interrompu dans la conduite de votre projet suite à la (re)priorisation d’un autre sujet ?
• …

Si honnêtement, sincèrement, vous sentez que votre plan a de fortes chances de subir des turbulences que vous ne pouvez pas prévoir et que, malgré la marge que vous avez prise, vous n’êtes pas totalement serein. Alors partez en agile.

• Assurez vous d’avoir un objectif business au lieu d’un objectif périmétrique (pour avoir de la marge de manœuvre)
• Identifiez des critères de priorisation et priorisez vos fonctions pour maximiser les chances d’atteindre l’objectif
• Etudiez tous les moyens qui vous permettraient de stabiliser vos équipes
• Avancez petit à petit en apprenant toujours plus de votre système, ses interactions, ses turpitudes.

Et vous noterez que cette discussion n’aurait jamais eu lieu si je m’étais contenté de donner mon avis d’expert à David.  Si un jour, vous rencontrez un ou une coach agile qui rechigne à vous dire directement quoi faire et préfère comprendre le contexte et explorer, avec vous, vos convictions et solutions, ne soyez pas surpris ou offusqué, il vous permettra sans doute de prendre de meilleures décisions pour votre projet, votre produit, vos équipes et votre business.

Crédit photo :

Cover : Photo by Kyle Glenn on Unsplash

Bulle : Photo by Volodymyr Hryshchenko on Unsplash

Point d’interrogation : Photo by Towfiqu barbhuiya on Unsplash