Souvent lorsque je parle de l’approche agile auprès des personnes que j’accompagne, on me pose la question :
« Mais… Que devient le Chef de Projet dans les méthodes agiles ? »
Parle t-on de chef de projet dans la méthode agile ?
Traditionnellement, depuis des dizaines d’années, lorsqu’on initie un projet en entreprise, il est d’usage de commencer par nommer un Chef de Projet (CP). Celui-ci est identifié comme la pierre angulaire, indispensable à tous projets informatiques. Il signe donc le commencement de tout projet de développement informatique. Tout du moins, c’était avant !
D’où les questions que l’on peut légitimement se poser :
-
Est-ce que le rôle de Chef de Projet disparaît dans la méthode Scrum ? -
Est-ce que les fonctions et les responsabilités, assurées jusqu’à maintenant par le Chef de Projet, disparaissent-elles dans un environnement agile ? -
Comment les responsabilités sont-elles réparties entre les rôles d’une équipe Scrum et leur manager direct ?
Projet VS Produit
Avant de commencer de répondre aux questions posées ci-dessus, il me parait nécessaire d’expliquer les différences entre un projet et un produit, puisque dans les approches agiles nous parlons plus de produit que de projet.
▶ Un bon projet ne fait pas forcément un bon produit .
Un projet est souvent démarré pour répondre à un enjeu « métier » lié à un délai et un budget. Bien souvent (trop souvent ?) le projet est centré sur les processus et les ressources pour atteindre un objectif commun.
Le produit, lui, a pour vocation de créer de la valeur pour l’utilisateur. Ce dernier est LA raison d’être du produit : pas d’utilisateur, pas de produit !
▶ Un produit, c’est avant tout une réponse à un besoin ou à une attente des utilisateurs .
Pour bien concevoir un produit, il faut donc bien connaître ceux qui en auront l’usage et qui voudront l’acheter. Lorsque nous sommes des concepteurs, nous devons donc aller au-devant des utilisateurs pour mieux les cerner et faire émerger leurs usages et leurs besoins, et ainsi adapter la stratégie produit au plus près de leurs attentes.
« Le projet est un engagement de moyen alors que le produit est un engagement de résultat. »
▶
En effet, souvent on oublie cela alors qu’il est essentiel pour une équipe de comprendre cette causalité vitale pour la pérennité de leurs activités.
Le rôle du Chef de Projet décrit par les CP
Lors d’un atelier, nous avons commencé à déterminer les rôles et les responsabilités du Chef de Projet (CP) et du Product Owner (PO) afin de les comparer entre eux.
Voici la restitution des échanges :
Ensuite, avec Jean-Luc (coach agile également), nous avons demandé aux participants de déterminer dans quelle partie placerait-on le Chef de Projet : dans la partie « Fonctionnelle », la partie « Organisationnelle », la partie « Technique » ou à l’intersection de ces 2 ou 3 parties ?
A noter : Le jour de notre atelier, nous avions majoritairement des acteurs fonctionnels, appelés aussi « métiers » : des Product Owners (PO), des Business Analysts (BA) mais aussi un Chef de Projet MOA.
Voici le positionnement du Chef de Projet selon notre groupe de participants, ce jour-là :
En complément, je vous laisse apprécier quelques verbatims de nos échanges :
Selon ce groupe de personnes, le Chef de Projet est : « en interface avec le management » ; « il gère les plannings et les tâches », « il organise le projet dont les jalons », « il s’assure du suivi des coûts du périmètre et des délais », « il gère les ressources humaines et les congés», « il identifie et gère les risques », « il coordonne les équipes », « il facilite », « il fédère et aide l’adhésion de tous », « il distribue les tâches », ...
▶ Pour ce groupe d’acteurs fonctionnels, le chef de projet, est avant tout un acteur organisationnel.
Pourtant, en creusant, nous avons eu des réactions complémentaires : « le chef de projet est aussi un coordinateur technique avec les architectes » ; « le chef de projet alloue les ressources nécessaires s’il y a besoin d’une personne en plus sur le projet, par exemple » ; « c’est le chef de projet qui décide des assignations de tâches à l’équipe » ; « le chef de projet comprend les fonctionnalités du produit », « le chef de projet valide les congés », etc.
Le Chef de Projet (CP) est donc devenu en quelques minutes, bien plus qu’un acteur organisationnel.
Il est aussi un expert technique, un manager et un acteur fonctionnel.
Pour l’avoir vécu personnellement durant des années, le Chef de Projet est donc un mouton à 5 pattes, surchargé par les multiples activités qui lui incombe : la gestion de l’équipe, la planification, les compte-rendus, la rédaction des spécifications, la gestion des coûts, le suivi technique, la gestion des anomalies, … La liste est longue.
Lorsque j’ai verbalisé ce constat, l’un des participants m’a rétorqué : « si le chef de projet est en surcharge de travail, c’est à lui de s’organiser pour éviter cela (sic !) ».
La vie d’un Chef de Projet n’est pas un long fleuve tranquille ! 😅
Maintenant que vous connaissez mieux le contexte, revenons à nos questions :
> Est-ce que le rôle de Chef de Projet disparaît dans la méthode Scrum ?
La nature même de l’approche agile conduit à changer de paradigme et à remplacer la notion de projet par celle de produit. Par conséquent, le rôle de chef de projet, tel que connu dans l’approche « Cycle en V » disparaît. Cela semble logique : pas de projet, pas de Chef de Projet.
Les créateurs de Scrum fait le choix de clarifier les rôles et les responsabilités, au sein de l’équipe, en faisant émerger des acteurs sur chacun des axes produit : le fonctionnel, l’organisationnel et la technique, comme ci-dessous :
Dans une équipe Scrum, les fonctions du Chef de Projet, comme le planning, la coordination et le suivi, ont donc été répartis à l’ensemble de l’équipe Scrum.
D’où l’inquiétude de certains et ce questionnement : quel est donc l’avenir d’un Chef de Projet ?
Voici ma réponse :
Si un Chef de Projet veut intégrer aujourd’hui une équipe agile de type Scrum, je lui recommanderais donc de se positionner sur l’un de ces 3 axes en précisant sa préférence.
Je m’explique :
- Si son appétence est liée à la définition du produit à réaliser, je lui proposerais de devenir Product Owner.
- Si son appétence est liée à l’organisation et à la coordination des acteurs de l’équipe, je lui proposerais de devenir Scrum Master.
- Si son appétence est liée à la réalisation du produit, je lui proposerais de devenir leader technique, développeur ou même testeur.
En complément, je vous invite à lire cet article : http://www.oeildecoach.com/qui-fait-quoi-dans-une-equipe-scrum/
> Est-ce que les fonctions et les responsabilités, assurées jusqu’à maintenant par le Chef de Projet, disparaissent-elles dans un environnement agile ?
Pas du tout, bien au contraire !
L’approche agile est avant tout une approche empirique, basée sur l’expérience.
L’approche agile cherche à générer constamment un produit de haute qualité : utile, utilisable et désirable, en prenant en compte l’évolution des besoins des utilisateurs.
Souvent j’entends des personnes dire : « en agile, nous avançons à vue », « qu’il n’y a pas de roadmap », « qu’on fait et défait constamment les choses sans savoir où l’on va ».
Il s’agit là d’une mauvaise compréhension du modèle agile, ou d’une mauvaise application.
Que nous faisions du cycle en V ou des méthodes agiles, la vision produit, le cadrage produit et la planification sont des prérequis indispensables pour réaliser le meilleur produit, répondant aux attentes des utilisateurs.
Ces éléments sont le résultat de la collaboration active de toute l’équipe Scrum, idéalement formée au moment du cadrage produit.
Lors de la phase suivante, celle de la réalisation du produit, les fonctions et les responsabilités du Chef de Projet sont réparties entre tous.
Chacun des membres de l’équipe porte donc une partie des engagements du Chef de Projet, comme par exemple : le Scrum Master portera la partie organisationnelle et de coordination entre tous ; et, le Product Owner sera l’interlocuteur principal sur l’avancement produit et le budget.
> Comment les responsabilités sont-elles réparties entre les rôles d’une équipe Scrum et leur manager direct ?
Le Scrum Guide n’aborde pas le sujet du manager au sein d’une organisation agile.
Est-ce que cela signifie qu’il disparait ou qu’il doit disparaitre ? Je ne le crois pas.
Selon moi, le manager est un acteur organisationnel nécessaire, encore plus dans les grandes entreprises. Le manager a un statut de référent et de coordination traverse au sein de l’organisation, il doit s’assurer que la ou les équipes ont tous les moyens pour accomplir au mieux leur mission et leurs objectifs. Ces moyens peuvent être financiers, techniques, fonctionnels et relationnels. Il se place alors en tant que « Servant Leader » c’est-à-dire un acteur permanent au service des membres de son équipe.
Si l’équipe Scrum a un sujet nécessitant un arbitrage ou un problème divers et variés liés à son écosystème, j’invite la ou les équipe(s) Scrum à en référer auprès de leur manager afin d’être aidé par ce dernier pour trouver ensemble la solution la plus adéquate.
Mon Oeil de Coach
En conclusion, comme nous avons pu le constater dans la démonstration ci-dessus, le rôle et les responsabilités du Chef de Projet persiste dans un environnement agile, même si cet acteur tel qu’on le connait historiquement disparaît. La méthode Scrum apporte la clarification nécessaire permettant à l’équipe opérationnelle de s’épanouir et d’atteindre une certaine émancipation, en lui octroyant plus d’autonomie et une réelle auto-organisation pour remplir sa mission d’exécution du produit.
Et vous, quel est votre avis sur le sujet ?
Vous avez aimé cet article ?
Laissez un commentaire positif et partagez-le sur les réseaux sociaux !
Je remercie Jean-Luc THELL et Géraldine SUDRES pour leur contribution à cet article.
Source image : Pexels
……… ✂……………………………… ✂………………………………… ✂………
Envie d’aller plus loin ?
- Qui fait qui dans une équipe Scrum ?
- Culture Projet VS Culture Produit de Stéphanie Cart
- Scrum guide de Jeff Sutherland et Ken Schwaber
- [LIVRE] Conduite de projets agiles de Julien PLEE
- [LIVRE] Scrum pour les nuls de Mark C. LAYTON
- Le top des ressources agiles de l’Oeil de Coach
……… ✂……………………………… ✂………………………………… ✂………
Très bel article je trouve. Merci pour les réponses plutôt claires.
Merci Romuald ! Cela fait toujours plaisir ce type de commentaire. 😉
Bonsoir Martial,
Ton site et tes articles sont extrêmement intéressants. Je découvre cette évolution de certains métiers de l’informatique.
J’ai quelques questions: la méthode agile avait été développée à mon sens pour lisser dans le temps l’utilisation d’équipes de développement et de consultants, empêcher la dispersion de toutes ces compétences à la fin d’un projet.
En revanche, cette « gestion » d’un produit par un trio où les 3 « leaders » sont placés à égalité n’a pas l’air si naturelle, surtout dans les entreprises où il y a fort turn-over récurrent. Sinon, pourquoi faire appel à un Coach Agile (métier qui donne envie). Est-ce juste rééquilibrer l’ancien trio CP AMOA-Client utilisateur-Chef des développeurs où le CP AMOA était un peu le leader naturel.
Qu’en penses-tu?
Bien cordialement,
Hélène
Salut Hélène,
Merci pour tes compliments. Je fais tout mon possible pour apporter le plus de valeur. Je suis tjs heureux d’apprendre que cela plait.
Pour moi, l’agilité est une nécessité moderne. Nous ne pourrons plus revenir en arrière, en tant que méthode. L’ancienne est bien trop inadapté aux enjeux actuels.
Pour répondre à tes interrogations :
1/ L’approche agile n’a pas été créé pour lisser le travail dans le temps mais bel et bien à répondre à de nouveaux enjeux : besoin de réactivité face à un monde qui change, faciliter l’adaptation, délivrer plus vite même si c’est moins, mieux contrôler les budget, etc.
Une gestion de la réalisation par « petits lots » est bien plus facile à traiter que des « gros lots », et c’est surtout moins risqué.
2/ L’apport du modèle Scrum a mis en exergue la nécessité d’avoir un trio : fonctionnel + tech + orga. Ce triangle marche parfaitement tant les acteurs se complètent. On retrouve ce triangle à tous les niveaux de SAFe. Le turn over est un poison pour les équipes, agile ou pas, car il déstabilise l’équipe sur plusieurs mois : nécessité d’expliquer les processus et les règles du jeu de l’équipe, montée en compétence sur les outils / fonctionnel, etc. Une société cliente peu mature ne comprend pas cela.
Est-ce que cela répond à tes questions ?
Bien à toi,
Martial
Il semblerait que le rôle de Scrum master soit souvent une casquette de plus ajoutée au rôle de chef de projet 🙂
Oui, tu as raison Philippe, je l’ai aussi constaté chez plusieurs organisations. J’ai même vu un chef de projet et un Scrum Master dans une même équipe, causant de nombreux dysfonctionnements. C’est dire ! 🙂
Le mélange des genres est dû à une méconnaissance du modèle Scrum qu’il faut corriger au plus vite.
Pour de tels problèmes, l’intervention d’un coach agile est utile pour expliquer et améliorer le fonctionnement.
Super article, qui replace bien le rôle du chef de projet, bien souvent perdu dans une organisation projet que se veut agile.
Merci Rémi,
Nous sommes heureux que cet article vous ait plu, et surtout qu’il ait été utile.