Lorsque le cadre Scrum est introduit au sein d’une organisation ou d’une équipe, je constate souvent une incompréhension en ce qui concerne le rôle de chef de projet. Que devient-il dans une organisation Agile? A-t-il encore sa place?

En quelques semaines, plusieurs personnes m’ont posé ces questions. Lors d’une formation Professional Scrum Master II, j’ai eu l’occasion de participer à un exercice qui m’a permis de confirmer mon interprétation de manière très pratique.

L’exercice

Partons tout d’abord de cet exercice. Imaginez des fiches décrivant des responsabilités, par exemple : carnet de sprint (Sprint Backlog), croissance personnelle de l’équipe de développement (Personal growth of the Dev team), obstacles (Impediments), etc. Les participants doivent classer ces fiches par responsable, soit sous la responsabilité de l’équipe de développement, du Product Owner, du supérieur hiérarchique, du Scrum Master ou du chef de projet.

À la fin de l’exercice, le couperet est tombé : aucune responsabilité n’incombait au chef de projet. C’est donc devenu un rôle obsolète dans l’équipe Scrum. Quant à lui, le supérieur hiérarchique continue à avoir ses propres responsabilités qui sont cependant loin de la microgestion.

Comment se fait-il que le rôle de chef de projet devienne inutile? Il s’agit pourtant d’un des rôles clés de la gestion de projet classique…

La répartition

La réponse est finalement assez simple : ses responsabilités sont réparties aux différents rôles que comporte une équipe Scrum.

Il est difficile d’établir une liste des tâches qui incombent à un chef de projet, car elles dépendent très souvent de l’entreprise au sein de laquelle il évolue. J’énumère ici des généralités qui m’apparaissent être ce qu’on attend le plus fréquemment :

  • Écriture du cahier des charges
  • Définition des priorités
  • Répartition des tâches
  • Gestion de l’équipe
  • Évaluation des risques
  • S’assurer de la qualité des développements
  • Définir le processus de travail, la méthodologie
  • Fournir une solution technique
  • Communiquer et reporter à la hiérarchie et au client de façon régulière
  • Contrôler le budget, les délais et la portée du projet
  • Superviser la maintenance et l’évolution du projet

Cette liste est inspirée du guide des métiers.

Si nous reprenons ces responsabilités et que nous les comparons aux responsabilités des membres d’une équipe Scrum, nous constatons qu’elles sont réparties entre les différents rôles :

Tableau Guide des métiers

Lors d’une transformation Agile, certaines des responsabilités propres à un chef de projet vont être redéfinies. Par exemple, communiquer et reporter au client deviendra « collaborer avec le client. » Cela pourra se faire entre autres lors de la revue. Dans le même ordre d’idée, dans le tableau ci-dessus, j’ai tenté de mettre un seul responsable par tâche. Les sujets pourraient cependant être portés par plusieurs membres de l’équipe.

Rappelons qu’être Agile nous permet de nous poser les questions nécessaires (inspection) et de nous adapter pour trouver les meilleurs moyens de travailler ensemble pour livrer de la valeur. Cette valeur devrait être livrée au plus vite pour valider très tôt le résultat et atténuer le risque. Il s’agit donc bien d’un travail d’équipe pour la plupart de ces responsabilités.

La transition

Je constate souvent que les gens qui gravitent autour d’une équipe Scrum, mais ne connaissent pas bien le cadre Scrum, s’adressent au PO ou au Scrum Master comme à un chef de projet.

Il y a cinq ans, je commençais chez un nouveau client en tant que Scrum Master alors que j’avais été cheffe de projet pendant plusieurs années. Je me suis assez naturellement tournée vers le « Scrum mastering » car j’avais déjà une prédilection pour l’humain et les processus de travail. Et pourtant, il m’était parfois difficile de me départir d’anciennes habitudes…

Je me souviens de réunions avec le département Infrastructure auxquelles j’ai assisté sans aucun autre membre de l’équipe, afin de coordonner les tâches liées à la création de serveurs et à l’ouverture de pare-feu (firewall)… Je vous mets au défi de trouver dans le guide Scrum une section qui indique que c’est l’une des responsabilités du Scrum Master. Avec le recul, je vois l’importance de laisser prendre la responsabilité de ces tâches à l’équipe de développement. Elle doit se sentir responsable de porter la solution technique dans son ensemble et non pas uniquement responsable du développement.

Lors d’une transition, il est parfois difficile pour d’anciens chefs de projet de trouver leur place dans une organisation Agile. Une de mes équipes a eu la chance d’être accompagnée par un coach Agile au démarrage du projet de transition. Lors d’un tour de table où nous nous présentions, quelqu’un a dit : « Avant j’étais chef de projet, maintenant… bien, je suis un simple développeur. » En une phrase, on ressentait le dépit et peut-être la tristesse de cette personne face à sa perte de statut.

