Un produit, plusieurs apps, une scrum team

Communauté Scrum Life
, ,
1

Bonjour à tous,

Je viens d’arriver (1 mois) dans une équipe Agile sous framework scrum, en tant que scrum master.

Je suis confronté à un problème :

Comme dit dans le titre, l’équipe est une « équipe produit », fonctionnant avec le framework Scrum. Il y a donc un seul produit (avec une vision de produit), mais à l’intérieur de celui-ci plusieurs outils/apps à maintenir, développer. Les développements peuvent être, dépendamment de l’application, du dev pure (Python par exemple) mais aussi de l’administration (modification de workflow sur un jira, ajout de colonnes dans des rapports et j’en passe…) et également de l’incidentologie.
De ce fait, l’équipe est réellement pluridisciplinaire mais avec des compétences non partagées et peu ou pas d’envie de progresser sur des domaines jusqu’ici inconnus (les dev ne font pas d’admin, les admin pas de dev, et tous, excepté un, font de l’incidentologie). Je me retrouve donc avec une équipe scindée en 2 sous équipes : une équipe de « tech », une équipe de « non tech ». Ceci n’est pas verbalisé, mais cela se ressent au quotidien.

Plusieurs points noirs en découlent :

  • Lors des cérémonies tous les sujets n’intéressent pas toutes les personnes en même temps. J’ai fait face à des discussions comme « On perd notre temps dans ces cérémonies parcequ’on ne comprend pas tout et cela ne nous intéresse pas car on ne fera jamais de Python » (par exemple), l’inverse étant vrai pour les dev qui ne font pas d’admin. Les cérémonies en question ici : sprint review et sprint planning principalement. Je ne parle même pas des sessions de refinement…

  • Impossibilité de faire un seul et unique sprint goal car il y a des besoins sur tous les outils à maintenir, et faire un seul sprint goal (donc sur un seul outil), réduirait à néant l’engagement et la motivation quant au sprint des personnes ne travaillant pas sur ce sprint goal… Oui je sais, c’est ultra moche…

C’est ultra moche, mais j’essaie de modifier cela en leur proposant des ateliers autour des méthodes agiles, de renforcer leur acculturation Agile, de les accompagner sur le sens de leur équipe, l’important d’être concerné/engagé autour de son produit… Mais rien n’y fait jusque là, je me frotte toujours aux mêmes remarques…

Auriez-vous des pistes, des débuts de réflexion à avoir pour essayer de modifier ces comportements ? Passer sur la stratégie Kanban au détriment du framework Scrum ?

Bref… Je me questionne et j’aimerais avoir vos avis.

Merci de m’avoir lu jusqu’au bout !

2

Bonjour et bienvenue Jérémy,

Tu exposes très clairement les faits, mais peux-tu nous éclairer sur le problème que tu veux résoudre et pourquoi ?

On peut avoir envie de modifier des comportements pour se conforter dans les bonnes pratiques agiles, encore faut-il que les gens aient envie de changer, et comme les gens ne souhaitent changer que s’ils voient un intérêt au changement, il faudrait d’abord creuser la raison du « pourquoi changer ». Si la réponse apportée aux collègue est « pour être vraiment agile », cela n’amènera pas le changement :wink:

3

Merci Nicolas pour ton retour.

Le problème que je veux résoudre est simple : Du fait de cette disparité dans l’équipe, de la multiplication des objectifs de sprint, j’ai remarqué clairement un manque d’engagement vis à vis des sprint goals.

En découle des sprints dans lesquels les objectifs ne sont pas atteints et ça ne dérange personne (à part moi visiblement…), seulement 50% du travail engagé lors du sprint planning est réalisé (parfois moins, jamais plus).

Il y a un déficit réel et observable d’engagement et de sens.

Voila pourquoi je souhaiterais « modifier ces comportements » pour amener plus de sens, de sérénité, d’engagement dans cette équipe malgré la multitude d’apps à maintenir/développer (10 apps) dans cette équipe produit.

4

Côté déficit de sens : En tant que développeur, qu’est ce qui me motive à travailler sur ce « produit », pour cette entreprise ? Y-a-t-il du sens au travail que j’effectue avec mes collègues ? A quoi je sers ? Pourquoi servirai-je les autres ?

=> Comment, en tant que scrum master, tu peux amener les collègues à trouver du sens ? Sont-ils portés par une vision ? Une mission ? Se dégage-t-il des intérêts communs vers une destination ? Peut-on aligner des personnes et peut-on s’aligner dans un collectif de travail ?

