Coaching Agile : Cône d'incertitude et planification agile !

Article de Eric Lannemajou pour AgileScrumEtNous

L’une des valeurs du manifeste Agile est de favoriser l’adaptation par rapport à un plan établi. Cette valeur est parfois mal interprétée et ne signifie pas qu’il ne faut pas planifier. Mike Cohn nous explique dans Agile Estimating and Planning les raisons pour lesquelles il est nécessaire pour une équipe Agile de planifier.

Dans mon expérience, j’ai rencontré plusieurs équipes qui se demandaient comment il fallait planifier et surtout comment estimer les stories. Faut-il estimer en point, en jours idéaux, avec la suite de Fibonnaci ? L’estimation du travail est souvent source de tension ou de conflit entre l’équipe de développement et les commanditaires du projet ou encore avec le Product Owner. Mais avant de se poser la question du « comment? », j’invite les équipes à revenir sur le « pourquoi? ». Pourquoi estimer ? A quoi et à qui cela sert ?

Mike Cohn nous explique ces raisons dans Agile Estimating and Planning. Un plan doit permettre de :

guider les décisions des investissements à réaliser.
savoir si un projet est sur le point de livrer des fonctionnalités que les utilisateurs attendent.
connaître le nombre de ressources disponibles pour travailler sur ce projet pendant une période définie.

Planifier est souvent difficile et les équipes peuvent tomber dans les deux extrêmes de ne pas planifier du tout ou de trop planifier. Planifier est une activité difficile et le cône d’incertitude ci-dessous nous démontre combien il est difficile d’estimer le projet dans les premières phases de ce dernier. A la définition du projet, l’incertitude est de 60% et il faut attendre le design détaillé pour réduire cette incertitude à 10%. Ce qui explique donc que plus de 2/3 des projets dépassent le coût estimé initialement.

cone of uncertainty agile

Mais alors si cela est si difficile de planifier un projet, pourquoi effectuer cette activité ? Et bien tout d’abord pour :

réduire le risque : les discussions qui servent à estimer le projet permettent de mettre en lumière les potentiels risques du projet.
réduire l’incertitude : un des risques les plus importants d’un projet n’est pas de ne pas sortir dans les temps mais bien de développer des fonctionnalités qui ne répondent pas aux besoins des utilisateurs. Ce risque peut être atténué via une planification agile continue qui permet de récupérer les retours utilisateurs au fur et à mesure du projet.
aider à prendre de meilleures décisions : l’estimation du coût d’un projet et de sa valeur métier nous permet de décider si le projet doit être lancé.
établir la confiance : les fréquentes livraisons de fonctionnalités permettent d’établir la confiance entre le client et les développeurs. Les estimations deviennent de plus en plus fiables au cours des itérations et permettent de prioriser les fonctionnalités en se basant sur l’estimation fiable de l’équipe de développement.
transmettre de l’information : un plan ne garantit pas la livraison d’un périmètre à une date précise mais permet néanmoins de fixer un niveau d’attente et l’approche pour arriver à satisfaire cette attente.

Maintenant que nous savons à quoi sert la planification et l’estimation agile, nous pouvons insister sur le « comment ». Certaines équipes estiment leurs stories en point de complexité/d’effort alors que d’autres les estiment en jours idéaux. Les jours idéaux sont des jours où chaque membre de l’équipe consacrerait 100% de son temps de travail dans la journée à la story sans être dérangé par d’autres activités professionnelles.

Les partisans du chiffrage en points mettent en avant que ce type de chiffrage :

permet aux équipe multi-fonctionnelles de pouvoir avoir une mesure commune.
est constant dans le temps, ne dépend pas du niveau de capacité ou de compétence de la personne qui va réaliser la story.
est une pure mesure de taille et ceci permet donc de pouvoir chiffrer par analogie, de manière relative. De plus, comme cette mesure est complétement abstraite, les équipes ne devraient pas être tentées de comparer cette estimation avec du temps passé.
est plus rapide grâce notamment à la possibilité de comparer de manière relative par analogie avec des stories de référence.

