7 changements à intégrer pour un véritable projet agile!

Pour beaucoup de projets, d'organisations, voir d'individus, passer à l'agilité représente un changement majeur de paradigme et de culture. D'ailleurs, dans pas mal de cas, un projet n'a d'agile que le nom.

Mais quand l'agilité est parfaitement comprise par l'ensemble des parties prenantes et que la volonté d'être agile est réelle, les changements à intégrer ne sont pas à sous-estimer, tant nous avons tous été habitué à évoluer dans une même matrice: des projets découpés en séquences, des équipes travaillant en silo, un management focalisé sur le respect des plannings.

L'agile casse ce moule, et c'est parfois rock 'n' roll, car ça bouscule pas mal d'habitudes!

Voici 7 changements à intégrer dans la conduite des principales activités projets lorsque l'on veut véritablement parler d'agilité!

L'implication du métier

Dans une organisation projet classique, l'implication du métier ou de ses représentants est forte dans les premières phases du projet (recueil de besoin, spécification), puis dans les dernières phases (validation,  acceptation). Cela pose souvent des problèmes de disponibilité de la part des sachants et autres key people, tant ces phases peuvent être chronophages. En revanche, durant la plus grande partie du projet, c'est à dire la construction à proprement dite, il n'y a plus de son et plus d’image.

Dans une organisation projet agile, l'implication du métier ou de ses représentants est constante durant toute la durée du projet. Cela peut paraître contraignant, mais en réalité, la charge est lissée, et le mode agile ne requiert pas de longues phases de travaux "en chambre". Tout au plus des workshops réguliers, d'une heure à une demi journée. On démarre plus vite, avec moins d'inputs, et on se voit souvent. Le dialogue métier/technique doit être constant, et la réactivité optimale, tant pour l'affinage de la compréhension de inputs fonctionnels que pour la prise en compte du feedback récolté sur les incréments livrés.

Les spécifications fonctionnelles

Dans une organisation projet classique, les spécifications détaillées du périmètre sont élaborées au début, et une une seule fois. Il n'est pas rare, pour un projet de plusieurs années, d'y passer plus de 6 mois. Il s'agit alors d'un labeur surhumain, tant il faut imaginer dans le moindre détail un vaste système et présupposer de son utilisation, alors que tout n'est encore que virtuel. A l'issue, de volumineux documents font l'objet de revues et de validations. A partir de ce moment, le projet devient comme figé et focalisé sur la réalisation de ces "tables de la loi".

Dans une organisation projet agile, les spécifications détaillées du périmètre sont élaborées au fil de l'eau, avec une approche "just in time". Une phase d'initialisation est toujours nécessaire pour le projet, mais n'a pas pour objectif de décrire tout le comportement du futur système dans ses moindres détails. On se concentre sur l'architecture générale (Vision), et sur le découpage du futur système en fonctionnalités, dont la granularité est inversement proportionnelle à la priorité (Product Backlog). On rentre alors rapidement dans la réalisation d'un premier incrément, en affinant préalablement la compréhension d'un premier sous-ensemble de fonctionnalités. On pourrait penser que la quantité limitée de détails formalisés est un problème pour les développeurs. En réalité, cette limite volontaire fait qu'il se produit un petit miracle: les développeurs parlent aux analystes, et cet échange est fondamental à la réussite du projet.

Les tests du système

