Skip to main content

Vers une équipe Scrum efficace – L’engagement des Parties Prenantes

 Sabrina Ferlisi

Afin d’avoir une équipe Scrum efficace, l’engagement des parties prenantes est crucial. Les défis comprennent l’alignement des objectifs, la collecte de feedbacks, la collaboration et le focus sur la valeur. Les problèmes actuels incluent un objectif de produit trop rigide et lointain, des difficultés à obtenir des feedbacks pertinents lors des revues de sprint, et un manque de focus sur la valeur due à l’absence de mises en production régulières.

Cette série d’articles aborde les facteurs qui sont déterminants pour qu’une équipe Agile soit efficace selon une étude scientifique. Le premier article abordait l’axe de l’Amélioration continue, le deuxième parlait de l’Autonomie de l’équipe, le troisième du Soutien du management, le quatrième des mises en production et enfin le cinquième la satisfaction interne et externe de l’équipe. À chaque fois, pour ancrer ces concepts dans des éléments tangibles, je les présente dans le contexte d’une équipe Scrum qui développe un produit informatique et que j’accompagne en tant que Scrum Master.

Dans cette dernière partie de notre série d’articles, nous abordons l’aspect crucial de l’engagement des parties prenantes qui passent souvent par avoir des objectifs communs, la collaboration, la valeur et la collecte de feedback.

Des objectifs communs ?

Au sein de notre équipe, l’Objectif de Sprint est discuté à chaque Sprint Planning. Souvent le Product Owner vient avec une proposition d’objectif qui sera affinée avec toute l’équipe. L’atteinte de l’Objectif de Sprint est généralement satisfaisante et cet objectif nous permet de communiquer clairement ce que nous cherchons à atteindre à nos parties prenantes, lors de chaque Revue de Sprint.

Cependant, lorsque nous abordons une vision à plus long terme, l’Objectif de Produit, dans le contexte du programme dans lequel nous sommes enrôlés, nous nous heurtons à une réalité quelque peu frustrante. En théorie, un Objectif de Produit est conçu pour être dynamique, adaptatif, et, dans ma vision, il se situe typiquement dans une fenêtre temporelle de 3 à 6 mois. Cette temporalité permet une réactivité face aux besoins changeants des utilisateurs et aux évolutions du marché. Cependant, dans notre cas, l’Objectif de Produit existant depuis plus d’un an s’écarte significativement de cette philosophie. Il est devenu un symbole de nos difficultés à intégrer pleinement l’agilité dans notre processus du programme.

Ce qui accentue le décalage avec la dynamique recherchée, ce n’est pas seulement l’ancienneté de cet objectif, mais aussi la manière dont il a été défini. Bien que notre Product Owner ait joué un rôle dans l’écriture de cet objectif, son travail s’est basé sur un cahier des charges préétabli, transmis dès le démarrage du projet. Cette démarche reflète une approche plus traditionnelle et moins flexible que ce que l’agilité prône. Au lieu d’un processus itératif, caractérisé par une exploration continue et une adaptation aux feedbacks des utilisateurs, nous nous trouvons dans une situation où le cap a été fixé sans la marge de manœuvre nécessaire pour naviguer et ajuster notre trajectoire en fonction des découvertes et des apprentissages en cours de route.

Où se situe le problème ? Est-ce la stratégie business qui est trop éclatée ? Est-ce la stratégie produit qui est fixée sur une période trop longue ? Est-ce la validation du produit qui est inexistante ? Un peu (beaucoup) de tout ?

La divergence des priorités au sein de l’entreprise est visible. Le Product Owner me rappelait que notre équipe Scrum est sensée travailler entre 5 à 8 semaines pendant cette année sur d’autres sujets que le programme, sans compter les impondérables de la vie (demandes de dernière minute, mise à jour des plateformes, bugs, etc.).

Ceci a un impact évident sur le focus, mais surtout sur les objectifs qui ne sont pas les mêmes en fonction des parties prenantes. Si on prend un pas de recul et qu’on regarde l’organisation dans sa globalité, l’objectif général semble clair et a été formulé sous la forme « Devenir n°1 dans notre domaine ». Pourtant, dans ce cadre, chaque équipe a son projet qui est prioritaire de son point de vue et qui cherche à le faire avancer coûte que coûte. Chaque équipe a son manager. Chaque projet a son chef de projet… Et je nous considère encore chanceux : notre équipe Scrum n’est pas une équipe transverse (comme par exemple une équipe fournissant des API) !

