Tout à l’heure je suis tombé sur une interview de notre cher JP sur YouTube, sur la chaine de Marris Consulting
Vers 5:20 - 5:30, Jean Pierre dit ceci :
« Parfois on entend des développeurs dire « L’agilité c’est nul, c’est pire que tout ». Et ils ont raison parce que, avant [l’agilité], si on caricature un peu le cycle en V à l’ancienne, ou peu importe la méthode, on donnait un sujet aux développeurs, on les laissait se débrouiller pendant 3 mois et on les revoyait 3 mois après et pendant ces 3 mois ils pouvaient se concentrer sur leur expertise. Je ne dis pas que c’était bien, mais il y avait des avantages à faire ça. Là, en gros, on a déployé Scrum en mode « Bon, maintenant tu vas nous faire un compte rendu tous les jours en daily et puis toutes les 2 semaines, au moins, tu seras obligé de nous livrer un truc et de nous faire une démo etc … » Ce n’est pas ça le bon état d’esprit mais dans pas mal d’environnement c’est comme ça que c’est pris. C’est juste un outil de plus pour faire du flicage alors que le sujet de fond était mieux collaborer avec l’utilisateur le client lui délivrer plus de valeur de meilleure qualité plus tôt pour moins cher et pas exploiter plus des personnes. Souvent c’est la partie humaine qui dérape. »
Ma question (à @jplambert comme à d’autres) c’est :
Pourquoi, certains developers perçoivent l’agilité, et plus particulièrement Scrum, comme « un outil de plus pour faire du flicage » ?
(Ou plus précisément) Comment faire en sorte que Scrum ne soit pas perçu comme un outil de plus pour faire du flicage ?
Est-ce que faire de la pédagogie, expliquer ce qu’est l’agilité/Scrum, qu’il est mieux voire nécessaire de procéder par itération, d’utiliser un framework basé (entre autre) sur l’empirisme, l’inspection et l’adaptation, suffit ?
La pédagogie est effectivement une bonne piste. Je ne sais pas si expliquer ce qu’est l’agilité / scrum est indispensable (tout dépend du contexte / des gens avec qui tu travailles, de leur rapport à l’agilité).
Après, il faut surtout comprendre pourquoi c’est perçu comme du flicage et démontrer que ce n’est pas le cas (ex très basique: si en daily on sait que Pierre est bloqué sur une US, Juliette en est informé et pourra venir l’aider.).
Peut-être qu’il est aussi utile de voir avec les parties prenantes / le management comment sont perçues les estimations (que ça ne soit pas pris comme étant un engagement comme quoi dans 3 sprints, d’après les estimations, c’est livré).
Je dirais donc que comprendre l’origine de la perception permettra d’apporter les réponses / ajustements.
Le flicage vient d’une arme à double tranchant : la transparence.
Augmenter la transparence, c’est augmenter les risques, et surtout leur visibilité. Et aussi, augmenter la responsabilité.
Et la responsabilité : c’est la liberté. Et ça fait peur… Et quand on a peur, on préfère éviter les problèmes bien souvent plutôt que de l’affronter.
Donc ce n’est pas contre Scrum, ou l’agilité. C’est vraiment contre l’augmentation de la responsabilité (bien souvent, la cause profonde), et la peur qui va avec.
Bonjour Nicolas,
Ce ressenti d’un outil supplémentaire pour faire du flicage peut provenir du fait que la nouvelle situation réplique une organisation de contrôle existante avant de passer aux pratiques agiles.
J’ai eu des cas ou on est passé d’une organisation ou un chef de projet créait les demandes en mode « command and control » puis quand on est passé en Scrum, ce dernier devenu PO pinguait directement les développeurs en cours de journée pour vérifier l’avancement et imposer des dates de livraison.
Avez-vous déjà vécu cette situation ? Merci
Bonsoir @spip93 ,
Tu peux les rassurer en disant que Scrum est une structure horizontale, l’équipe Dev est responsable de la réalisation et de la livraison du produit. Une équipe qui s’auto-organisation , s’il y a un dysfonctionnement c’est pas une personne qui est visé mais plutôt l’équipe Scrum (PO, SM, Dev Team) .
Comment faire en sorte que Scrum ne soit pas perçu comme un outil de plus pour faire du flicage ?
A mon avis, ce n’est pas la bonne question.
Je conseille d’aider l’équipe à mieux voir sa situation (forces et difficultés) et à explorer des possibilités adjacentes, éventuellement en s’inspirant de Scrum, mais pas seulement. Il faut en même temps être à l’affût des effets secondaires qui peuvent être indésirables. (Safe to fail probes - Cynefin.io)
Ensuite, une meilleure explication orale peut aider, mais la pédagogie ne passe pas uniquement par des paroles. Les actions, le fait de vivre les choses aide à transmettre la connaissance tacite qui est souvent oublié et sans quoi la méthode est vide de sens.
Enfin, je pense qu’il faut arrêter de survendre les choses comme des incontournables ou des remèdes magiques.
Je suis d’accord avec @BenjaminF sur la transparence comme arme à double tranchant.
Généralement l’approche « naïve » suffit amplement. Explique pourquoi on fait les choses! (Encore faut-il le savoir )
Si tu prouves tous les jours que tu es là pour réaliser un produit de qualité dans le respect des gens qui le développe. Il sera difficile pour un développeur de te contre dire. Il pourra toujours essayer de contourner tes arguments si il a vraiment la flemme de prendre ses responsabilités. A toi de le remettre sur le bon chemin. Si ca révèle un problème de motivation et que cette personne ne sera donc jamais vraiment engagée, c’est sûrement une erreur de casting…
En effet pris sous un angle pessimiste ça peut paraître condescendant. Sous un angle optimiste, je vais essayer de reformuler.
Quand je dis approche naive c’est pour dire que parfois on explique pas simplement les choses, répondre a la question pourquoi suffit parfois a donner du sens aux choses. Et est-ce que ça n’est pas ce que nous recherchons tous? Faire des choses qui ont du sens?
Quand je dis remettre sur le chemin la encore ça n’est pas pessimiste. Ça s’est appliqué a moi aussi quand j’étais lead tech. Sur certains projets la tête complètement sous l’eau, a dépasser mes limites. Une fois on m’a sorti du projet, je l’ai mal pris, mais avec du recul c’est ce qu’il fallait faire car j’avais trop de rancune, jetais trop épuisé, j’avais trop donné et le résultat n’avait pas de sens a mes yeux. Pour autant je souhaitai continuer mais ça aurait été le mauvais choix, pour moi comme pour le projet.
Autre exemple, un architecte sur un projet ne faisait que du dev, quand il prenait un sujet il le faisait a moitié. C’est pas respectueux du client et de ses collègues qui reprenait son travail. Il n’était pas motivé, en effet ce qu’il voulait c’est faire de l’architecture. Le projet n’était pas bon pour lui car ça n’était pas le sens qu’il voulait donner à sa carrière. Dans ce cas autant se dire les choses respectueusement et revoir le casting.
Encore la rien de condescendant bien au contraire ce que je recherche c’est un équilibre, que les gens apportent leur meilleur au projet et que le projet permette l’épanouissement des membres de l’équipe !
Est-ce plus clair pour toi @punkstarman ? Si non qu’est ce qui est condescendant a tes yeux ?
Ce n’est pas une question de pessimisme ou d’optimisme. Le problème est que tu tires une généralité trop grande. Ce n’est pas « généralement » le cas que Scrum est le « bon chemin ». Ce n’est pas « sûrement » une erreur de casting si la personne n’est pas motivée.
L’expertise n’a pas sa place dans une situation complexe. En tant que « leader agile » ou accompagnateur du changement, nous n’avons pas à comprendre la situation ou apporter notre analyse. Nous avons plutôt à donner aux gens les moyens de mieux donner du sens à leur contexte par eux-mêmes.
Je ne dis pas que scrum est le bon chemin! (Relis mes messages si tu veux)
Je dis que le bon chemin est un chemin gagnant-gagnant projet-membre d’équipe.
Les valeurs de scrum sont FORCE le E pour Engagement, si il y a un problème sur l’engagement a voir comment le traiter si ce problème est trop important. Si dans un contexte scrum une personne n’est pas engagée, oui c’est sûrement un problème de casting. Ça ne reste que mon opinion libre à toi de ne pas être d’accord. Et peu m’importe de travailler dans un contexte autre que scrum, si ça peut te rassurer.
Si je post des messages sur ce forum c’est pour partager et apprendre, mais absolument pas pour me faire juger gratuitement. Si tu ne comprends pas mon point de vue, et bien échangeons mais avec un peu de bienveillance si possible.
Je relis tes messages. Effectivement, tu n’as pas explicitement dit que Scrum était le bon chemin. Je l’ai inféré du contexte. Désolé.
Le manque d’engagement d’une personne peut venir de plusieurs choses : des appétences et compétences de la personne elle-même, mais aussi du contexte dans lequel la personne est.
Ces phrases manquent cruellement de bienveillance envers la personne et ne considèrent pas assez la possibilité que le problème peut venir d’ailleurs.
« cruellement »… Je ne crois pas que l’on se connaisse et je suis tout sauf cruel.
Quand j’applique scrum j’applique aussi ses valeurs, parmi lesquelles figure le Respect et l’Ouverture. Si tu crois faire du scrum sans en appliquer les valeurs tu passes complètement à côté. C’est bien pour ça que j’estime que l’engagement est une chose essentielle.
Et non je ne vais pas jeter un membre de l’équipe si j’estime qu’il n’est pas assez motivé. On va chercher à savoir pourquoi, si on peut améliorer les choses. Comme dis précédemment le but est que les gens s’épanouissent, parce que oui des gens épanoui ça en fait des gens productif.
J’ai déjà passé 4 sprints de 3 semaines a faire monter en compétence un codeur qui ne savait pas coder… résultat il a demandé a sortir, car ça n’était bon pour personne.
Quelqu’un qui ne veut pas être transparent sur son travail, ne peut pas travailler avec scrum. Pourquoi ? Parce que sans application des valeurs il n’y a pas de confiance et sans confiance il n’y a pas de transparence et sans transparence il n’y a a pas d’inspection, sans inspection pas d’adaptation, donc pour finir pas d’amélioration continue … Qui peut prétendre faire scrum sans amélioration continue ?
Hello Nicolas, je te confirme, cela peut être considéré comme du flicage :
Lors de la sortie IOs 17, un dev front bloquait sur la mise en place d’une fonctionnalité sur d’anciens IOs (on maintient 6 versions). On passe d’un Sprint à l’autre, il ne prend que cette US…, je demande l’indice de confiance, réponse 1/5… Pourquoi ? Ben parce que j’essaie tout ce que je peux et je ne trouve pas de solution. Pour moi Scrum master, j’entends perte de confiance, de motivation et en plus blocage de la release de la fonctionnalité puisque Android et IOs doivent sortir ensemble.
Je sais que ça fait au moins 3 daily que j’entends ce blocage, je vais voir dans le Jira, je constate que rien ne sort en test sur IOs depuis un moment. Forcément, Focus sur cette fonctionnalité qui bloque la release, je lui suggère de contacter un dev IOs senior de sa boite de conseil. Et je signale la situation à l’ADM de l’organisation pour savoir ce que je peux faire. Réponse : « Mais c’est du flicage pas du Scrum master! » Je réponds que non, c’est de la prise en compte d’une situation bloquée, et que d’ailleurs je viens de faire au dev la suggestion de demander de l’aide à un dev senior. Bon l’aide n’a pas fonctionné, il ne savait pas non plus. mais leur discussion a allumé une étincelle qui a ramené le problème de l’importance du Legacy dans cette version, et la solution est venue 1 jour plus tard.
Ce qui a été considéré comme du flicage c’est la recherche des faits objectifs pour essayer de proposer une solution qui permette de remettre la machine en marche, dans les faits comme dans la tête.
Mais au delà de ça je crois que tout vient d’un souci de transparence et de gestion des égos personnels. Si la transparence est gérée selon Scrum et qu’il n’y a pas de gros égos, alors ça passe crème. Mais pour quelqu’un qui manque de confiance ou n’accepte pas de l’aide pour la raison inverse, relever les faits devient du flicage.
Bon ce dev, pas de problème d’égo donc c’est bien passé et avec le soulagement est revenu l’enthousiasme de réussir la suite sans blocage, et surtout soulagement pour toute l’équipe sur la release de la fonctionnalité.
Selon moi, la transparence c’est touchy tant qu’on n’en a pas fait une habitude. Donc forcément au début ça fait des vagues, et toute incursion est considérée comme du flicage. Après, quand l’équipe voit qu’il n’y a pas de conséquences personnelles négatives et au final le sentiment plus régulier d’avancer plus confortablement et bien cela devient plus facile à pratiquer par tous tant que ça reste dans la bienveillance (parce qu’on a aussi la « transparence d’attaque »= je me permets d’être limite vexant par transparence)
J’aurais d’autres exemples à te citer sur la relation « flicage »/« transparence », vécus en quelques mois, mais je crois que celle-ci est déjà bien parlante
J’y vais de ma proposition de réponse (sans encore avoir lu celles des autres)
Scrum se basant sur une équipe auto-organisée, il met un de ses piliers en avant au travers de ses valeurs, ses artefacts, ses pratiques… ce pilier, c’est la transparence.
On n’est pas fliqué, on reste transparent, on s’autorise à ne pas travailler dans une blackbox.
Pour le développeur qui n’est pas habitué à devoir travailler « réellement » en communauté, il y a déjà un sentiment de « surveillance » par les collègues de l’équipe.
Et avec les « externes » à l’équipe, c’est encore plus fort.
Certains confondent transparence (« hey vient, tu peux venir voir ce qui se passe chez nous et on en discute » et open bar ('Bon, ils sont transparents, je rentre, je regarde, je pars avec ce que j’ai vu, compris et je l’exploite à l’extérieur")
En fait, la transparence devrait être amandée comme un creative commons « Vous avez le droit de venir voir ce qui se passe, mais si vous le rapportez à l’extérieur, ou si vous l’interprétez sans discussion, veuillez préciser à vos interlocuteurs de venir nous en parler à nous l’équipe »
)
