Il serait un euphémisme de dire que les méthodes agiles intéressent. Le nombre d’associations proposant des certifications agiles ne cesse d’augmenter. Ces mêmes associations se targuent d’un nombre exponentiel de certifiés. Le sujet occupe une place importante dans les recherches scientifiques et les blogs (1).
Les méthodes agiles ne font pas que faire parler, elles sont aussi plébiscitées. On trouve ci et là, des articles ou des conférences expliquant leurs bénéfices et l’appréciation qu’en ont les équipes (2).
En tant que consultant, lors d’interventions chez certains de mes clients, je constate cependant que si les équipes projets maîtrisent bien les démarches agiles, le management de l’entreprise n’a pas nécessairement opéré de virage « agile ». Il reste sur les mêmes approches que celles utilisées avant le déploiement des méthodes agiles dans ses projets.
Autrement dit, il semblerait que dans ces entreprises, les méthodes agiles soient cantonnées au développement et à l’ingénierie. Les symptômes sont nombreux et pourrait faire l’objet d’un article à part entière. Cependant, on peut citer quelques freins à leur adoption :
- On ne voit pas de raison de changer ou de bénéfices
- Il est possible que certaines personnes voient les méthodes agiles comme une approche technique uniquement
- Les équipes ont été formées à ces méthodes mais pas le management, ces approches leur semblent donc obscures et inconnues
Si vous faites partie d’une équipe projet utilisant les méthodes agiles, vous constatez peut-être cette situation. Imaginons que vous gérez vos projets avec l’approche Scrum. Vous vous retrouvez face à une confrontation des visions. Vous utilisez un modèle empirique ; votre management un modèle prédictif. Vous gérez des sprints ; votre management, des dates d’échéances. Vous gérez des users stories dont les priorités évoluent sans cesse ; votre management, des phases et des objectifs planifiés dans le temps.
Si vous gérez des projets, il y a peu de chances que vous soyez en mesure de changer ces pratiques du jour au lendemain. Vous avez bien sûr tout à gagner en essayant de faire évoluer les pratiques, cependant, imaginons à nouveau que le management sollicite les éléments précédemment cités en urgence.
Adressons ces problématiques en détail.
Sprints vs date d’échéance
Il apparait à première vue que les 2 notions semblent antinomiques. Cependant, si vous définissez des sprints d’une durée fixe, il est possible de répondre aux demandes de votre management. Cela fonctionne également avec des sprints à durée variable mais vous devez connaître la durée de ces sprints à l’avance, ce qui complique l’estimation.
Pour cela, il faudra que les user stories de votre product backlog soient définies et que la complexité de chacune d’elle soit déterminée, grâce notamment à une ou plusieurs sessions de planning poker.
Il vous faudra également des indications sur votre vélocité, c’est-à-dire la valeur de complexité produite durant un sprint. L’idéal serait bien entendu d’avoir déroulé complètement un sprint afin de la mesurer. Si cela n’est pas possible, et que l’estimation demandée est à haut niveau, il est également possible de se baser sur un ancien projet. Dans ce dernier cas, la vélocité de l’équipe devra cependant être très proche.
On représente généralement la vélocité selon un burndown chart :
Vous connaissez la durée de chacun des sprints, le contenu de chacun de ces sprints et votre vélocité, il devient donc possible de satisfaire la demande du management en terme de date d’échéance.
Par définition, les méthodes agiles permettent de produire ce qui a le plus de valeur. Il se peut que le contenu de vos sprints évolue. Tant que la somme de complexité totale des sprints reste identique, vous pouvez ajouter des users stories en retirant une somme de complexité identique selon le principe des vases communicants. Les échéances restent les mêmes et l’entreprise produit la valeur la plus utile pour elle.
Sur l’illustration ci-dessous, représentant deux versions différentes du product backlog d’un projet, la somme des user stories représente une complexité de 66, permettant de finir à la même date malgré les modifications de contenu.
Vous pouvez donc fournir à votre management des objectifs de délais, lié aux dates de fin de vos sprints et ainsi satisfaire la demande en reporting.
User story vs phase et objectifs fonctionnels
Regardons maintenant de plus près la notion de phases et des objectifs fonctionnels associés.
L’approche Scrum offre des outils permettant de segmenter les objectifs fonctionnels d’un projet.
Il est possible de classer les user stories en thème ou en epic (épopée).
Les deux classifications comprennent plusieurs user stories. Le thème est plus souvent utilisé pour regrouper des user stories sur des sujets connexes. Chaque user story du thème peut cependant être traitée de façon indépendante. L’epic regroupe également plusieurs user stories mais sous-tend que l’intégralité de l’epic doit être produit pour obtenir les bénéfices envisagés.
Dans le cadre de la demande du management, qui souhaite découper un projet en phase ou par objectifs fonctionnels, ces 2 notions peuvent donc être adaptées.
De façon générale, on pourrait assimiler une epic à une phase du projet, dont on attend un ou plusieurs livrables qui peut servir à évaluer la possibilité de continuer le projet. De l’autre, on peut utiliser les thèmes pour représenter des objectifs fonctionnels liés.
Il s’agit là bien entendu d’une proposition et il convient d’adapter cette approche à vos besoins de management et de reporting.
Scrum : boîte à outils agile
Scrum semble donc équipé pour proposer des réponses aux demandes d’un management fonctionnant avec des approches prédictives. Il n’y a donc pas nécessairement besoin de chercher des solutions compliquées pour répondre à votre management.
Il y a plusieurs avantages à se reposer sur les outils « standards » de l’approche Scrum :
- Ils sont connus et maîtrisés par l’équipe
- Ils permettent de faciliter vos pilotages du projet grâce à une vision d’ensemble
- L’ensemble de l’entreprise peut les utiliser pour répondre au besoin de pilotage de l’organisation et ainsi faciliter l’adoption des approches agiles dans la hiérarchie
La prochaine fois que vous recevrez ce genre de demandes, ne soyez plus inquiet des informations que vous communiquez à vos managers : Repartez des outils agiles pour les adapter à leur contexte.
PIERRE-MARIE POLLET
Références:
(1) A decade of agile methodologies: Towards explaining agile software development (http://www.sciencedirect.com/science/article/pii/S0164121212000532)
(2) Agile: The World’s Most Popular Innovation Engine (https://www.forbes.com/sites/stevedenning/2015/07/23/the-worlds-most-popular-innovation-engine/#40d36a4d7c76)
