Release board

L’atelier du release board va être crucial pour la suite du projet. Il n’est pas rare qu’il soit le point de blocage de certains projets où les budgets ne sont pas suffisants pour envisager de sortir sereinement le MVP/MMP du produit. Il peut amener à un NO GO ou à un déclenchement urgent d’un Decision Committee.

1/ Estimer la capacité d’un sprint avec le release board

En première partie de cet atelier, nous allons demander au leader technique (ou aux leaders techniques) de définir les stories pouvant faire partie du premier sprint qu’il pense être réalisable.

Pour commencer, il faudra définir le nombre de membres théoriques que nous désirons avoir au lancement du projet. Il existe d’ailleurs plusieurs visions à ce sujet au sein des entreprises. 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é).

Nous allons laisser les profils techniques remplir un premier bac qui représentera l’ensemble des stories qu’ils pensent que cette équipe théorique pourra réaliser lors d’une première itération.

Ces profils techniques présents lors du framing agile devront également définir le type de profils qui constituera cette équipe de démarrage du framing agile :

• profil junior ou sénior
• profil avec ou non un historique dans l’entreprise
• compétences des profils attendus

Voici à quoi ressemble ce release board rempli par les profils techniques que nous réaliserons sur le mur :

Ici, nos profils techniques ont estimé qu’ils pourront faire 3 stories qui totalisent ensemble 26 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 au dessus du bac du premier sprint (en rouge).

2/ Estimer les prochains sprints avec le release board

L’équipe va à présent estimer la capacité de faire des prochains sprint en prenant la capacité du sprint 1 déterminée juste avant en référence.

Elle indiquera la capacité au-dessus de chaque bac en prenant en compte :

1. Les éventuelles absences lors des vacances très convoitées (Noël, été…)
2. Les mois les plus difficiles de l’entreprise
3. Les jours fériés

3/ Remplir le release board 

Le Product Owner pourra alors remplir le release board en priorisant par la valeur. Voici d’ailleurs la courbe idéale qu’on tentera d’atteindre.

Nous considérons qu’il y a une période de rodage lors du démarrage de la phase d’exécution de l’équipe de développement d’où cette montée de courbe lors des premiers sprints. L’équipe ne sera pas 100% performante dès le démarrage de la phase d’exécution.

Tout au long du projet, nous prendrons en compte les feedbacks des utilisateurs clés, sponsors et parties prenantes ; cela changera probablement la priorisation du backlog surtout si certains feedbacks ont une grosse valeur business que des stories précédemment définies.

Pour obtenir cette courbe, on priorisera par ROI (Return on investment) car la valeur n’est pas suffisante pour livrer un maximum de valeur le plus tôt possible. En effet, nous pourrions avoir une story avec beaucoup de valeurs mais également avec une charge importante ; elle ne sera donc pas forcément la plus intéressante à livrer tôt sur le projet.

Voici le calcul très simple pour obtenir le ROI de chacune des stories :

ROI (Return on Investment) = Valeur business / Point d’effort

Nous tenterons de livrer plus tôt des stories qui ont le plus de ROI par rapport aux stories qui en ont le moins.

Conseils : Ne limitez pas le contenu de votre release board au MVP/MMP. Ajoutez au minimum 30% de contenus complémentaires (Non MVP/MMP). Cela a pour but de vous donner un peu de marge pour avoir la capacité de prendre en compte des feedbacks clients qui arriveront tout au long du projet. De plus cette technique vous permettra de limiter les risques en cas d’absences imprévues d’un membre de votre équipe ou en cas de départ anticipé de l’un d’entre elle.

4/ Définir la date d’atterrissage

Quand le release board est complet, l’équipe obtiendra une date d’atterrissage en comptant le nombre de sprint.

Si il y a des attentes fortes au niveau date de livraison, le product Owner pourra ajuster le release board en imaginant un autre scénario comme celui d’ajouter X développeurs pour approcher la date d’atterrissage.

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.

5/ Avoir la sécurité budgétaire

Comme le rappelle le “moderne agile” définit par Crisp, la sécurité de l’environnement est indispensable pour le bon déroulement d’un projet. Le budget fait parti de ces facteurs qui doivent impérativement être sécurisé tant il peut être un facteur de désastre pour les projets au sein de nos entreprises.

Le framing agile insiste énormément sur l’importance de s’assurer que le budget est suffisant lorsque celui-ci est défini auparavant par une enveloppe budgétaire ou de définir un budget qui sécurise à 100% la possibilité de livrer au minimum le MVP/MMP lorsqu’il n’y a aucune enveloppe budgétaire de défini en amont.

Combien coûtent nos profils ?

Si vous fonctionnez en ETP (équivalent temps plein) et que cette pratique valide à 100% la présence des profils, inutile d’aller au delà de ce calcul pour la partie profil. Les entreprises fonctionnant sur cette unité de mesures vous assureront ces profils pendant le temps défini.

Si vous fonctionnez avec des prestataires ou des freelances, cherchez le TJM (taux journalier moyen) des profils nécessaires à votre projet en prenant si possible la fourchette haute. Je rappelle que certains profils techniques sont difficiles à trouver en cette période ; le fait de vous assurer une fourchette haute vous évitera de devoir prendre trop de temps dans la recherche de profils.

