Sceptique dans une équipe Scrum

14

Mon entreprise est récemment passée à une méthode de travail agile et, dans le cadre de celle-ci, nous avons commencé à utiliser SCRUM. Bien que je sois très à l'aise avec cela et que je pense que cette méthode est supérieure à une méthode traditionnelle, certains de mes coéquipiers ne partagent pas la même opinion. En fait, ils sont très sceptiques à propos de "toutes ces choses agiles" et ne les prennent pas au sérieux. À titre d'exemple, l'un des coéquipiers est toujours en retard aux réunions et ne s'en soucie pas vraiment. La direction de l'OMI essaie de ne pas le remarquer (peut-être parce que c'est nouveau et qu'il faut du temps pour que les gens s'y habituent).

Ma question est de savoir comment résoudre ce problème sans soulever de conflit au sein de l'équipe?

Sorantis
la source
4
Qu'est-ce que WoW? Googler "agile WoW -warcraft" n'a pas beaucoup tourné.
Joe Daley
1
@Joe - "Façon de travailler" peut-être?
ChrisF
Manière de travailler.
Sorantis
Scrum! pas SCRUM! Sensationnel? Agile # 1 = WoT, pas WoW. Sans le WoT, le WoW est juste SNAFU. Et l'une des principales façons de penser est d'abattre les barrières à la communication, pas d'en ériger de nouvelles.
MIA
2
Agile WoW = Raider un boss ou deux par nuit pendant une semaine et faire un clair complet en cours de route? Et jumeler des raiders / faire des examens DPS? Désolé, ancien joueur de WoW ici.
Wayne Molina

Réponses:

21

Face à un sceptisme extrême, j'essaye quelques choses:

1.) Je démonstration des techniques telles que TDD, déploiement continu, Paire programmation, la collecte des besoins avec vos utilisateurs, itérations courtes etc. Je n'appeler ces techniques agiles ou harpe au sujet du Manifeste Agile (je harpe sur le logiciel Artisanat - mais c'est différent; p). Je montre simplement aux membres de l'équipe des outils et des techniques utiles qui leur facilitent la vie. Ils ont tendance à sauter dans le train agile une fois qu'ils en voient les avantages au jour le jour.

2.) Je n'échange pas immédiatement vers une méthodologie SCRUM (ou autre) complète. Il est toujours préférable d'introduire de petits aspects d'Agile à la fois.

3.) Je suis d'accord avec les sceptiques (jusqu'à un certain point). Agile n'est pas une solution miracle et SCRUM, Kanban, Lean, etc. ne sont pas non plus une solution miracle. Au lieu de cela, je travaille avec eux pour voir quels aspects pourraient leur être profitables immédiatement (un serveur CI est généralement une évidence), puis j'essaie le reste "Laissons les stand-ups pendant une semaine, puis passez en revue".

Comme toute méthodologie, SCRUM et d'autres doivent réellement travailler avec l'équipe et l'organisation, pas les aliéner.

Donc, pour passer directement à votre question. Soulevez-le avec l'équipe:

"Je suis aussi un peu sceptique à propos des stand-ups, mais je pense qu'en tant qu'équipe, nous devrions lui donner un bon coup d'essai pendant 1 semaine (pas d'excuses!) Et ensuite le revoir pour voir si cela a fonctionné pour nous. Que font les gens pense?"

Martijn Verburg
la source
9
@ Sorantis - Ce n'est pas vraiment un problème Agile WoW, n'est-ce pas? On dirait que ce membre de l'équipe n'est tout simplement pas bon pour travailler en équipe! Il s'agit davantage d'un problème de psychologie / comportement humain et l'astuce consiste généralement à découvrir ce qui motive cette personne (à la fois dans son comportement positif et dans son comportement négatif).
Martijn Verburg
4
++ Lorsqu'elle est imposée, c'est comme une religion, et les gens sont naturellement résistants. Lorsqu'elle est explorée fonctionnalité par fonctionnalité, elle ressemble davantage au bon sens, et si les gens disent "mais c'est essentiellement ce que nous faisons de toute façon", alors vous gagnez. Je pense qu'une partie du problème avec Agile est simplement qu'il a un nom, et vient donc de l'extérieur.
Mike Dunlavey
1
Ahhh programmation par paires - c'est là que 1 gars lit un magazine tandis que les autres codes :)?
Chris S
2
@Martijn, j'ai fait la programmation par paires où une personne a la souris et l'autre le clavier. De cette façon, les deux doivent se concentrer;)
Benjol
1
@Mike Dunlavey: "si les gens disent" mais c'est essentiellement ce que nous faisons de toute façon "alors vous gagnez." - ou alors vous introduisez une beaurocratie inutile? s'ils le font bien de toute façon, ont-ils vraiment besoin de vos règles sur la façon de le faire?
2011
16

