Qui porte le rôle de Chef de Projet en agile ?

Chef de projet de projet dans agile

Chef de projet en environnement agile

 

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 ? »

Culturellement et 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.

Dans les méthodes agiles et en particulier dans Scrum, le rôle de Chef de Projet n’est pas cité dans le Scrum Guide, le document de référence de la méthode.

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.

Projet VS Produit

▶ 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. »

 

▶ Enfin, c’est le produit qui fait vivre l’équipe (et plus largement l’entreprise), et non le projet.

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.

 

L’atelier sur le rôle du Chef de Projet

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 :

Chef de Projet VS Product Owner

Comparatif Chef de Projet VS Product Owner

 

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 ?

3 composantes produit

Les 3 composantes d’un produit numérique

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à :

Le positionnement du Chef de Projet

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.
Le chef de projet sait tout faire et il est partout en même temps !

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.

Chef de Projet : l’homme orchestre ?

 

Alors, le Chef de Projet serait-il un homme-orchestre, omnipotent et omniscient ?
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 :

Scrum : 3 rôles et responsabilités

 

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.

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 disparaît. La méthode Scrum apporte la clarification de son positionnement permettant à l’équipe agile de s’épanouir et d’atteindre une certaine émancipation, lui octroyant plus d’autonomie pour une meilleure 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 ?

……… ✂……………………………… ✂………………………………… ✂………

En quoi puis-je vous aider ?

Je suis Martial SEGURA, coach agile indépendant certifié SAFe.
Je développe le potentiel et les savoir-faire des équipes et des personnes. J’accompagne la transformation agile des organisations en m’appuyant sur les valeurs et principes agiles.
Contactez-moi pour en parler :
🚀 Linkedin : https://www.linkedin.com/in/martialsegura
📱 06 82 15 70 32
📧 martial.segura[at]oeildecoach.com

Laisser un commentaire :

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

close
Inscrivez-vous à la Newsletter !

Libère ton potentiel en recevant chaque nouvel article GRATUITEMENT !