Si vous fonctionnez avec des internes, utilisez les méthodes de calculs imposés par l’entreprise qui diffèrent souvent beaucoup entre les structures. Il me serait très difficile de vous expliquer les nombreuses pratiques que j’ai rencontré tout au long de ma carrière ; cela m’imposerait de faire un livre complet juste sur ce sujet.

Pour définir le coût de l’ensemble des profils, il vous suffira de prendre l’équipe imaginée et la durée estimée du projet. Un simple tableau pas forcément très sexy peut parfaitement vous aider :

Profil	Quantité	TJM	Coût
Dev front	2	500	60000
dev back	2	600	72000
Product Owner	1	700	42000
Scrum Master	1	600	36000

Total : 210k€

Combien coûtent les profils transverses ?

Il n’est pas rare dans les grandes entreprises d’avoir l’obligation de faire appel à des profils transverses. Dans certaines configuration, cela représente un coût refacturé au projet lui même ; il sera indispensable de le calculer dès maintenant afin de ne pas se faire surprendre par ces coûts complémentaires : devops, ingénieur sécurité, architecte fonctionnel…

N’hésitez pas à rajouter des lignes dans votre tableau pour réaliser ces calculs.

Conseils : il est fortement conseillé d’avoir un template défini pour la partie budgétaire dans les grands groupes pour sécuriser cet aspect qui peut rapidement devenir très complexe à gérer. Le moindre oublie pourrait venir perturber le bon déroulement du projet.

Combien coûtent les environnements et logiciels ?

Il est également important de bien définir les coûts des environnements et des logiciels utilisés. Bien que le coût est souvent bien plus faible que celui des ressources, dans certains secteurs, cette règle ne sera pas forcément vraie.

Pour réaliser les lignes budgétaires supplémentaires, les profils techniques de ce framing agile devront déjà travailler sur la partie “analyse technique” pour définir les pré-requis nécessaires pour cette partie budgétaire.

Dans certaines entreprises, des forfaits sont définis pour les différents types d’environnements et différents types de logiciels utilisés. Dans ce cas, n’hésitez pas à les utiliser.

Ajoutez les lignes nécessaires dans votre tableau budgétaire pour avoir un coût global du projet.

Validation du budget

Quand le tableau est intégralement terminé, vérifiez que le budget nécessaire est équivalent à l’enveloppe dédiée au projet ou plus bas que celle-ci (dans le cas où une enveloppe budgétaire était prédéfini en amont du framing agile).

Si vous n’êtes pas dans ce cas de budget prédéfini en amont du framing ou que le budget calculé est supérieur à celui estimé auparavant, déclenchez au plus vite un “decision committee” pour prendre une décision budgétaire essentielle pour continuer le projet.

Il sera inutile de continuer le projet si vous ne pouvez pas assurer l’enveloppe budgétaire pour celui-ci. Il n’est pas toujours simple de dire “STOP” ; cependant, il est parfois nécessaire de le faire pour éviter des pertes d’argent inutiles. Continuer un projet sans avoir la sécurité budgétaire est extrêmement dangereux.

Si l’exigence budgétaire est au-dessous de ce qu’il peut être donné au projet, analysez en Decision Committee si le scope peut-être revu à la baisse afin de réduire les coûts du produit à réaliser. Cela imposera de prendre de grandes décisions essentielles pour la suite du projet et qui ne seront pas sans conséquence ; cependant, il est impératif de sortir du Decision Committee avec l’assurance d’avoir le budget pour effectuer l’ensemble du projet ou de dire “No go” et d’arrêter immédiatement le projet pour limiter les pertes inutiles.

Envisager des scénarios multiples

Dans le cadre où un « no go » est envisagé, il est conseillé que l’équipe propose trois scénarios très différents pour voir si une alternative peut correspondre à l’ensemble des parties prenantes et des sponsors. Voici les éléments sur lesquels il est possible de jouer pour la proposition de scénarios variés :

• diminuer le scope initial imaginé
• envisager un pivot

Si aucun des scénarios proposés ne convient à l’ensemble des acteurs, le « no go » sera prononcé avec beaucoup moins de regret. Cependant lors du Decision Committee, les parties prenantes et/ou sponsors peuvent  également proposer un scénario alternatif.

En cas de décision imprenable

Si certains membres du Decision Committee ne pourront pas prendre de décisions hâtives, ils devront notifier une nouvelle date proche pour donner leur décision et assumer les pertes le temps de cette prise de décision. Ce format n’est pas celui qui est privilégié mais il est parfois obligatoire au vue de la complexité des processus budgétaires.

Conseils : il est important d’enclencher les recherches de profils pour l’équipe de réalisation dès que les budgets et les ressources sont validées pour le projet. Attention en cette période difficile sur les aspects recrutement de profils IT ; il ne faut pas perdre une seule seconde pour lancer les recherches.  Certaines entreprises ont des équipes “sourcing” pour gérer les demandes de prestations sur les profils nécessaires ; cependant, il ne restera que 2 semaines environ pour effectuer ces recherches lorsque vous aurez validé le nombre de profils. Dans certains cas, bien que ce ne soit pas la situation idéale mais imposée par le contexte, il faut lancer les recrutements rapidement pour ne pas se retrouver sans profil dès le démarrage de la phase de réalisation.