Un cas typique de Scrum mal implémenté .

Scrum a été imposé à l'équipe. L'équipe (entière) ne l'a pas choisie.

Lorsque vous souhaitez l'implémenter, vous devez avoir un soutien total de l'équipe et de la direction, sinon cela ne fonctionnera pas du tout.

La résistance au changement est votre ennemi ici.

Je vous suggère fortement de recommencer et de présenter Scrum à l'équipe et de la laisser poser des questions.

Si vous ne vendez pas l'idée, n'essayez pas de les forcer à utiliser une méthodologie dont ils ne veulent pas. Ils feront tout pour le saboter. Arriver tard dans les stand-ups quotidiens est l'un des comportements que vous aurez.

Veuillez noter que Scrum peut ne pas être recommandé pour votre entreprise. Les seules personnes qui peuvent répondre à cette question sont les personnes qui travaillent à la base. L'équipe .


la source
1
Existe-t-il un moyen d'inciter les sceptiques à aimer le SCRUM? C'est une chose un peu faible à faire - ne l'utilisez pas si vous ne l'aimez pas.
Sorantis
1
@Sorantis: il n'y a pas de moyen facile de le faire. Vous devrez investir beaucoup d'efforts et de temps pour expliquer comment Scrum apportera des avantages pour les . Le confort du statu quo est si important qu'ils feront tout ce qu'ils peuvent pour le garder. Même en se forçant à ne pas comprendre les avantages. C'est ce qui se passe lorsque vous imposez vos idées aux autres. Votre situation est vraiment difficile à résoudre.
@Sorantis - cela arrive tous les jours. Cela s'appelle les ventes. Continuez à souligner les bonnes choses que SCRUM vous a apportées. Meilleure communication! S'adapter au changement! Garder le projet simple! Ne soyez pas trop bon pour utiliser le travail de Pavlov. ;-) Les gens répondent à être montrés, moins à se faire dire. Montrez-leur que SCRUM fonctionne bien pour vous et ils suivront dans le temps.
Steve Goodman
C'est ce que Staline a dit.
Job
Staline a dit quoi?
5

Il se peut que le concept de réunions quotidiennes ne s'applique pas très bien à ce qu'une personne fait. Ces réunions ne sont pas gratuites.

Si ce que vous faites nécessite beaucoup de concentration à long terme, comme les mathématiques, les réunions peuvent vous dérailler et être frustrantes. Je travaille avec quelqu'un comme ça, qui préfère se rencontrer sur une base hebdomadaire, ce qui est parfaitement raisonnable.

Mike Dunlavey
la source
5

En fait, pour être honnête, si j'étais dans votre équipe de programmation, je serais probablement aussi sceptique! J'ai vu une longue lignée de méthodologies qui étaient censées révolutionner les choses et faire en sorte que les projets arrivent à temps, dans les limites du budget et sans bug. Ce n'est que la dernière. Pourquoi devrais-je croire l'huile de serpent? Il y a 10 ans, les mêmes personnes fouettaient autre chose, dans quelques années, quelque chose de nouveau arrivera. Ne vous méprenez pas, je pense que certaines des nouvelles méthodologies apportent des idées utiles. Malheureusement, ils apportent aussi beaucoup de dogmes et d'idées stupides.

Est-ce vraiment important s'il ne monte pas à bord? Attribuez-lui simplement quelques tâches de programmation et laissez-le faire comme il l'entend. Si son travail est satisfaisant, qu'il le soit. Si son travail n'est pas satisfaisant, remplacez-le. Pourquoi est-il si important pour les gens de suivre la mêlée?

