Pour illustrer le project management dans un contexte agile, je vous propose d’utiliser Scrum comme framework de référence. Très largement déployé au sein des entreprises, il est a priori assez représentatif et a l’avantage de définir des rôles à ce niveau d’équipe.
Lorsqu’une nouvelle équipe Scrum est créée, une question que l’on peut entendre est : “Que devient le chef de projet ?”. C’est une question pertinente, parce que si l’on regarde le Scrum Guide, le chef de projet n’est pas mentionné. Tout d’abord, voici ce qui est écrit concernant la Scrum Team :
La Scrum Team se compose d’un Scrum Master, d’un Product Owner et de Developers. Il n’y a pas d’équipe dans l’équipe ni de hiérarchies. Il s’agit d’une seule et même unité stable, composée de professionnels focalisés sur un seul objectif à la fois, l’Objectif de Produit.
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf
Il n’y a donc pas de hiérarchie, pas de manager, pas de chef de projet. En réalité, la gestion de projet est répartie sur les 3 rôles :
- Le Product Owner : porteur de la vision du produit, il décide et communique sur les priorités de l’équipe
- Le Scrum Master : servant leader au service des développeurs, du PO et de l’organisation. Il est focalisé sur l’amélioration continue, la levée des obstacles et la bonne appropriation / utilisation des pratiques Scrum.
- Les développeurs : ensemble de personnes ayant ensemble toutes les compétences nécessaires à la construction du produit. Ils s’accordent sur le plan de sprint, se focalisent sur l’objectif du sprint et sur la qualité de leur production.
Etudions alors les responsabilités d’un chef de projet, tel que défini sur le site Cegos (institut de formation professionnelle français).
Sous la responsabilité d’un directeur de projet, le CDP englobe plusieurs rôles dans l’entreprise : concepteur, contrôleur, coach, expert et orateur. Il est le garant de la réussite d’un projet.
Ces capacités de conception, contrôle, coaching, expertise et aisance oratoire sont toutes bien évidemment nécessaires, y compris dans un contexte agile. Mais réparties sur les membres de l’équipe : le PO participe à la conception fonctionnelle et les développeurs à la conception technique (bien qu’il n’y ait aucune contre-indication à ce que tout le monde face un peu de chaque). Le PO contrôle les fonctionnalités développées pendant le sprint et les développeurs font du code review avant de faire tester leur feature, …
Notons ici la notion de garantie de réussite du projet. Dans une équipe Scrum, la réussite du “projet” est bien sous la responsabilité de l’équipe entière. La définition de réussite est définie juste après.
Dès lors que le projet, le budget ainsi que le calendrier sont définis, le chef de projet entre en action. Il doit gérer et contrôler le travail d’une manière efficace. Le CDP est tenu pour responsable dans le cas où le contenu du projet n’est pas bien défini ou que le projet n’est pas bien planifié. Son rôle est donc déterminant au sein de l’entreprise.
C’est là que les visions du monde divergent à 180°. D’après cette définition, le chef de projet n’a son mot à dire ni sur le contenu, ni sur les délais, ni sur le budget. Mais il est malgré tout tenu responsable du succès du projet. La réussite revient donc à réaliser la prophétie du management et des avant-ventes.
L’agilité propose une vision différente et part d’un postulat très simple : il n’est pas possible de prédire le futur. En effet, nous (équipe de développement) ne pouvons pas garantir que
– Notre client a décrit suffisamment ses besoins
– Notre client ne risque pas de changer d’avis
– Le marché n’obligera pas notre client à vouloir autre chose que ce qui a été commandé
– Nous avons bien compris les besoins du client
– Et bien d’autres choses …
Cependant nous, agilistes, partons du principe que nous ferons notre maximum pour satisfaire notre client, dans le respect du budget imparti (ou même avant d’avoir tout consommé). En effet, rien ne dit que toutes les fonctionnalités demandées ont toutes la même valeur et qu’elles seront toutes utilisées par les utilisateurs. Charge au PO de prioriser les fonctionnalités qui apportent le plus de valeur aux utilisateurs et, peut-être, que le client décidera de lui même d’arrêter de développer de nouvelles fonctionnalités avec moins de valeur ajoutée.
Pour conclure, non seulement la gestion de projet dans un contexte agile ne responsabilise pas une seule personne dans la réussite mais bien un collectif, et en plus la séparation des rôles incite à une meilleure gouvernance. De plus, si le chef de projet traditionnel a pour objectif de respecter coûts-qualité-délais-périmètre, l’équipe agile a pour objectif la satisfaction du client, dans le respect des individus qui la composent.
Le chef de projet, en fonction de ses compétences et ce ses appétences, pourra donc facilement trouver sa place dans cette nouvelle organisation : plutôt côté product ownership s’il a une fibre business, plutôt côté Scrum Master s’il aime faciliter, et plutôt développeur s’il a une fibre technique.