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.
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
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.
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 ?
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.
