Utiliser un diagramme de Gantt en gestion de projet agile : est-ce possible ?

Qu’est-ce qu’un diagramme de Gantt et pourquoi pose-t-il question en agilité ?

Pour être honnête, ce n’est pas tant l’outil qui pose problème, mais la manière dont il est souvent utilisé par les chefs de projet. La principale erreur consiste à croire que le diagramme de Gantt reflète parfaitement la réalité. Pourtant, ce n’est pas le cas. Ce malentendu ne vient pas forcément des chefs de projet eux-mêmes, mais souvent des lecteurs du diagramme : le management, les clients, ou d’autres parties prenantes qui, séduits par sa simplicité visuelle, imaginent que tout se passera comme prévu.

Les limites du diagramme de Gantt

Les problèmes les plus courants liés à l’utilisation classique du diagramme de Gantt sont bien connus :

• Dates de début et de fin faussement précises
• Estimations souvent biaisées
• Mise à jour lourde et chronophage
• Attentes irréalistes des clients et du management

Certes, les choses commencent toujours avant la date fixée, se terminent toujours après et la mise à jour des progrès est aussi folle que la barre de progression Windows. Cependant, cette représentation est simple à comprendre : les équipes sont condamnées à mettre à jour le moindre détail, la moindre dépendance ou tâche.

Et ce n’est pas le pire. Non seulement la représentation de l’état d’avancement du travail est erronée et génère une quantité folle de paperasse, mais la partie projection et roadmap est également mauvaise. Pourquoi cela ?

Ces limites tiennent au fonctionnement même du diagramme : pour chaque élément, il faut fixer une date de début, une date de fin et une estimation de charge. Or, dans la réalité, ces données sont presque toujours approximatives. Malgré cela, le diagramme donne l’illusion d’un engagement précis, alors même que les aléas du terrain rendent ces prévisions très fragiles. En plus, la mise à jour du planning peut rapidement devenir une charge de travail inutilement lourde pour les équipes.

Comment l’Agilité a changé la manière de piloter les projets

Les méthodologies de gestion de projet agiles sont justement apparues en partie pour combattre la bureaucratie et le micro-management du développement de produit, mais aussi afin de se focaliser sur la valeur livrée :

• Une estimation approximative de la durée des tâches est faite, afin de mettre fin aux discussions interminables pour savoir si la tâche que vous allez réaliser dans 6 mois nécessitera vraiment une heure ou deux.
• L’accent est mis sur les User Stories (et non sur les tâches) pour livrer un logiciel complètement fonctionnel.
• Un suivi des métriques est réalisé, ce qui permet de se concentrer sur la valeur livrée au client plutôt que sur la simple complétion des tâches (comme les graphiques Burn-up des User Stories).

C’est pourquoi désormais, nous avons un backlog agile, organisé autour de la valeur livrée, avec un haut niveau d’estimation (ou pas d’estimation du tout). Les clients sont contents parce que ce qui est important est livré en priorité. L’équipe produit est satisfaite car elle n’est plus obligée de maintenir des indicateurs qui n’ont aucune valeur pour elle. Enfin, le manager de produit est content également parce que les nouveaux indicateurs se concentrent sur ce qui compte vraiment : la capacité des équipes à exécuter (graphiques burn-down, diagramme de vélocité) et ce qui est livré au client (graphiques burn-up).

Est-ce que tout le monde est content ?

Non ! Le top management ne l’est pas. Parce qu’il perd un précieux outil, envers lequel il pouvait se montrer compréhensif (même si celui-ci était un peu cassé). Il ne comprend pas ces nouveaux outils et a perdu sa capacité à prévoir « par lui-même ».

Car le Gantt apporte une réponse simple à des questions fréquentes des parties prenantes :

• Quelle est la direction du projet ?
• Où en est-on aujourd’hui ?
• Quels sont les jalons majeurs ?
• Y a-t-il des risques ou des dépendances critiques ?

Peut-on rendre les gens heureux ?

Cette nouvelle approche satisfait souvent les équipes produit, qui se libèrent de la gestion d’indicateurs peu utiles, et les clients, qui reçoivent plus vite ce qui a de la valeur pour eux. Mais côté direction, le changement est parfois mal vécu. Car les outils agiles, malgré leurs qualités, ne remplacent pas complètement la visibilité offerte par un diagramme de Gantt.

En effet, ce dernier répond à des questions simples et légitimes :
Dans quelle direction va le projet ? Où en est-on aujourd’hui ? Quels sont les jalons ? Y a-t-il des risques à anticiper ?

