Roadmap agile

Il est indispensable de faire la différence entre un release plan et une roadmap agile. En effet, la roadmap est une vision beaucoup plus macro et ne s’attend pas à avoir les détails de chaque petite fonctionnalité à appliquer.

Cet atelier est dédié aux entreprises qui imposent encore d’avoir une vision plus long terme du produit. Cependant cette roadmap agile ne devra pas se transformer comme un contrat à respecter ; en effet, il n’est pas rare de voir la roadmap comme un plan à suivre strictement.

Pour les organisations qui n’ont pas de raisons réelles de mettre en oeuvre une roadmap agile, nous recommandons de ne réaliser que les éléments suivants de cette partie :

• estimer la capacité de faire de l’équipe -> sera utile pour définir les éléments à affiner de la première itération

Roadmap agile – définition

Les objectifs de la roadmap agile  pour l’entreprise  sera de :

• partager une vision commune des enjeux de l’entreprise
• de donner une direction commune à suivre
• de donner la visibilité nécessaires à ceux en ayant réellement besoin
• d’aider à la priorisation par la valeur aux équipes de réalisation

L’organisation devra toujours avoir  en tête que cette feuille de route (nom français) respectera le triangle de fer agile qui rappelle que le scope est variable.

Utilisons « The go product roadmap »

Dans le framing agile, nous privilégions l’utilisation du canvas « the go product roadmap » de Roman Pichler qui permet concrètement de définir une roadmap agile claire et synthétique. Si cette feuille de route est parfois exigé par le contexte (demande du marketing, top management…), elle ne doit en revanche en aucun cas imposer un effort insurmontable pour la mettre en oeuvre.

Voici à quoi ressemble ce canvas très efficace :

Nous recommandons de commencer par définir une première colonne; celle-ci pourrait définir la version MVP/MMP du produit. Il est en effet fortement recommandé de faire cette version minimale comme première release de votre feuille de route.

Date de livraison ou plage de temps

La première case correspond à la date d’échéance espérée pour cette première version. Il est très difficile de déterminer celle-ci tant de nombreux éléments vous manqueront. Voici de vraies questions qui complexifieront la définition de cette date :

• Pouvons-nous vraiment dire aujourd’hui que nous avons pensé à tout ?
• N’allons-nous pas découvrir des éléments qu’on ignore aujourd’hui ?
• N’allons-nous pas avoir des difficultés pour implémenter la solution ?
• Pouvons-nous assurer que nous rencontrerons pas des problèmes imprévus tout au long de la réalisation ?
• …

En effet, il est tout simplement impossible de prédire ce qui se passera à l’avenir. Nous pouvons d’ailleurs prendre en exemple la période de confinement (covid19) qui a mis à rude épreuves de nombreuses organisations.

Mais alors comment faire pour définir cette date ?

Dans ce cas, il est tout a fait possible d’utiliser un release board pour vous aider dans votre roadmap. Attention, cet exercice a pour but de vous aider à avoir une vision plus claire mais les résultats ne pourront pas être considéré comme un contrat de réalisation du produit. Cependant le maintien régulier de cette roadmap, l’équipe pourra alors mieux communiquer avec les équipes extérieures impactées par la date prévisionnelle de la release.

Conseil: Si l’équipe décide de faire cette roadmap, elle devra la maintenir tout au long du cycle du produit. Si les dates doivent évoluer et qu’elles impactent d’autres équipes de l’organisation, elles devront être communiquées le plus tôt possible. Il ne faut pas oublier qu’un jour de retard sur la communication de ce type d’éléments peut amener à des retards bien plus long pour d’autres équipes.

1/ Estimer la capacité d’une itération (sprint) de l’équipe de réalisation

Pour se faire une « prévision » de la capacité de faire de l’équipe de réalisation, le framing agile propose un atelier très simple qui ne prendra pas plus de 20 minutes. L’idée n’est pas d’essayer d’avoir une prévision 100% juste (qui serait utopique de croire possible), mais de se faire une idée à peu prêt viable d’une date de release.

L’équipe devra alors définir l’équipe(s) type qui est envisagé pour la réalisation du produit :