Côté déficit d’engagement : En tant que Scrum master et en tant que Product owner, ai-je réussi à dégager un sens au travail et à partager cette vision auprès du collectif de travail et pour que naturellement le collectif (je parle pas encore d’équipe) adhère à des objectifs que lui-même peut co-construire ? Peut-on attendre de ces objectifs un quelconque engagement ?

Je vois bien ce qui te porte en tant que scrum master, mais souvent on veut mettre la charrue avant les boeufs et tout avoir en même temps : la collaboration, l’engagement, le plaisir au travail, la transparence,… Mais tout ça se construit sur le long terme. Sur le long terme et en plus pas seul. Ton meilleur allié dans ce genre de transformation va être celui qui porte la vision du produit.

Comment se passe la relation avec le PO et comment voit-il les choses lui ?

5

La relation avec le PO est plutôt bonne. Il adhère complètement aux méthodes Agiles, au framework scrum.

J’essaie de le challenger sur son backlog, sur ce qu’il a mis en place pour l’équipe (plus de 5 mois sans scrum master, donc il a essayé de faire office d’eux). Bien souvent, nous avons des discussions très intéressantes autant sur le fond que sur la forme. Donc de ce côté là, je sens bien que nous voulons avancer dans le même sens.

Concernant l’équipe, et je pense que tu as mis le doigt desssus, la vision de produit est floue voir très floue. La plupart des membres de l’équipe ne connait pas la vision du produit et donc forcément, difficile de se sentir impliqué dans un produit pour lequel tu n’as pas ou peu la vision, l’objectif du produit.

Et je pense que tout découle de là : pas ou peu de connaissance de la vision produit ==> peu sens pour l’équipe ==> peu d’engagement. Ajoute à cela que le produit est scindé en 10 outils à maintenir / améliorer + du run… Tu obtiens une équipe qui est complètement éclatée et qui fonctionne « pratiquement » en silo.
L’équipe est designée comme ça par l’entreprise, je n’ai malheureusement pas la main sur cela…

Alors, moi de mon côté, j’essaie de m’atteler à amener du sens, les coacher sur ce que sont les méthodes agiles, quel est le but/sens pour NOTRE équipe de travailler en SCRUM, ce que ça nous apporte en tant qu’équipe et individus, quels bénéfices nous en tirons mais également quelles problématiques en ressort. Et j’essaie en conséquences de proposer des ateliers cohérents avec ce qui ressort et de mettre également sur le tapis ces sujets en rétro pour que l’équipe tente de mettre des actions en place…

Ca ne fait qu’un mois que je suis dans cette équipe, donc il est bien trop tôt pour évaluer l’évolution. Mais en revanche, il est vrai que je me sens parfois en difficulté dans mon rôle de scrum master vis à vis de ce design d’équipe et tout ce qui en découle.

6

Hello,

J’arrive un peu après la bataille, mais à mon avis il y a un discours assez contradictoire :

Tu dis que l’équipe est une « équipe produit » mais tout le reste semble contredire cette affirmation.

Soit on est sur un produit unique qui s’appuie sur un écosystème d’outils, et on peut avoir un sprint goal commun à l’ensemble. Dans ce cas, le sprint backlog correspond à l’articulation de cet objectif en une collection de tâches cohérentes à réaliser, qui se répartissent sur tout ou partie des outils (et pas forcément toujours les mêmes).

Soit on ne sait établir des sprint goals qu’au niveau de chaque outil et il n’y a donc en fait pas de produit unique, seulement une juxtaposition de logiciels.

7

Salut Adrien,

Désolé je viens de voir ta réponse que maintenant…