Cela a nécessité un travail de longue haleine pour faire comprendre à cette personne qu’elle avait une valeur énorme au sein de l’équipe au-delà du titre qu’on voulait bien lui donner. Je me permets de citer mon collègue Tremeur Balbous qui vous propose de réinventer votre place au sein de l’entreprise. Il dit entre autres : « (…) je vous invite à reconsidérer la question dans une perspective différente; celle de l’exploration de la valeur que vous pouvez, en étant la personne que vous êtes, apporter à votre équipe ou à votre entreprise. »

Agilité à l’échelle

J’ai parfois entendu l’argument qu’un chef de projet pourrait être utile dans un contexte Agile où plusieurs équipes doivent travailler ensemble en coordination. Si tel est le cas, j’aurais plutôt tendance à conseiller un cadre comme Nexus qui permet de mettre en place une structure Agile à l’échelle, sans pour autant réinstaurer le rôle de chef de projet.

Conclusion

Pour conclure, je dirais que là où nous avions l’habitude d’avoir un homme-orchestre qui gérait toutes les facettes du projet, nous avons à présent une équipe solidairement responsable, composée de personnes avec des responsabilités partagées.

En répartissant les tâches, nous nous trouvons face à un pouvoir réparti où chaque personne dans l’équipe peut avoir son influence sur des décisions stratégiques liées au produit. D’ailleurs, nous parlons bien de produit dans Scrum et non de projet. Il paraît alors logique de ne pas trouver de place pour le chef de projet en tant que tel.

Il s’agira donc de revisiter à la fois les responsabilités et son propre engagement au sein de l’équipe pour s’adapter au mieux au nouvel état d’esprit apporté par l’Agilité.

Sabrina Ferlisi

Scrum Master et Coach Agile à Pyxis Suisse.

En 2014, après un master d’ingénieur en informatique et des années dans le développement logiciel et la gestion de projet, Sabrina tombe dans la marmite de l’Agilité en tant que Scrum Master et découvre un nouveau monde. Depuis, elle est passionnée par tout ce qui touche aux interactions humaines, à la communication et à l’amélioration continue.

Énergique, intuitive et organisée, elle met son savoir-faire au service des équipes et des organisations en donnant à la fois un cadre et de la souplesse aux environnements complexes.

Sabrina est également Scrum Trainer, et donne les formations Professional Scrum Master (formation certifiante de scrum.org).

Billet précédent

5 croyances qui prédisent le succès Agile d’une entreprise

Billet suivant

Le chef de projet est mort, vive le chef de projet !

2 Commentaires

  1. mediacox@hotmail.com'
    Damien
    27/04/2020 at 04:16 — Répondre

    J’entends bien tout le discours autour de la responsabilité des acteurs de l’équipe.
    Mais comme vous le dites, les responsabilités sont PARTAGEES. Mais les responsabilités partagées sont parfois dilluées, dissoutes … tout le monde fait tout, et à l’arrivée personne n’est plus responsable de rien.
    Ce qui m’interpelle, c’est le coté un peu “monde de Oui-Oui” … ça marche tant qu’il n’y a pas de grain de sable. Mais avec des responsabilités PARTAGEES, à la moindre divergence d’approche, on est bloqués car il n’y a plus d’arbitre légitime. On fait comment dans ce cas ?

  2. bernardjadot@hotmail.com'
    Bernard
    11/09/2020 at 04:43 — Répondre

    A mon humble avis : Comme souvent, c’est une question de point de vue.
    La question des responsabilités aura plusieurs réponses possibles en fonction des objectifs.
    Ais-je besoin de connaître le responsable pour lui “remonter les bretelles” si un grain de sable se présente ?
    Ou ais-je besoin de connaître le responsable pour gérer le problème qui pourrait être causé par le grain de sable ?
    A mon sens : l’arbitre est tout désigné.
    Il s’agit du Product Owner lorsque la question porte sur l’aspect fonctionnel du produit.
    Il s’agit de l’équipe dans les autres cas (avec intervention du scrum master si l’équipe ne peut se mettre d’accord)

    Je pense que les divergences d’approche constituent un élément essentiel dans le processus d’amélioration continue.
    Si on standardise tout et que tout le monde fonctionne de la même façon : Il faut être certain que la façon de faire est la bonne.
    Comment savoir si c’est la bonne ? En comparant avec d’autres … Mais si tout le monde fonctionne de la même façon … Comment comparer ?

    Après le Sprint Planning, nous avons systématiquement une réunion avec toute l’équipe. Les problématiques techniques sont exposées et chacun donne son point de vue.
    Ensuite, l’équipe sélectionne la meilleure approche exposée et s’y conforme pour le reste du sprint.
    D’une part, il y a un temps de réflexion pour exprimer son avis et chacun est invité à y prendre part.
    D’autre part, il y a un temps pour l’action pour appliquer ensemble ce qui a été décidé précédemment.
    Il faut absolument éviter de mélanger les deux.
    Les décisions prises et les actions qui en découlent sont évaluées en fin de sprint : C’est l’objet de la rétrospective.

    En vous souhaitant une très bonne journée

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

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