Qu’en est-il de la roadmap agile ?

La bonne nouvelle est que vous pouvez réunir toutes ces informations sous la forme d’un graphique de Gantt, sans compromettre vos valeurs et pratiques agiles. Résumons ce que vous pouvez faire avec Tuleap pour rendre un diagramme de Gantt agile :

• Premièrement, les dates : une date de début et une date de fin, afin de pouvoir dessiner les barres,
• Ensuite, une idée de la progression : la barre intérieure pour indiquer la complétion des tâches,
• Enfin, en option, les dépendances (est-ce que quelque chose doit être fait impérativement avant une autre ?) et les enfants (la manière dont les choses doivent être décomposées).

Comment créer un diagramme de Gantt pour la gestion de projet agile ?

Devinez quoi ? Nous avons déjà tout ce qu’il faut dans notre backlog agile habituel !

• Les dates : une User Story n’a pas de date en soi, mais elle est planifiée dans un Sprint ou dans une Release, qui eux possèdent une date. Récupérons donc cette information pour dessiner les barres.
• Progression : en fonction des habitudes de l’équipe, vous avez déjà une idée des progrès réalisés. Par exemple, certaines équipes suivent l’évolution de « l’effort restant ». C’est ce qui est utilisé pour dessiner les graphiques burn-down. Si l’effort restant est comparé à l’effort initial, il est possible d’en déduire un pourcentage de progrès. Par ailleurs, si l’équipe n’a pas fait d’estimation initiale pour les Stories, il est toujours possible d’obtenir un ratio en comparant le nombre de tâches accomplies sur le nombre de tâches total.
• Dépendances : elles peuvent être signalées par un lien entre deux Stories. Mais dans le monde agile, nous essayons de classer les éléments par ordre de priorité (ce qui est prioritaire est fait en premier).

Il existe un article dédié si vous souhaitez apprendre comment construire une roadmap agile pour vos projets.

Scrum + Gantt : un exemple concret

Dans un projet Scrum, les Epics sont généralement planifiés au niveau des Releases, tandis que les Stories le sont à l’échelle des Sprints. On ne sait pas toujours exactement quel jour une tâche sera réalisée et ce n’est pas un problème. Ce qui compte, c’est que la Story soit terminée à temps.

Le Gantt n’est pas là pour micromanager chaque étape, mais pour offrir une lecture synthétique des échéances globales. Et c’est justement en ne cherchant pas à trop le détailler qu’il reste compatible avec l’agilité.

Quelles sont les erreurs à éviter avec un diagramme de Gantt en agile ?

Le diagramme de Gantt devient problématique en contexte agile lorsqu’il est mal utilisé. Voici les principales dérives à éviter :

• Croire qu’il reflète la réalité : dans un Gantt classique, tout semble sous contrôle, alors qu’en pratique, les imprévus décalent rapidement les tâches.
• Planifier à outrance : détailler chaque tâche à la journée ou à l’heure alimente le micro-management, totalement contraire à Scrum.
• Se baser sur des estimations précises : les dates reposent sur des hypothèses souvent fausses, ce qui donne un planning trompeur.
• Se focaliser sur les tâches plutôt que sur la valeur : l’agilité privilégie les User Stories et la valeur livrée, pas la complétion d’unités de travail isolées.

En clair, le Gantt classique est trop rigide pour l’agilité. Mais adapté, il peut devenir un outil complémentaire et pertinent.

Alors, est-ce qu’un diagramme de Gantt peut être agile ?

La réponse est bien sûr oui, tant que sa représentation n’influence pas la façon dont l’équipe agile travaille. La frontière est mince et c’est là que les outils peuvent vraiment protéger l’équipe. Avec Tuleap, cette frontière est tracée avec l’outil Roadmap qui est une représentation de ce qui se passe dans le backlog du produit. Les équipes continuent à travailler en suivant les pratiques agiles, leur management peut avoir une représentation qu’il comprend mais sans la tentation du micro-management. Le meilleur des deux mondes réuni !

L’essentiel à retenir

Le diagramme de Gantt, bien qu’associé à la gestion de projet classique, peut parfaitement s’intégrer dans une démarche agile à condition d’être utilisé comme outil de visualisation, et non de rigidification du planning.

• Tuleap propose un module Gantt intégré et personnalisable.
• Permet de visualiser les jalons, dépendances et livrables.
• Compatible avec les approches hybrides (Scrum + cycle en V).
• Doit être flexible : le Gantt ne remplace pas le backlog.
• Idéal pour les équipes pluridisciplinaires ou multisites.