En fait, c’est un peu plus compliqué : nous avons 9 outils qui sont regroupés au sein d’un unique produit qui se nomme « Produit Outils IT », donc qui recense tous les outils utlisés par les collaborateurs de la DSI du client (ex: EasyVista pour les incidents, Jira, miro, sciforma (saisie des équipes, budgets etc… , monday, GCP pour exposer des données de reporting aux utilisateurs et j’en passe…), tenant sous une vision de produit commune qui est grosso modo de permettre aux collaborateurs de la DSI d’avoir à disposition des outils leur permettant de référencer, collaborer et mesurer l’activité fonctionnelle du SI.

Cette collection d’outils, regroupés au sein du produit nommé précédemment, ne permettent pas de dégager un seul et unique sprint goal du fait de la pluralité des périmètres (certains sont techniques, d’autres plus administratifs…).
Aujourd’hui donc, je ne trouve pas le moyen de faire émerger un seul sprint goal. Et ça m’agace parceque j’ai l’impression que ce problème est insoluble et que finalement, le framework scrum, n’est probablement pas le plus adapté à ce contexte. J’ai communiqué en ce sens au PO et la responsable de services, mais pour eux la situation leur convient en l’état…

Peut-être que l’utilisation de Kanban serait plus adaptée. J’ai déja taté le terrain plusieurs fois, mais à chaque fois il y a bottage en touche…

En tout cas, merci pour tes réponses.

8

Je comprends bien le contexte : vous avez un centre de services qui maintient 9 outils. Si ces outils sont proposés individuellement aux utilisateurs, ils constituent « une offre de services » mais pas « un produit », même avec une vision commune.

Un produit est un ensemble cohérent et atomique de services visant à répondre à un ensemble cohérent de besoins des utilisateurs. Pour que l’offre de services devienne un produit, il faut qu’il soit présenté de manière unifiée aux utilisateurs. On ne demande pas accès à Jira ou Miro mais « la plate-forme Toto », derrière laquelle se cache un certain nombre d’outils, organisés de manière intelligente pour fournir le service aux utilisateurs. L’outil n’est pas une fin en soi : si la plate-forme utilise Jira pour répondre au besoin organisationnel des utilisateurs, on pourrait imaginer la remplacer par un Tuleap, ou une solution sur-mesure tout en continuant de fournir le même service aux utilisateurs. Dans ce contexte, on a une vision unifiée des utilisateurs, avec un marché segmenté par le besoin et non par l’offre. Il devient alors « facile » d’avoir une vision produit, avec des objectifs produits qu’on peut ensuite décliner en objectifs de sprint, lesquels peuvent impliquer de toucher tel ou tel outil mais pas tel autre.

La question à 1 millions d’Euros : « Faut-il proposer un produit ou une offre de services ? »

Bah oui, clairement la situation leur convient, car c’est toi et l’équipe de dev que ça dérange, pas eux :slight_smile: ! Si tu veux faire bouger les lignes il faut commencer par leur faire constater le problème. Abordez-vous le problème en rétrospective ?

Le PO est responsable du produit. Son produit = ses objectifs. Ce n’est donc pas à toi (« je ne trouve pas le moyen ») de faire émerger un sprint goal, mais au PO. Bien sûr, ça te concerne, car ça concerne l’équipe, mais ton rôle de SM consiste à aider l’équipe à résoudre les problèmes, pas de faire le boulot du PO à sa place. Surtout pas de résoudre ses problèmes avant qu’il en ait conscience. Ton rôle de SM c’est de pointer les problèmes, leur responsable, et de les aider à les résoudre.

A mon sens, la première étape c’est de poser factuellement, avec l’équipe, les problèmes rencontrés, en rétro par exemple. Ensuite, expliquer que du point de vue de Scrum (ton domaine d’expertise à toi), ce qui pose problème c’est l’absence de sprint goal au niveau de l’agrégat d’outils. Donc que tu seras vigilent à l’avenir de faire en sorte que le PO se présente avec des sprint goals cohérents aux prochains sprints plannings.

Ca ne veut pas dire de tout lui mettre les problèmes sur le dos, mais remettons l’église au milieu du village : c’est sa responsabilité, tu ne le feras pas à sa place, mais tu viendras en soutien de son effort à lui. Même si tu sais que in-fine le problème est plus profond, je n’aborderais pas la question de la cohérence méthodologique, car c’est pas à toi d’aboutir à cette conclusion, mais au PO. Il va donc falloir l’accompagner pour qu’il admette le problème. Là, vous pourrez aller voir la responsable de service ensemble pour discuter méthodologie.

Ca se fera en l’accompagnant sur l’identification des sprints goals, où il va galérer autant que toi. A ce moment là, tu peux aborder, toujours sous l’angle de ton domaine d’expertise, le fait que les sprint goals sont généralement rédigés en cohérence avec un product goal. Et donc l’accompagner (ou le faire accompagner) sur la fixation de product goal qui, j’imagine, ne l’ont pas été. En tirant la pelote, vous devriez finalement aboutir à la discussion sur la cohérence produit des outils, discussion que tu peux ensuite réorienter vers une discussion avec la responsable de service.

Enfin, ça, c’est si le PO est de bonne constistution …