Au fil des ans, j'ai vu beaucoup de bons programmeurs quitter ou s'énerver parce que leur manager continuait à introduire de nouvelles méthodologies. Ils veulent juste coder et faire le travail. Croyez-moi dans quelques années, vous maudirez la mêlée et sauterez sur la dernière mode.

Antonio2011a
la source
-1. Même si la mêlée n'est pas là pour rester, vous faites toujours partie d'une organisation. Si cette organisation décide de passer à la mêlée, il est très facile de progresser. Si vous êtes un bon programmeur et joueur d'équipe et que vous êtes prêt à accepter que quelqu'un d'autre en sache plus sur les priorités commerciales, alors Scrum vous permettra exactement de faire votre travail, à votre façon. Si elle est bien faite, la mêlée ne devrait pas prendre plus de 10% de votre temps. Dans ces 10%, vous avez également fait votre planification et vos rapports. Boohoo.
Kris Van Bael
1

Si vous faites de l'agilité, vous devriez avoir un backlog à partir duquel vous travaillez. Utilisez la mêlée pour distribuer des affectations à partir du backlog.

Les choix (les meilleurs) choix sont choisis en premier au début de la réunion. Lorsque vous arrivez en retard, donnez-lui simplement ce qui reste pour la journée.

Peu importe s'il est le don de Dieu pour la programmation, il obtient la tâche de merde que personne d'autre ne voulait. S'il essaie de réaliser une autre tâche ou de travailler sur autre chose, l'équipe dans son ensemble doit s'appuyer sur lui et le forcer à ne travailler que sur sa tâche «choisie». Vous devriez probablement avoir un maître de build qui peut rejeter ses modifications s'il ne travaille pas sur le travail choisi.

L'équipe devrait également fixer des objectifs et éventuellement une compensation. Vous pouvez voter en équipe pour ne pas récompenser ceux qui ne participent pas. Cela dépend du niveau de propriété que votre direction a accordé à votre équipe agile. Rappelez à la direction ceux qui blessent l'équipe et empêchent celle-ci de réussir.

Rappelez-lui que s'il se présente à l'heure, il peut participer au processus.

Bill Leeper
la source
De cette façon, vous perdrez la dernière chance de vendre Scrum aux sceptiques. À mon avis, le vrai problème est la méthodologie imposée, comme d'autres réponses le suggèrent.
MaR
1

Les équipes Scrum sont censées s'auto-organiser. Scrum fonctionne également en implémentant une transparence extrême dans tout.