• quels profils sont nécessaires (selon les expertises)
• combien de personnes pour chaque type de profil
• définir la séniorité (junior, senior…) des profils et si ils ont un historique au sein de l’organisation

Afin de pouvoir faire cette estimation, l’ensemble de l’équipe devra également définir la durée des itérations (sprint) et la date de démarrage de la première itération de réalisation. En effet, c’est un élément indispensable pour faire une estimation de ce type.

Le lead technique (ou les leaders techniques) de cette équipe de framing agile sera responsable d’arbitrer ces éléments tout en écoutant les différents points de vus en cas de désaccord entre les membres de l’équipe. Parfois, le nombre de développeurs sera imposé (lié au budget dédié et à la date imposée) ; et parfois, le nombre de développeurs sera libre (pas de budget dédié).

N’hésitez pas à rendre ce travail visuel de façon à mieux visualiser la force potentielle de la future équipe. Pour cela, j’aime beaucoup par exemple la représentation de la matrice de compétence :

Quand cela est fait, nous allons demander aux profils techniques de définir les stories pouvant faire partie du premier sprint qu’il pense être réalisable. Ils devront prendre en compte l’équipe qui a été définie pour le produit ; ce travail exige que certains de ces profils aient de véritables expériences dans le domaine afin de ne pas être trop approximatif dans son estimation.

Pour cela, ils poseront les items sur un espace dédié (sur le mur ou sur la table de l’Obeya) afin de définir ce qu’ils pensent qui sera réalisable lors du premier sprint.

 

Conseil: Si le projet n’est pas trop complexe ou particulier, il peut être intéressant de demander à des experts du domaine de participer à cet atelier même si ils ne seront pas des membres de l’équipe. Cela permet de challenger la capacité et  probablement de mettre plus en avant certaines potentielles difficultés techniques.

Ici, nos profils techniques ont estimé que l’équipe technique pourra réaliser 5 stories qui totalisent ensemble 31 points d’effort.

Quand ce premier travail est réalisé, le framing master rappellera des potentiels soucis que l’équipe pourra rencontrer tout au long du projet pour rechallenger l’estimation du leader technique (et autres profils techniques). Il pourrait citer par exemple des problèmes très fréquents que nous rencontrons :

• des soucis de mises en production
• des environnements de recette pas toujours stables
• audits de code imposés par la hiérarchie
• des absences conséquentes pour maladie
• …

Il se peut que nous voyons en conséquence la capacité imaginée se diviser par deux après une prise de conscience de l’ensemble des profils techniques.

Quand les profils techniques valident que ce premier sprint est réaliste, le framing master notera le total des points d’effort de ce sprint en dessous de l’espace dédié à la reflexion présenté plus haut.

2/ Il est essentiel de miser sur la stabilité

Il est essentiel de penser à avoir des équipes stables car l’ajout de nouveaux développeurs en cours de projet ne sera pas productif (voire même contre-productif).

Voici un graphique qui représente la différence entre une équipe stable et une équipe instable :

L’ajout d’un ou de plusieurs développeurs en cours de projet n’amène jamais une équipe à devenir plus productive. Au contraire, il y a différents facteurs qui vont amener l’équipe à être moins productive pendant une période assez conséquente :

• création de nouvelles interactions
• les arrivants doivent apprendre le produit, l’environnement et le contexte
• les arrivants doivent être formés et aidés pour bien s’intégrer

Au niveau des interactions, quand nous avons une équipe de 5 personnes, nous avons 10 types d’interactions au sein de l’équipe. Le fait d’ajouter deux développeurs au sein de l’équipe en cours de projet, ajoutera 11 nouvelles interactions soit plus que les interactions déjà présentes.

Vous comprendrez aisément que l’équipe devra apprendre à nouveau à se connaître et que ces interactions ne seront pas forcément bonnes dès le départ voire sur le long terme. Il ne faut jamais ajouter de nouveaux profils pour tenter de combler une impression de retard surtout lorsque la date d’atterrissage approche à grand pas.

Pour éviter ce type de désagrément, le framing agile amène les participants à bien réfléchir sur l’importance de définir une équipe stable dès le démarrage du premier sprint.

3/ Définir le temps minimum nécessaire pour réaliser la première release