Enfin, les jours idéaux varient d’une personne à une autre. Cependant, il est plus facile d’expliquer un chiffrage en jours idéaux aux personnes extérieures à l’équipe et pour une équipe qui débute, ce mode de chiffrage est plus facile à appréhender.

L’action de planification pour une équipe agile s’effectue à plusieurs horizons et plusieurs niveaux d’abstraction. L’action de planifier revient à se fixer des objectifs sur une période donnée et à les réviser tout en décalant des objectifs plus long terme. Pour une équipe qui travaille en SCRUM, l’équipe va fixer un objectif de release avant le premier sprint et réviser ce dernier au fur et à mesure des sprints. En effet, la release va être initialement estimée et planifiée puis revue à la fin de chaque itération pour évaluer comment le périmètre associé à la date évolue. L’action ici sur le périmètre du sprint a une influence sur le périmètre de la release. On parle ici de planification en couches successives ou en oignon.

estimation et planification agile

Le dernier point détaillé par Mike Cohn que je souhaiterais partager est celui du niveau de détail de l’estimation et de la planification. A quel moment et niveau de détail faut-il arrêter de planifier ? Cette question peut aussi se poser dans un projet en cycle en V et j’ai déjà par le passé fait l’amère expérience de trop planifier un projet. Ce problème se présente par le fait de planifier de toutes petites tâches et donc de planifier tout le temps. Planifier devient alors l’activité principale et l’information portée par ce niveau de détail n’apporte pas assez de plus-value au projet. Mike Cohn nous explique ce travers avec le petit exemple suivant : « si vous vous demandez combien de cookies j’ai mangés l’an dernier, vous avez plusieurs options pour répondre à cette question :

Estimer le nombre de cookies au hasard
Demander à mes proches, mes amis, ma famille
me suivre pendant une journée, compter combien je mange de cookies et extrapoler sur un an.

Cependant, si votre but est de savoir si vous pouvez m’offrir ou non, une boîte de cookies, alors vous n’avez pas besoin d’avoir une mesure ultra précise et il n’est donc pas nécessaire d’effectuer trop de recherches. Dans ce cas précis, la première solution pourra convenir. Quand on planifie, il faut donc toujours se demander dans quel but afin d’évaluer le niveau d’effort et de détail que nécessite cette planification.

Je vais vous décrire une situation que j’ai déjà rencontrée et qui peut s’avérer être un parfait exemple d’une planification peu « agile ». Lors d’un projet avec un centre de service, j’ai travaillé avec une équipe qui chiffrait les stories en points en utilisant la suite de Fibonnaci. L’équipe n’était pas dédiée et le nombre de point d’une story, convertie par un coefficient donnait directement le nombre de jours et donc le coût de la story. L’équipe allouait un nombre/capacité de points différent à chaque itération qui représentait donc directement le nombre de jours pendant lesquels l’équipe allait travailler sur le produit. Cette situation peut aboutir à plusieurs effets pervers :

Comme l’équipe estime une capacité ou un coût de story fixe et que celui-ci représente le nombre de jours de travail sur la fonctionnalité, il n’est plus possible de lisser entre les stories d’un même sprint.
Comme l’équipe estime avec la suite de Fibonnaci et que les stories sont directement converties en jours/homme, une story légèrement supérieure à 8 passe à 13, ce qui n’est pas du tout le même coût : le commanditaire se sent lésé.
Comme les développeurs estiment chaque story et prennent un engagement sur chacune d’elles, ceux-ci ont tendance à se protéger et réhausser leur chiffrage.
Comme l’équipe n’est pas dédiée et que la capacité change à chaque itération, on perd la possibilité d’apprendre au cours des sprints.
Le fait de ne pas estimer de release et de changer la capacité à chaque itération supprime toute possibilité de planification.

Cette situation aboutit donc à une forte tension entre le commanditaire et l’équipe de développement. Sans compter que ceci rajoute aussi de la pression sur les développeurs qui doivent prendre un engagement à la story. Ce pattern qui favorise un rapport contractuel et impose une facturation à la story est selon moi anti-agile.