Donc, la réponse évidente est que le Scrum Master appelle une réunion, explique le problème (mais ne vous moquez pas, tout le monde dans l'équipe sait déjà exactement quel est le problème), puis leur dit qu'ils ont 1 heure pour comprendre ce ils vont y faire. Puis il s'assoit dans le coin et garde la bouche fermée.

De toute évidence, il s'agit d'une équipe nouvelle pour Scrum. La clé est donc que le Scrum Master doit accepter la réponse que l'équipe propose. S'il les annule ou impose ses propres idées à la solution, il détruira la confiance dont l'équipe a besoin pour construire avec lui qu'ils sont autorisés à s'auto-organiser. Il est possible que l'équipe décide de ne rien faire.

En tout état de cause, la question doit être examinée lors de la rétrospective Sprint et l'efficacité de la solution proposée peut être discutée.

Éviter les «conflits d'équipe» ne devrait même pas être un facteur du tout.

Dave
la source
0

Renvoyez le coéquipier, il ne provoquera pas de controverse au sein de l'équipe.

John Saunders
la source
1
Je ne pense pas que ce soit une solution du tout. C'est comme si ma main me faisait mal .. Oh, coupons-le.
Sorantis
4
Cela dépend - si l'entreprise a choisi de mettre en œuvre SCRUM et que les membres du personnel ne sont pas disposés à travailler comme requis par l'entreprise, c'est un motif de licenciement assez classique.
Murph
@ Sorantis: plus comme "si ta main gauche t'offense, coupe-la", ou quelque chose comme ça. Et, prévenez-le d'abord.
John Saunders
2
@Rob: passez par le processus, expliquez clairement ce que l'on attend du sceptique, et s'il ne veut pas faire ce qui est nécessaire, laissez-le partir ou bien renvoyez-le. Ne pas le faire envoie le mauvais message au reste de l'équipe - que SCRUM n'a pas d'importance et qu'ils peuvent tous l'ignorer, tout comme le sceptique.
John Saunders
2
Agile, c'est l'équipe. Si vous avez quelqu'un qui refuse de faire partie de l'équipe, la direction doit le mettre en probation ou le laisser partir. À long terme, vous serez mieux avec une équipe qui fonctionne bien qu'avec quelqu'un qui cause des problèmes. J'ai entendu de nombreuses histoires d'équipes agiles détruites par une mauvaise pomme.
Bill Leeper
0

Parcourez votre ancien travail, trouvez plusieurs exemples de la façon dont l'approche de la chute d'eau vous a laissé tomber plusieurs fois dans le passé. Présentez ensuite les cas à votre coéquipier. Avec un aperçu du bon sens, il verra la lumière.

La programmation est une activité de précision, donc une personne rare resterait insensible aux faits. Du moins, en théorie.


la source
Le fait est que je suis un nouvel employé de l'entreprise. Je suis venu quand ils ont commencé à utiliser WoW agile. Et mon coéquipier travaille dans l'entreprise depuis 15 ans
Sorantis
2
J'ai juste mal interprété «chute d'eau» comme «échec de l'eau» et c'était le meilleur changement de nom d'une approche de développement que j'ai jamais vu. Impressionnant!
glenatron
@glenatron: Très agréable, frappe vraiment le clou.
3
Le problème avec l'approche consistant à trouver des contre-exemples est qu'ils ne sont pas de bons arguments en faveur d'autres idées spécifiques. Personne n'aime les chutes d'eau, mais cela ne veut pas dire qu'ils veulent s'engager avec Agile.
Mike Dunlavey
0

Qui a pris la décision de changer et pourquoi? Où ces sceptiques ont-ils participé à la décision ou la décision a-t-elle été abandonnée?

Êtes-vous trop rigide et / ou rapide dans la mise en œuvre de vos nouvelles méthodes? Avez-vous sorti de bons produits (pas nécessairement parfaits) en utilisant vos anciennes méthodes? Avez-vous démontré aux sceptiques en quoi cela leur sera bénéfique? Pouvez-vous le démontrer? Ceux qui ont "vu la lumière" ont-ils démontré aux sceptiques en quoi cela profite à eux, à l'équipe et à l'entreprise?

Vous leur demandez probablement de n'accepter tout que sur la parole des croyants. Plus que probable, ces sceptiques ont adopté de nouvelles méthodologies auparavant et aucun avantage n'a jamais été réalisé.

Peut-être pourriez-vous faire un projet ou deux avec seulement les croyants qui y travaillent en utilisant vos nouvelles procédures. Prenez de vraies mesures et démontrez aux sceptiques de réels avantages. Peut-être même mettre en place un peu de concurrence entre les sceptiques et leurs anciennes méthodes et les croyants et leurs nouvelles méthodes.

Bien sûr, que faites-vous si les sceptiques gagnent?

ElGringoGrande
la source
Je ne suis pas manager, je suis juste un membre de l'équipe. La décision a été prise par la direction
Sorantis
0

Organisez une réunion d'équipe pour discuter et comprendre pourquoi votre entreprise est passée à SCRUM et demander à tout le monde d'identifier ce qu'ils pensent de SCRUM ajouterait de la valeur au mode de fonctionnement actuel. Parfois, les entreprises effectuent des commutations à tête d'os (j'ai participé à des réunions de mêlée où personne n'écoute vraiment et tout le monde se contente de dire ce qu'il a fait hier et quitte. Ces équipes parviennent généralement à un équilibre comme - "Je ne vous questionnerai pas et vous ne salissez pas avec moi "et se dandiner là-bas. C'est juste une perte de temps), alors prenez ce qui vous convient le mieux.

Les vétérans ont généralement beaucoup de résistance à tout ce qui pourrait changer leur style de travail actuel, vous devez donc vous assurer qu'il y a suffisamment de carottes pour qu'ils puissent sortir de leur inertie. Dans ce cas, j'aurais un 1: 1 avec cette personne ou je ferais de lui le scrum master :). Une fois que vous leur donnez la responsabilité, ils trouveront la paix avec elle ou la supprimeront complètement parce que cela n'ajoute pas de valeur. Les deux sont gagnant-gagnant.

Subu Sankara Subramanian
la source