Dans une organisation projet classique, les tests sont élaborés après les spécifications, et en parallèle des développements. Ils sont exécutés à la sortie de la phase de développement, dans une étape qui (normalement) est planifiée en début de projet, et qui est souvent largement amputée avec les retards de développement (n'est-ce pas?). Durant cette étape, l'équipe de développement est sous pression car il faut corriger une montagne d'anomalie qui arrive chaque jour, tout en finalisant les développements (souvent en retard,  donc!).

Dans une organisation projet agile, les tests font partie des spécifications. Voir, ils les remplacent totalement avec l'approche de "test spécifiant", basée sur la création d'exemples d'usage valorisés venant enrichir chaque élément du Product Backlog. Ces tests doivent pouvoir être facilement automatisés et devenir des spécifications exécutables, même si ce n'est pas une obligation absolue. Automatisé ou pas, un cas de test est élaboré avant le développement de l'élément fonctionnel qu'il complète. Les tests fonctionnels alimentent donc l'activité de développement et contribuent à un meilleur alignement du développement avec le métier.

La validation du produit

Dans une organisation projet classique, la recette (UAT, VABF, ...) est véritablement le couperet final du projet. Dans le pire des cas, le nombre et/ou la criticité des anomalies remontées sont tellement importants que la mise en production est tout simplement repoussée. Et je ne parle pas des utilisateurs...on va dire "interpellés" par l’ergonomie qu'ils découvrent! A ce moment précis, la confiance accordée à l'équipe de réalisation se réduit comme peau de chagrin...

Dans une organisation projet agile, le cycle de validation se cale sur le cycle de développement, c'est à dire itératif et incrémentale. Chaque incrément réceptionné à l'issue chaque itération fait l'objet d'une acceptation partielle de la part du client. Ceci nécessite le respect d'une règle fondamentale d'un projet agile: chaque élément fonctionnel alimentant une itération doit pouvoir être complètement terminé dans une et une seule itération. Ensuite, les anomalies d'une recette N alimentent les travaux des itérations suivantes. On maintien généralement une phase de recette chapeau à la fin du projet, mais comme la plupart des anomalies ont déjà été levées et corrigées, il s'agit alors surtout de vérifier la bonne intégration du produit dans le SI et formaliser l'acceptation finale pour passer en production.

Les estimations

Dans une organisation projet classique, on estime des tâches en jour/homme, et ceci de manière prédictive. Le manager demande à chaque membre de son équipe (généralement individuellement) d'estimer son effort pour accomplir une certaine tâche. Dans le cas où la tâche est en avance, les délais sont généralement maintenus et on perd en productivité. Dans le cas où la tâche est en retard, la pression s'accentue et on perd généralement en qualité. Les tensions peuvent alors s'exacerber car il n'est pas rare de voir fuser les réprimandes pour ne pas savoir respecter ses engagements.

Dans une organisation projet agile, on estime des fonctionnalités en complexité relative, et ceci de manière empirique. Le terme fonctionnalité est à comprendre ici comme une valeur apportée au client, et non comme une simple caractéristique du système. Les estimations sont obtenues collectivement, via des ateliers de travail dédiés. Quelque soit l'unité d'estimation, cette unité représente toujours une taille, jamais un délais. Chaque élément est estimé comparativement aux autres. Plus le projet avance, plus la connaissance grandie, et plus les estimations sont fiables. L'apprentissage constant est une donnée du projet agile.

La planification et le suivi

Dans une organisation projet classique, on planifie des phases et des activités (architecture, spécification, développement, test) et ceci en début de projet. On suit ensuite la progression de chaque phase. Les indicateurs majeurs du projet sont l'état de chaque activité et la tendance de la trajectoire vers la date de fin prévue. On s'intéresse généralement peu à l'adéquation de ce qui est en construction avec à ce qui est réellement attendu, en tout cas pas avant la recette finale.

Dans une organisation projet agile, on planifie de la valeur métier (c'est à dire des éléments fonctionnels de différentes granularités apportant un intérêt tangible pour les utilisateurs), et ceci tout le temps. On suit la quantité de valeur déjà délivrée et acceptée par les utilisateurs, et la quantité de valeur restant à délivrer. Un indicateur important est la vélocité de l'équipe de réalisation, c'est à dire sa capacité à produire une certaine quantité de valeur dans un laps de temps donné, ce qui permet de planifier en permanence l’atterrissage du projet avec toujours plus de précision. Mais l'indicateur majeur reste le feedback obtenu à la livraison de chaque itération.

Le management du projet

Dans une organisation projet classique, un chef de projet définit le cadre d'organisation, affecte les tâches et contrôle leur progression. Son action s'inscrit généralement dans une organisation où la frontière entre ceux qui réalisent le produit (MOE) et ceux qui veulent le produit (MOA et/ou DSI) est forte. Généralement seul à porter l'engagement, le CP utilise le traditionnel point projet hebdomadaire pour relever les compteurs individuels (consommé / reste à faire), consolider le tout afin d'actualiser les indicateurs, et donner les directives pour la suite. Parfois, c'est le respect du processus qui compte plus que l’objet même de ce dernier: la réalisation d'une vraie application pour de vrais utilisateurs!

Dans une organisation projet agile, la notion même de chef de projet n'a plus vraiment de sens. Un manager agile est un facilitateur, qui travaille à maintenir en permanence un bon niveau de collaboration et de transparence entre toutes les parties prenantes, quotidiennement. Il entraîne l'équipe vers plus d'autonomie dans ses décisions et de confiance dans ses engagements. Il incite chacun à prendre part à l'amélioration continue, du projet comme du produit. Le "contrat agile", explicite ou non, nécessite aussi que l’engagement soit mieux réparti entre ceux qui réalisent et ceux qui veulent. Le rôle du "chef de projet agile" peut finalement se résumer à ça: détruire les obstacles qui peuvent freiner la bonne marche de l'équipe dans son engagement à produire de la valeur et de la qualité pour un client.