Afin de déterminer la date de la release ils sera indispensable de connaitre l’effort total nécessaire pour réaliser le fameux MVP/MMP du produit. Si vous avez bien réalisé votre story mapping advanced, il vous faudra additionner les points d’efforts définis de tous les éléments inclus dans la partie MVP/MMP et la partie NFR :

Donc si nous prenons par exemple la capacité de l’équipe technique sur un sprint et le total de point d’effort définie pour la réalisation de la première release, nous aurons très simplement :

Nombre de sprint nécessaire = total point d’effort release 1 / capacité sprint 1
Nombre de sprint nécessaire = 310 / 31
Nombre de sprint nécessaire = 10

Sachant que le scope est variable en agile, nous pourrions avoir les cas présent tout au long de la réalisation de cette première release :

• Le MVP/MMP finalement est revu
• Des feedbacks peuvent changer la priorisation du backlog

Ainsi, nous recommandons fortement de suivre les règles suivantes :

• Ajoutez 30% de sprint en plus -> ici 10 sprint x 3 = 13 sprints
• Envisagez une baisse de capacité par moitié pour les 2 semaines de Noël, juillet et août

Avec tous ces éléments, vous pourrez définir une date de release réaliste et qui permet de faire face à d’éventuels problèmes ou découvertes rencontrés lors de la réalisation.

A présent vous pouvez remplir la case « Date » de la première release ; mettez la date du dernier jour de la dernière itération envisagée.

Conseil : si la date définie ne convient pas par rapport aux objectifs de l’entreprise, l’équipe pourra proposer plusieurs scénarios différents en jouant sur le nombre de ressources. Ces différents scénarios pourront être soumis au Decision Committee qui aura plus de faciliter pour prendre une décision concrète sur le sujet. Attention, ne baissez pas les estimations des user stories (ou n’augmentez pas la capacité définie) pour faire plaisir à l’ensemble de l’organisation ; cette mauvaise pratique aura un coût très important et rendra la roadmap totalement irréaliste.

Nom de cet évènement

Il est souvent intéressant de donner des noms à ses release. Des entreprises utilisent des noms de fruits, d’autres d’animaux pour amener un petit côté plus sympa. D’autres privilégieront de simples numéro de versions ou de sous versions. Rien de bien complexe, l’équipe saura faire le choix le plus adapté à leur organisation.

Les objectifs

Nous mettrons dans cette case, les objectifs (potentiellement définis dans le product vision board) que tentera d’atteindre cette première release. Nous vous recommandons de définir au maximum 3 objectifs et au minimum 2 objectifs clés. Ceux-ci seront très importants car ils devront être suivi régulièrement pour assurer que les résultats vont dans le bon sens.

Si ce n’est pas le cas, le product owner pourra revoir la priorisation de son product backlog pour tenter des petites expérimentations qui permettront de voir les métriques repartir dans le bon sens.

Les grosses fonctionnalités

Dans cette case, nous mettrons toutes les grosses fonctionnalités qui seront incluses dans notre première release ; nous parlons pas de user-stories mais d’un niveau supérieur au scope plus large (voire plus large que les fonctionnalités définis lors du story mapping advanced).

Si ces fonctionnalités ont beaucoup de chances de rester tout au long de l’avancement de cette plage de temps, son contenu pourra varier selon différents éléments :

• changement de contexte
• feedbacks constructifs

Les métriques

En agile tout comme en lean startup, nous aimons mesurer les résultats de nos produits. Il est conseillé d’indiquer comment nous les mesurerons dans notre roadmap agile. Nous allons ainsi décrire plusieurs métriques pour voir si :

• nous allons dans  la bonne direction en cas de livraison continue
• notre livraison a les effets désirés

Nous privilégions fortement de faire de la livraison continue quand cela reste possible. Cela permettra de pouvoir réaliser des petites expérimentations afin d’atteindre peut-être plus rapidement les objectifs imaginés précédemment.

L’atteinte de ces métriques valideront que nos objectifs ont bien été atteint.

Définir les autres releases

Bien que vous pouvez utiliser une technique similaire pour définir d’éventuelles autres releases, nous vous recommandons de ne pas autant aller dans les détails pour les définir. Privilégier de les estimer en « grosse maille » par rapport aux résultats que vous avez obtenus pour la première release.