Agilité et projets au forfait, c’est possible ?

On a bien souvent tendance à associer l’agilité au développement des produits (et des projets) de petite à moyenne envergure. Dans certains cas, ce  modèle vient se  » heurter  » à un engagement au forfait.

Pas nécessairement me direz-vous ?! Candides que vous êtes…

Il est vrai que dans un monde parfait, où le scope fonctionnel ne change jamais, où rien ne vient perturber une équipe, où le Product Owner a une vision juste et éclairée six mois à l’avance… Il est vrai que dans ce monde là, il serait possible d’être agile tout en respectant une obligation de résultat. Parce que c’est bien de cela qu’il s’agit. Il y a d’un côté un forfait avec obligation de résultat dans lequel le l’équipe va s’engager sur les coûts, les délais et le contenu. De l’autre l’agilité, Scrum et l’obligation de moyens sur les ressources et les délais.

Donc ces deux modèles sont incompatibles ? Eh bien pas forcément !

Respecter le triangle Agile

L’agilité répond à un besoin de souplesse et d’adaptabilité dans le développement d’un produit. Ce besoin vient en partie du client lui-même. Dès lors, est-il réellement judicieux de fixer le contenu du produit trois, six ou douze mois à l’avance ? Dans la pratique, il est impossible de respecter pleinement les trois constituantes d’un projet (coûts, délais et contenu). Au final, il y a souvent soit un dépassement de délais, soit un déficit de qualité ou de fonctionnalité. Et presque toujours un surcoût.

Donner de la visibilité

Une fois ce constat établi, quels moyens avons-nous pour donner la visibilité au client ?

On va en premier lieu s’engager sur le couple ressources / délais. Ça c’est le budget, et c’est souvent la seule variable connue au lancement du projet. Puis on va  donner une projection du contenu, une estimation du résultat que le client obtiendra avec ce budget. Pensez au story mapping ou à d’autres outils ! Attention il ne s’agit toujours pas de s’engager sur le périmètre final, auquel cas on perdrait toute agilité en plus de créer un risque.

Il ne faut pas oublier que ce risque devra être partagé entre le client et le prestataire. En réalité, c’est le prestataire qui porte le risque la plupart du temps.

Au périmètre fixe répond la vélocité

Il est possible d’aller plus loin, prenons l’exemple de Scrum. Après quelques sprints (à équipe et durée fixes évidemment), une fois que l’équipe aura gagné en maturité, on peut et on doit calculer vélocité de la Dev Team. Cela permet de prédire la valeur qui pourra être produite par l’équipe dans les sprints à venir. Ce niveau de prédictibilité doit être un objectif à atteindre pour toute équipe Scrum.

Pour cela il faut de la confiance et de la bienveillance entre le client et l’équipe de développement, mais ça c’est un autre sujet…

Crédits illustration : Agile utile