La Collecte de Feedbacks et la Collaboration

Nos revues de sprint sont des moments que j’estime en tant que Scrum Master comme clés pour la collecte de feedbacks auprès de nos parties prenantes. L’organisation de ces revues est adaptée à chaque sprint, avec des invités variant en fonction des développements réalisés.

Cependant, faire en sorte que les bonnes personnes se déplacent et qu’elles participent activement reste un défi. Souvent, le Product Owner se retrouve à devoir organiser d’autres meetings sur des sujets qui pourraient être discutées lors de la Revue. Bien que nous soyons conscients de ce point et que nous cherchions activement une « formule magique » pour l’améliorer, le chemin vers une Revue de Sprint efficace et collaborative reste à tracer.

La relation du Product Owner et de l’équipe en général avec les parties prenantes se passent bien d’un point de vue relationnel et collaboration. Bien qu’il existe des échanges constructifs entre les parties prenantes internes, le PO et les business analystes, ces discussions portent généralement sur des éléments déjà décidés en amont, réduisant ainsi la marge pour de véritables optimisations que ce soit en terme de périmètre ou en terme de priorisation. La séparation dans le temps entre la décision et l’exécution limite notre capacité à livrer de la valeur de manière optimale.

Focus sur la Valeur

Ici réside notre plus grand défi : le focus sur la valeur. Cette pierre angulaire de l’agilité se trouve malheureusement érodé par une série de contraintes systémiques au sein de notre projet. La convergence de plusieurs facteurs, déjà évoqués dans cet article et les précédents, forme un véritable obstacle à notre capacité de concentrer nos efforts sur ce qui importe vraiment : la création de valeur pour l’utilisateur final.

En premier lieu, l’absence de mises en production régulières entrave gravement notre agilité, nous n’avons pas procédé à une mise en production depuis un an. Cette lacune nous prive de l’opportunité d’itérer rapidement sur le produit basé sur les retours concrets des utilisateurs. Sans cette boucle de feedback vital, nous naviguons à vue, sans pouvoir confirmer si les fonctionnalités développées répondent effectivement aux besoins et attentes des utilisateurs.

De plus, notre organisation en mode projet, avec un périmètre fixe, contraste fortement avec l’approche produit prônée par l’agilité, où l’adaptabilité et la réactivité face aux changements sont clés. Cette rigidité structurelle nous enferme dans un cadre où les décisions sont prises bien en amont, et en plus sans inclure le Product Owner. Il en découle un manque de flexibilité nécessaire pour s’adapter aux découvertes et aux évolutions du marché.

Ces facteurs combinés créent un environnement où le focus sur la création de valeur est constamment mis à l’épreuve.


La clé dans un avenir plus itératif ?

Nous sommes dans un environnement complexe et la clé pour améliorer la situation est loin d’être simple ou évidente. Elle réside potentiellement dans des ajustements structurels profonds et stratégiques.

Tout d’abord, établir un objectif d’entreprise clairement ciblé, soutenu par des priorités définies et partagées à l’échelle de toute l’entreprise, pourrait fournir un cadre cohérent pour guider nos efforts collectifs. Une vision unifiée permettrait de concentrer les ressources et les talents sur ce qui compte vraiment, en évitant la dispersion des énergies et en maximisant l’impact de chaque action.

Ensuite, il est crucial de raccourcir les boucles de feedback à tous les niveaux : de la définition du besoin à son implémentation, de l’implémentation à la mise en production et de la mise en production à la validation du travail accompli. Réduire ces délais nous permettrait de répondre plus rapidement aux changements et de minimiser le risque en s’assurant que ce que nous livrons reste en parfaite adéquation avec les attentes et les besoins des utilisateurs.

Enfin, une approche qui inclut les utilisateurs finaux et l’équipe Scrum dès la phase de définition des besoins, et qui envisage l’équipe non pas uniquement comme un exécutant, mais comme un acteur clé du processus de discovery, est essentielle. Adopter un processus de discovery plus itératif, nous permettrait d’innover de manière plus efficace et de créer un produit véritablement aligné sur les attentes du marché.


Pas de commentaire actuellement

Votre adresse email ne sera pas publiée.