Comment marier l’Agilité à l’échelle et la gestion de projet classique en période de transition ?

Lorsque les organisations entreprennent le voyage vers l’Agilité à l’échelle en utilisant des frameworks comme SAFe, la transformation n’est bien sûr pas instantanée. Pendant cette période de transition, des projets classiques continuent souvent d’exister à côté d’Epics et viennent s’appuyer sur des Agile Release Trains. Cette coexistence apporte son lot de défis, qui peuvent néanmoins être surmontés avec une approche appropriée. Cet article vise à explorer comment gérer efficacement cette période de transition (idéalement la plus courte possible), où l’Agilité à l’échelle et la gestion de projet classique coexistent.

Gérer des paradigmes portant des périodes d’engagement différentes 

Un des défis majeurs réside dans des durées d’engagement différentes entre la gestion de projet classique et l’Agilité à l’échelle. Dans la gestion de projet classique, l’engagement porte sur la durée totale du projet, tandis que dans l’agilité à l’échelle, l’engagement se fait sur une durée d’un PI (Program Increment ou Planning Interval dans la nouvelle version de SAFe) d’environ trois mois. Dès lors comment s’engager sur un projet dont tout ou partie de son développement s’appuie sur un train qui ne s’engage que sur une période de trois mois et qui va prioriser les features de plusieurs Epics et projets différents ?

Une première solution pour atténuer les conséquences est de mettre en place des mécanismes pour aligner la roadmap du train agile avec la roadmap Lean Portfolio Management (LPM) et les plannings des projets. Si un train Large Solution est en place, mettre également en place des mécanismes pour aligner la roadmap Large Solution avec la roadmap LPM, les plannings des projets, la roadmap des trains et la roadmap des équipes non incluses dans un train.

Pour ces roadmaps, il est recommandé de privilégier l’utilisation de features pour la roadmap à trois mois, et de ‘macro features’ pour la roadmap à plus de trois mois et ceci pour trois raisons majeures :

La gestion de l’incertitude

Il est naturel que l’incertitude augmente avec la projection dans le temps. Préciser les éléments du backlog à l’extrême pourrait non seulement s’avérer ardu, mais également superflu. En effet, ces éléments sont susceptibles d’évoluer avec le temps, ce qui rend les détails initiaux obsolètes. Par conséquent, conserver une granularité macro sur le long terme s’avère être une stratégie efficace pour gérer cette incertitude.

La préservation de la flexibilité 

Une granularité macro assure également la flexibilité nécessaire pour réagir à de nouvelles informations ou à des changements de contexte. En effet, des éléments de backlog moins détaillés permettent d’apporter des modifications sans perturber l’ensemble de la roadmap, ce qui est particulièrement utile lorsque des ajustements sont nécessaires sur le long terme.

L’économie d’effort 

Il est important de noter que le détail des éléments de backlog peut être une tâche coûteuse en temps et en ressources. En préférant une granularité macro, ces efforts peuvent être réorientés vers des tâches apportant plus de valeur.

En outre, autant que faire se peut, il est préférable de construire la roadmap avec un alignement capacitaire/vélocitaire au niveau de chaque équipe afin d’avoir une roadmap réaliste et anticiper les goulots d’étranglement.

Une deuxième solution pour atténuer cet écart de paradigme est de mettre en œuvre une contingence de délai pour chaque projet. 

Cette contingence de délai apporte une gestion des risques appropriée pour le projet dans le contexte Agile. Tout projet, qu’il soit géré de manière Agile ou classique, comporte des incertitudes. La contingence de délai est une technique de gestion des risques qui permet d’absorber les retards inattendus ou les problèmes qui pourraient survenir durant l’exécution du projet mais apporte également la flexibilité nécessaire pour adresser la gestion concurrente des projets et Epics aux ressources du train.

Comment concilier les engagements projets et la priorisation par la valeur ?

Dans le cadre d’un PI Planning (ou d’un Pré-PI Planning si Large Solution), implémentant la solution de plusieurs initiatives (projets, Epics), comment arbitrer entre des features d’initiatives différentes ? Si l’on considère uniquement la priorisation des features par le WSJF (Weighted Shortest Job First), avec un périmètre des projets fixe, les engagements projets risquent de ne pas être respectés car les features avec un WSJF faible seront toujours reportées.

Dans le cadre d’un PI Planning (ou d’un Pré-PI Planning si Large Solution), j’aurais donc tendance à recommander la priorisation des feauture sur la base non seulement du WSJF mais également de la priorisation respective des initiatives telle que définie dans le cadre du LPM et des dates d’engagement des projets.

Pour illustrer ces propos, voici le mécanisme que j’ai mis en place récemment dans le cadre d’un train Large Solution implémentant la solution de nombreux projets et Epics :

• les capabilities / features sont priorisées dans le cadre de BO Sync en prenant en compte le WSJF et la priorisation des initiatives;
• avant le Pre-PI Planning, chaque ‘producteur’ (train, équipe isolé, fournisseur) identifie le niveau de confiance d’intégration des features priorisées dans le PI avant le Pre-PI Planning; 
• toujours avant le Pre-PI planning, chaque ‘demandeur’ (chef de projet, Epic Owner, train en dépendance, équipe isolé) identifie si la priorisation et le niveau de confiance pose ou non problème vis à de la roadmap ou du planning projet;
• le Pre-PI Planning tient lieux d’arbitrage avec tous les représentants métier, IT et projets pour prendre la meilleure décision en toute connaissance de cause.

Fournir la visibilité nécessaire sur l’avancement des projets

Un autre défi important est de fournir la visibilité nécessaire sur l’avancement, les risques et les problèmes aux représentants de projet. Pour ce faire, nous vous recommandons :

• D’inviter ces représentants aux cérémonies du train agile ou du train Large Solution;
• de donner accès et de former ces représentants aux outils et aux boards du train;
• d’offrir des vues permettant de visualiser l’avancement par projet.

Éviter une duplication des cérémonies de suivi

Un dernier défi est d’éviter une duplication des cérémonies de suivi entre le train et les projets. Pour cela, il est essentiel d’identifier les objectifs et les activités des cérémonies du train et des comités de projet pour soit supprimer les comités de projets, soit ne garder que les parties des comités de projet qui ne sont pas en doublon.

Conclusion

Le mariage entre l’agilité à l’échelle et la gestion de projet classique peut être géré efficacement avec les bonnes pratiques et une approche centrée sur la communication et la transparence. Il s’agit d’une période de transition qui, si elle est bien gérée, peut conduire à une organisation plus agile et plus efficace.

Il est également à noter que la plupart des problèmes et des solutions discutés ici sont également applicables, dans une moindre mesure, aux Epics.

Stéphane Déprès, Coach Agilité à l’échelle, Consultant Manager