Agilité : quel rôle pour quelle fonction ? – Episode 2

Projet agile : être concerné ou impliqué ?

Avant de présenter ce que recouvre les rôles de Product Owner, Scrum Master et Coach Agile, il est important de rappeler que l’équipe agile est constituée de personnes impliquées dans le projet. Mais qu’entend-on par impliquées ?

Pour illustrer ce point, voici la petite histoire de Ginette « la poule » et Dédé « le cochon ».

Un jour, Ginette la poule va voir Dédé le cochon :

– Hey Dédé, j’ai une idée de business ensemble, je pense que nous devrions ouvrir un restaurant.
– Je ne sais pas, répond Dédé le cochon. Comment comptes-tu l’appeler ?
– Des œufs et du jambon, lance la poule ! Et nous serions engagés à 50/50 dans l’affaire, ça te dit ?
– Ah non merci, lui rétorque vivement le cochon après réflexion ! Moi, je serais impliqué alors que toi tu serais seulement concernée !

Dans cette fable, les deux acteurs jouent un rôle déterminant dans la réalisation de leur menu mais ils n’interviennent pas de la même façon. L’engagement est fondamentalement différent : la poule est « concernée » en fournissant les œufs alors que le cochon est « impliqué » dans le projet en mettant sa jambe sur le billot, sa participation est donc autrement plus engageante.

Donc en cas de prise de décision, le poids de la décision n’aura pas le même impact sur le cochon et sur la poule !

Cette petite fable sert à illustrer le fait que lors la constitution d’une équipe agile, il faut partir du principe qu’elle soit constituée de « cochons », c’est-à-dire de personnes impliquées dans le projet.

Evolution des rôles « standards » vers des rôles « agile »

Dans les entreprises qui choisissent de se tourner vers des approches agiles, les ressources présentes sont souvent des chefs de projets : la question que se posent les entreprises est « comment les faire évoluer sur des rôles agiles, notamment des postes de PO et de Scrum master ? ».

La différence significative et fondamentale entre un chef de projet et un scrum master par exemple, c’est que le chef de projet pilote l’activité d’une équipe, alors que le Scrum master délègue le pilotage de l’activité à son équipe (autonomie et responsabilisation) et se concentre quant à lui sur les membres de l’équipe pour les aider à constamment s’améliorer.

Certains chefs de projets se sont vus nommés PO au sein de leur organisation, sans formation préalable, ni accompagnement dans cette nouvelle posture. De ce fait, des appellations ou rôles ont émergés au sein des organisations, pour répondre à des besoins spécifiques.

Or le PO a un rôle stratégique, c’est « le nerf de la guerre », il oriente le produit, on attend de lui qu’il soit le garant de la production de valeur et donc d’une part du ROI de l’entreprise. A ce titre, on lui délègue une responsabilité et il doit donc être légitime pour réaliser ce ROI sur un périmètre défini.

C’est un rôle difficile à faire émerger dans l’entreprise, notamment dans les entreprises qui se lancent dans l’agilité : soit l’entreprise nomme un PO de manière un peu arbitraire au sein de ses collaborateurs sans vraiment qu’il connaisse son rôle, soit elle fait appel à un PO externe qui va orienter ce rôle dans l’entreprise, car l’entreprise n’étant pas mature, elle n’est pas en capacité de lui dire ce qu’on attend de lui !

Au fil du temps, le rôle de scrum master a perdu de sa superbe, on constate aujourd’hui qu’il n’est souvent plus dédié à une seule équipe mais affecté à plusieurs projets. Une des raisons repose sur la difficulté des entreprises à saisir la valeur qu’il apporte, ils est souvent considéré comme non productif et donc vu comme un centre de coût. Il faut à la fois une certaine maturité du Scrum Master et de l’entreprise pour observer combien ce rôle est à valeur ajoutée.

Lever les limites perçues par la mise en place de rôles « agiles »

Quand on parle de ses rôles il est donc important de regarder le niveau de maturité, en terme d’agilité, des entreprises qui les emploient. Si c’est une entreprise qui amorce sa transition vers l’agilité, il est préférable, de mon point de vue, de faire venir des personnes externes qui vont apporter leurs expériences pour produire tout en gérant la montée en compétences des équipes en interne.

Pour les entreprises plus matures, la question qui se pose est différente et parle plus du management de ces rôles : comment les orienter, comment aider au mélange entre ces arrivants et la culture agile déjà en place ? L’entreprise se doit d’intégrer cette personne et de se référer à son expérience en disant « nous dans notre culture d’entreprise, voilà comment nous voyons et comment nous vivons l’agilité ».

Un autre point important, surtout pour les entreprises qui amorcent leur mutation, est d’identifier en quoi ces rôles vont être transformants pour l’entreprise et le management notamment.  En effet, lorsque ces rôles sont mis en place dans les entreprises, les managers se sentent souvent remis en cause dans leur fonction et ils sont nombreux à se poser la question « quel est mon rôle dorénavant et à quoi vais-je servir  dans une équipe qui s’auto-organise ? ».

Il faut avoir en tête que le lancement d’un projet avec une équipe agile, va forcément avoir un impact sur l’organisation et le management de l’entreprise. La question de l’apport managérial dans la chaine de valeur est un vrai sujet à adresser pour maintenir la cohésion sociale lors du déploiement de l’agilité.

C’est avec toutes ces contraintes que l’entreprise doit évoluer. Se faire accompagner pour bien instaurer l’agilité est une étape importante pour éviter que sa mise en place, plutôt qu’être source de performance ne soit synonyme d’échec. N’hésitez pas à consulter notre page Agilité et à nous contacter pour y voir plus clair.