How to Convince Your CFO to Use Scrum
Convaincre votre directeur financier (Chief Financial Officer: CFO) et autres cadres sup de votre société d’utiliser Scrum est en réalité très simple, dans la théorie. Essayez cette stratégie la prochaine fois vous devez aider des exécutifs à comprendre pourquoi Scrum est un processus important et utile pour le développement logiciel.
Selon mon expérience, les experts financiers et les directions sont très attentifs à savoir ce qui arrivera si de certaines situations se produisent et veulent souvent simuler des scénarios dans leur stratégie de management des risques.
La meilleure approche dans cette situation est d’exposer la valeur business que vous livrerez si le projet devait s’arrêter en cours d’exécution.
Il y a plusieurs raisons pour lesquelles des projets de développement de logiciel sont arrêtés avant leur date de fin :
- sévères compressions budgétaires
- changement de priorités de projet,
- la société a été rachetée
- le budget approuvé n’est pas suffisant pour couvrir le périmètre complet du projet
En justifiant au management pourquoi utiliser utiliser Scrum il y a quelques années, nous avons posé cette question à la direction : Et si le projet devait être arrêté à environ 60 % de son effort ou calendrier ?
Pour cette démonstration, nous avons comparé deux projets. Le projet W, est exécuté dans une approche traditionnelle en cascade (Waterfall). Le projet S, utilise une approche agile.
Le projet W a un modèle de réalisation et une dépense typique par phase :
- 10 % du temps/effort concernent la préparation et la définition du projet
- 25 % du temps/effort sont passés sur une analyse minutieuse du livrable logiciel
- 40 % du temps/effort sont passés sur le développement et les tests de système
- 20 % du temps/effort concernent les tests d’intégration et de recette ainsi que les corrections de bogue
- 5 % du temps/effort sont requis pour mettre le logiciel en production et le lancer avec les clients.
Comme vous pouvez voir, si on ordonne à l’équipe d’arrêter le développement à 60 % du parcours dans ce processus nous serons en réalité en plein milieu de l’écriture de code et de l’exécution de quelques tests système. Dans ce scénario, « la valeur » que le projet W délivre à la société est en fait un tas de documents d’analyse et un morceau de logiciel non testé.
Maintenant jetons un coup d’œil au modèle de dépense du Projet S, fonctionnant en mode Scrum:
- 10 % du temps/effort concernent la préparation et la définition du projet
- 85 % du temps/effort sont passés à analyser, développer et tester des incréments de fonctionnalités qui sont livrés itérativement dans des « sprints » bihebdomadaires
- 5 % du temps est nécessaire pour clôturer correctement le projet
Si le Projet S doit s’arrêter à 60 % en temps ou en effort dépensé, l’équipe aura déjà complété une bonne quantité de sprints et délivré un certain logiciel utilisable. Dans ce scénario, le projet S délivre une valeur réelle et des fonctionnalités utilisables (probablement environ 40 % à 50 % du produit total) au client.
Dans l’entretien avec la direction, nous avons utilisé un graphique sur la valeur acquise pour mieux illustrer notre point. Il inclut les suppositions suivantes :
- Le démarrage et la définition d’un projet / produit correspondent à 0 % de la valeur totale
- La documentation d’analyse et de conception représente 15 % de la valeur totale
- Le code source avec les tests unitaires système correspondent à 35 % de la valeur totale
- Le logiciel complètement testé et packagé représente 50 % de la valeur totale
Notre directeur financier et les autres cadres supérieurs ont décidé de commencer à utiliser Scrum pour nos développements de nouveaux produits parce qu’ils croient fermement que, d’une perspective de management des risques de la société, il vaut mieux utiliser Scrum qu’un développement par phase.
DantotsuPM.com 