Story Agile #3 – Organisation de l’équipe

30 septembre, 2020

L’équipe, le moteur de Scrum

Comment passer d’une organisation MOA vs MOE à une équipe Scrum ? C’est là l’enjeu qui sera traité dans cet épisode… et vous allez voir que la transition n’est pas si évidente.

Dans l’épisode précédent, nous avons vu comment l’entreprise Ventout a réussi à définir la vision de son produit. La déclinaison plus opérationnelle du projet peut ainsi démarrer sereinement avec la constitution de l’équipe. Nous allons donc voir dans cet épisode, comment Basile, le Scrum Master et Coach Agile du cabinet Celencia, va remettre en cause bon nombre d’habitudes…

Habituellement, la société Ventout constituait son équipe projet de la manière suivante :

  • Un ou des experts de services métiers étaient détachés auprès de la direction informatique. L’expert métier endossait le rôle de chef projet MOA, principalement en charge des spécifications et des tests.
  • L’équipe de développement était composée selon la capacité à faire individuelle de chaque développeur. Afin de staffer au mieux chaque personne, ils pouvaient intervenir sur 2 ou 3 projets.

Ce fonctionnement était très confortable et simple pour tout le monde, cependant des difficultés apparaissaient fréquemment lors de la phase de tests. Ce qui pouvait conduire à certaines tensions ou incompréhensions et au dérapage des délais suite aux demandes d’ajustements. Afin de constituer une véritable équipe Agile, Basile a réuni Bernard (DSI) et Gustave (Marketing). Initialement, Bernard proposait  4 développeurs front, dont 1 a plein temps (Simon) et 3 selon leur plan de charges présentant les disponibilités sur toute la durée estimée du projet.

Basile est conscient que cette approche ne permet pas d’avoir une équipe stable et autonome. C’est à dire capable de travailler à 100%, sur l’ensemble du processus de souscription en ligne, indépendamment des périmètres applicatifs. Il va devoir faire preuve de pédagogie auprès de Bernard en lui précisant plusieurs points :

  • Le développement pressenti est essentiellement sur le site, mais le processus de souscription consomme les données du CRM (description, tarif…) et alimente des outils connexes de gestion. Si l’équipe travaille exclusivement sur le site, elle va être dépendante des autres équipes, qui ont leur priorité.
  • L’équipe va passer plus de temps à se synchroniser que produire. Il conseille fortement d’intégrer dans l’équipe une personne capable de paramétrer le CRM (développeur ou non) ; et d’avoir une compétence sur l’interfaçage des outils.
  • Si l’équipe n’est pas stable en termes de staffing, cela entrainera des problématiques de coordination et de priorisation, plus du temps de montée en compétence et une incapacité à déterminer la vélocité de l’équipe. Autrement dit, il ne sera pas possible de donner une estimation et un avancement fiables.

Ces explications ont convaincu Bernard qui est prêt à essayer cette approche. Ainsi, il alloue à l’équipe Benoit et Nicolas, deux développeurs non-experts mais mutli technos, ayant déjà déjà travaillé sur plusieurs briques du SI. Il propose que toute l’équipe soit formée au CRM par les experts pendant trois jours.

Il reste maintenant la question épineuse du choix du Product Owner ; sur laquelle Gustave a déjà son idée. Va-t-elle correspondre aux préconisations de Basile ? Gustave est persuadé que Barbara est la personne la mieux placée pour jouer le rôle de PO. Elle a participé à tous les ateliers de travail, dont la définition de la vision. C’est une experte du digital et elle connait bien les adhérences avec les autres applications du fait des projets déjà menés avec la DSI.

Basile ne remet pas en cause toutes les qualités de Barbara, qui sont un atout pour le projet. Néanmoins, il l’interroge sur sa capacité à travailler en mode Agile. Sa capacité à découper, et prioriser les fonctionnalités, sans avoir tout écrit, uniquement sur la base de la vision. Sa capacité à travailler au quotidien, au service des développeurs et non pas pousser une spécification ou un rapport de tests à la MOE. Cela demande un état d’esprit différent. Suite à ce questionnement, Gustave préfère nommer Juliette. Elle est certes moins experte que Barbara, mais elle a participé à tous les ateliers, possède un bon relationnel et une approche empirique des travaux. Le changement ne la déstabilise pas.

L’échange se conclut par une remarque de Bernard, tout à fait compréhensible mais révélatrice de la culture actuelle.

Bernard : “Nous avons défini l’équipe, mais nous avons oublié un acteur central, le chef de projet. Qui devons-nous nommer ?”

Basile :  “Bernard, nous avons déjà échangé sur ce point lorsque je vous ai présenté la méthode. Que souhaitez-vous ? Vous avez besoin d’être rassuré en mettant un chef qui vous produira des reportings. Je le ferai si vous avez besoin d’être rassuré ; mais l’équipe (dont le PO) sera là uniquement pour produire de la valeur et devra s’auto organiser. Ne vous inquiétez pas, vous pourrez voir l’avancement des travaux, toutes les 3 semaines, lors des démonstrations. Je pense que c’est le résultat le plus rassurant et concret pour tous.

Bernard peu convaincu de la mise en place ou non d’un chef de projet demande à ce que ce point soit statué lors du prochain comité de pilotage projet, sur la base d’un bilan après deux sprints.