Pour la mise à l’échelle du framing agile, le framework propose une notion de portfolio agile essentielle pour une gestion globale des produits/services/solutions que l’entreprise veut mettre en place. Cette gestion se veut agile et axée sur la valeur à délivrer.
Concepts de base du Portfolio agile
Pilotage par la valeur
Les modèles d’enveloppes budgétaires
Dans les très grandes structures, il n’est pas rare d’être piloté par les budgets. Ces entreprises allouent des enveloppes budgétaires souvent annuellement ; elles se répartissent par “business unit” (parfois sur plusieurs niveaux) puis par “projet”.
Voici une représentation simple de ce qui se fait régulièrement au sein des très grandes structures :
Bien que les projets ne sont pas lancés par hasard et bien que dans l’idée d’apporter un plus à la structure, ils restent pilotés par le budget. Si une unité propose beaucoup plus de projets avec une grande valeur ajoutée qu’une autre unité, elle ne pourra pas lancer tous les projets la même année.
La première victime de ce type d’organisation est l’entreprise elle-même : elle ne peut pas maximiser sa livraison par la valeur. Cependant cette répartition par le budget est logique car ces entreprises fonctionnent par silos d’activités.
La fin des fonctionnements par silos
Bien que cela ne résolvera pas à 100% le problème de ces silos, l’entreprise devra rapidement imaginer un rapprochement fort des différents corps de métiers. Les framing agile ont pour but d’aller de plus en plus dans des fonctionnements par “squad” où l’ensemble des compétences seront réunies tout au long de la vie du produit (et pas que du framing agile).
Pilotage du budget par la valeur
Pour avoir une bonne mise à l’échelle des framing agile, il ne faudra plus être piloté par les budgets. L’entreprise devra mettre en place un système de priorisation de produits imaginés (et des releases) totalement axé sur la livraison de valeur.
L’entreprise pourra dédiée une enveloppe budgétaire pour la partie maintenance nécessaire quand les produits n’évoluent plus mais qu’ils nécessitent un minimum de maintenance.
Voici un schéma qui représente le parcours préconisé par la mise à l’échelle du framing agile au sein des grandes structures :
Les sponsors et parties prenantes proposent des idées de produits ou de releases dans un backlog macro dédié à la gestion des produits de l’entreprise. L’ensemble de ces produits devront présenter l’ensemble des éléments qui apporteront de la valeur.
Ces idées seront priorisées par le Ministry selon leur valeur. Il prendra la décision des lancements de framing agile selon la capacité de faire et la capacité budgétaire restante. En revanche, le Ministry devra définir un pourcentage budgétaire dédié au framing et un pourcentage dédié à la réalisation des projets pour ne pas mettre l’ensemble du budget nécessaire sur les framing agile. Il serait bien dommage qu’un projet ne puisse pas se réaliser parce qu’il n’y a plus de budget.
Quand l’équipe du framing agile arriva sur la définition budgétaire nécessaire à la phase de réalisation du produit, elle présentera les résultats au Decision Committee. Celui-ci pourra valider ou rechallenger l’équipe sur le budget ou le scope de celui-ci.
Pour rappel, nous travaillons cette définition budgétaire lors de l’atelier du release board.
Optimisation de la priorisation par la valeur
Quand le Decision Committee valide le budget nécessaire à la phase de réalisation, elle est remontée au Ministry qui pourra valider ou non le lancement de la phase de réalisation ; pour cela, le Ministry analysera si le ROI (return on investment) du produit correspond bien aux attendus de l’entreprise.
Pour faire simple, le ROI = valeur du produit / coût
Nous pouvons insérer plusieurs critères pour définir la valeur du produit comme ceux-ci :
- valeur amenée aux clients finaux
- valeur amenée aux utilisateurs
- baisse de coûts
Il reste tout à fait possible de définir un ROI plus complet ; cependant il faudra faire attention à ne pas le rendre trop complexe à calculer.
Tous les projets ou releases qui n’atteignent pas le ROI considéré comme acceptable seront mis en attente ; cela ne signifiera pas que ceux-ci ne sortiront jamais car un ROI peut évoluer avec le temps et le Ministry peut revoir le ROI minimum acceptable d’une année à l’autre.
Dans le cas d’un projet en Overall Framing Agile, la validation budgétaire devra se réaliser sur l’ensemble des produits/offres de celui-ci. Cependant, la répartition budgétaire et le ROI sera réalisé pour chacun des produits/offre. Cela permettra au Ministry d’avoir plusieurs possibilités de décisions à prendre :
- budget validé pour tous les produits à l’exception d’un (à retravailler)
- (ou) budget refusé globalement car la solution globale est jugée insuffisante
- budget validé pour l’ensemble des produits/offres.
Portfolio agile en détail
Pour commencer son portfolio agile, le framing agile recommande deux artefacts : un backlog projet et un board. Nous allons voir ces deux artefacts et la gestion préconisée pour ceux-ci.
Backlog projet
Le backlog projet est très simple à réaliser Il permettra principalement de mettre l’ensemble des projets ensemble en donnant quelques éléments essentiels pour avoir une première priorisation estimative :
Chaque entreprise est libre de rajouter des éléments complémentaires. Nous recommandons cependant que chaque élément complémentaire ajouté soit essentiel pour la priorisation et les décisions autour de celle-ci ; cela avec l’objectif de ne pas perdre du temps inutilement.
Bien que l’exercice soit compliqué à l’arrivée d’une idée, il faut tenter de déterminer le budget nécessaire ou accepté pour transformer cette idée en solution concrète. Afin d’obtenir le ROI estimé du projet, il faudra également déterminer la valeur du projet (expliquée plus tard).
Avec le ROI estimé, vous pourrez alors placer les éléments du backlog du projet ayant le ROI le plus fort au projet ayant le ROI le plus faible ; cependant, il ne faudra pas exclure les projets ayant les ROI les plus faibles car l’évolution des ROI peut varier avec le temps.
Portfolio agile sous forme de board
Dans la représentation d’un backlog, il y a une notion essentielle qui n’y apparait pas (ou du moins visuellement très complexe à interpréter) : le temps. Pourtant cette notion dans de nombreux contextes peut être essentiel pour prendre de réelles décisions. Pour cela, le framing agile préconise d’utiliser un board pour représenter le portfolio agile et les éléments essentiels.
On y classe les éléments du ROI estimé le plus haut au ROI estimé le plus bas. Les budget, le temps et les ressources devront être prises en compte pour placer les éléments sur le temps (axe horizontal).
Afin d’avoir une visibilité sur le temps, nous recommandons de créer des colonnes par trimestre. Pour ceux qui doivent gérer des dizaines de projets, il peut être plus intéressant de faire des colonnes par mois car une gestion plus fine sera alors exigée. Un maximum de visibilité sera essentiel pour prendre de meilleures décisions les éventuelles priorisations.
Le triangle de priorisation
Le plus complexe est ensuite de jongler sur trois éléments clés indissociables (le triangle de la priorisation) qui obligeront à prendre des décisions :
Ce triangle de priorisation explique qu’il faut s’accorder sur ces trois éléments pour réaliser notre priorisation. Selon les contextes, certains éléments sont fixes, ce qui implique de jouer sur la variabilité d’un (ou des) autres éléments. Quand l’entreprise travaille sur plusieurs projets, il est impossible que ces trois éléments soient fixes. Cela empêcherait toute priorisation par la valeur.
Voici quelques cas possible où il faudra résoudre une équation pour prioriser :
- budget fixe : jouer sur le nombre de ressources et sur le temps selon ce qui nous arrange
- temps et budget fixes : jouer obligatoirement sur le nombre de ressources
- budget et ressources fixes : jouer obligatoirement sur le nombre de ressource (la prestation externe peut aider)
- ressources fixes : jouer sur le temps et le budget
- ressources et temps fixes : jouer sur le budget
- temps fixe : jouer sur es ressources et le budget
Ces trois éléments sont 100% liés : le budget est impacté par rapport au temps du projet et les ressources. Et cela va de même dans les autres sens de comparaison. L’entreprise devra prendre des décisions importantes autour de ce triangle de priorisation.
Rappel ! Chaque projet lancé en framing agile doit avoir un budget sécurisé pour l’ensemble du projet. Si le budget semblait sous-estimé comme nosu pouvons le découvrir en milieu de framing agile, une décision budgétaire devra être prise.
Validation de lancement de framing agiles
Selon la capacité de l’entreprise ou la capacité qu’elle s’autorise (recrutement, prestation…), le Ministry lancera les framing agile des projets ayant le ROI estimé le plus haut. Il faut comprendre que chaque framing agile n’ira pas forcément jusqu’à la fin ; en effet, une remise à jour du ROI grâce à un premier travail d’affinage sur l’ampleur des tâche à réaliser peut amener à arrêter le framing agile en cours de route ; cela amène à l’abandon très probable du projet. En effet, les équipes peuvent s’apercevoir que l’estimation budgétaire était beaucoup trop basse (ROI à la baisse).
Comme le schéma le montre ci-dessus, le ROI du projet 1 est au final beaucoup plus bas que l’idée estimative avant le démarrage du framing agile. Afin d’optimiser les coûts, il sera privilégier d’abandonner ce projet 1 et d’allouer le budget pour autre projet semblant avoir plus de ROI (ici le projet 5).
Mais dans d’autres cas, le ROI peut aussi évoluer positivement ; ce qui renforcerait l’idée que la réalisation de ce projet est une réelle valeur ajoutée pour l’entreprise. Tous ces éléments se confirment à la fin de l’étape « roadmap » où il est essentiel de prendre une décision de go/no go. Avec la mise en place du portfolio agile, la décision se prendra par rapport à l’ensemble des projets (si ceux-ci ne sont pas tous lancés).
Portfolio agile pour les programmes
Bien que la gestion est similaire, voici à quoi ressemble un portfolio comprenant un programme ; celui-ci contient quelques subtilités très simples à comprendre.
Pour un programme, nous vous conseillons de calculer un ROI du programme dans son ensemble. Attention à ne pas prendre le total des ROI des projets contenus dans ce programme ; cela n’aura que peu de sens. Le programme sera priorisé unitairement dans le portfolio. Cependant, si un projet dans le programme peut servir d’autres projets, en cas d’annulation du programme, le projet pourra être inséré unitairement à la suite dans le portfolio agile. Mais nous somme ici sur des cas très particuliers.
Pour conclure, il est fortement recommandé que le budget total du programme lui soit alloué. Ne pas alloué le budget nécessaire au programme dans son ensemble amènera à un risque non négligeable d’investir dans un programme couteux qui n’a pas la garanti d’aboutir.
Soyez le premier à commenter