Taux de succès des projets SCRUM
Dans toute bonne présentation de SCRUM, le schéma suivant nous est présenté afin de démontrer qu’il faut changer la méthodologie de mise en œuvre des projets IT, car beaucoup trop de projets sont un échec :
Ce qui m’étonne dans toutes ces présentations c’est que personne ne prends le temps d’expliciter le « Challenged ». De mon point de vue, un projet non challengé est une bizarrerie. Même sur un projet ou le besoin est clairement défini, ou l’implication du client est bonne, ou l’équipe est performante, il faut gérer les risques et des problèmes apparaissent. Passons.
Ensuite, j’ai voulu effectuer le même type de graphique sur l’ensemble des projets que j’ai piloté depuis le passage à SCRUM. De mon côté, je vais partir sur une échelle de 1 à 10, d’un projet ou tout se passe pour le mieux à un projet qui rate.
- Entre 1 et 4 le projet est un succès.
- Entre 5 et 8 le projet sera challengé.
- 9 et 10 le projet est un échec.
Sur l’ensemble des projets, la moyenne de toutes ces notes est 5. Au final, 20% des projets sont en échec, 40% sont challengés et 40% sont un succès – encore une fois de mon point de vue.
Cette analyse ouvre une question plus large : qu’est-ce que le succès ? quels sont les critères qui permettent d’affirmer que le projet est réussi ? Quelques critères mettent sur la piste :
- Un respect des charges et des délais
- Une montée en compétence de l’équipe
- La satisfaction du client
Concernant les projets que j’ai considérés comme échoués, je remarque qu’à chaque fois la méthodologie a été rejetée d’entrée de jeu, sois par un prestataire, soit par le client lui-même et que techniquement, ces projets n’étaient pas des « challenges » énormes Rétrospectivement voici ce qui permettrait d’éviter l’échec dans ces cas :
- En cas de partenariat, intégrer un Scrum Master de confiance chez les équipes sous-traitantes, puis « Scrummer les scrums » en donnant le même rythme aux équipes internes et distantes.
- En cas de rejet du client de la méthodologie, ou de forte méfiance, proposer une formation Product Owner au client ou définir un Product Owner en interne avec l’accord du client qui sera son unique contact en dehors des démos afin de protéger l’équipe.