Membres d'équipe dominants dans une équipe Scrum

Que feriez-vous dans une situation où un membre de l'équipe qui essaie de prendre des responsabilités ne lui est pas initialement attribué mais au Scrum Master?

L'équipe Scrum est auto-organisée donc il y a de la place pour quelqu'un qui est un peu plus dominant. D'autres devraient lui demander ses idées sur les tâches sur lesquelles ils travaillent, mais sa domination doit être maîtrisée.

Ce que tu peux faire:

• Motiver les autres à être indépendants mais collaboratifs - cela peut être mieux réalisé si vous coopérez avec leur manager et les RH qui leur fixeront certaines attentes, qui seront évaluées régulièrement.
• Pendant les stand-ups, la planification et les rétrospectives; laissez les autres membres de l'équipe parler en premier. Lors des révisions, laissez les autres membres de l'équipe présenter des histoires d'utilisateurs qu'ils ont implémentées.
• Laissez les autres choisir les tâches en premier afin que le développeur dominant ne puisse pas seulement choisir les tâches qu'il veut faire.
• Impliquez la programmation par paires pour certaines tâches afin que le membre dominant de l'équipe collabore avec d'autres développeurs.
• Soyez démocratique - l'opinion d'un membre de l'équipe ne suffit pas pour apporter des modifications au processus - Scrum ne fonctionnera que si l'équipe communique clairement, ou si vous vous bloquez simplement.
• Si rien de tout cela ne vous aide, vous devriez parler avec le membre dominant de l'équipe et lui expliquer la situation - mais attention, il n'y a pas de chef d'équipe dans Scrum pour une raison. Si vous avez le soutien de la direction, vous pourriez également menacer sa stabilité d'emploi, mais cela devrait être la toute dernière option.

Si le membre dominant de l'équipe ne veut pas perdre sa domination et que les membres passifs de l'équipe ne veulent pas être plus actifs, vous aurez besoin du soutien de leur manager et des RH. Cela pourrait être un problème si le processus Scrum n'est pas encouragé par la direction.

Vraisemblablement, la raison de cette question est parce que vous sentez que l'équipe est en quelque sorte sous-performante à cause de cette personne dominante. Peut-être parce que le reste de l'équipe ne contribue pas à 100% parce que, à quoi bon?

En tant que gestionnaire, si vous l'êtes, il est de votre responsabilité de vous assurer que tous vos employés comprennent quels sont leurs rôles. Plus précisément, ce que l'on attend d'eux et comment ils vont être évalués. En tant que membre d'une équipe Scrum, chaque personne est personnellement responsable du succès de l'équipe. Ce membre d'équipe dominant doit donc savoir qu'il manque à cette responsabilité et sera évalué en conséquence.

La rétroaction est un point clé. S'il y a une réunion d'équipe et que cette personne domine la discussion, force ses conceptions et son approche sur le reste de l'équipe et les pousse dans des rôles passifs, alors il doit lui être dit, sans ambages et en privé, qu'il ne répond pas aux exigences du rôle. Si vous le repérez sournoisement en soulignant uniquement ses propres réalisations personnelles, alors il doit être appelé et faire comprendre que les réalisations personnelles sont beaucoup plus appréciées que d'aider l'équipe à avoir une réussite de groupe.

Tout cela est difficile, mais c'est à cela que servent les managers et les Scrum Masters.

Il y a une autre façon possible de procéder. Faites-en un problème d'équipe. Appelez-les ensemble et dites-leur qu'ils ne réussissent pas bien et voici pourquoi. Demandez-leur de trouver une solution. Vous pourriez être surpris.

Pourquoi ne pas demander son avis au développeur alpha. Il est tout à fait possible qu'il n'ait aucune idée de l'effet qu'il a. Prenez-le à part et dites-lui ce que vous pensez. Vous pourriez même organiser la discussion sur "hé vous êtes notre développeur principal, mais nous devons amener ces personnes à votre niveau, j'ai besoin de votre aide pour savoir comment pouvons-nous le faire?". Transformez sa domination en atout. Voyez s'il peut voir des façons de le faire.

S'il est mesuré sur la façon dont il soutient son équipe et les amène à son niveau, il sera plus motivé à le faire.

Vous sous-entendez qu'il ne travaille pas réellement dans l'intérêt de l'équipe (je suppose), c'est-à-dire qu'il est mal en quelque sorte, alors oui, retirez-le. Mais un homme sage m'a dit un jour: ne présumez pas la mauvaise volonté, alors que l'incompétence ou la simple ignorance sont plus probables.

On dirait qu'il essaie d'être le Scrum Master.

Clarifiez vos positions et agissez en conséquence.

Le rôle du Scrum Master est de favoriser l'esprit d'équipe. Si vous ne pouvez pas faire de cette seule et unique personne un joueur d'équipe, retirez-le de l'équipe .

Note rapide: votre développeur dominant n'est pas plus problématique que votre développeur passif.

la planification actuelle du sprint est un rôle qui tourne à travers l'équipe

La planification du sprint doit impliquer toute l'équipe et ne pas être remise à une seule personne à la fois. À moins qu'il y ait une bonne raison à cela, je vois cela comme un problème grave.

Si ce que vous dites est vrai et objectif, vous avez un problème majeur entre vos mains: les personnes qui ne participent pas et le "Dominator" qui empêche un processus vraiment agile. En tant que maître du srum, c'est à vous d'agir. Vous aimeriez peut-être mettre votre chef de projet en confiance dans cette situation.

De nombreuses équipes s'écartent du cœur de l'agilité, et c'est votre travail de les ramener. Vous devez enseigner et réintégrer des valeurs agiles dans l'équipe. En fait, vous devez constamment enseigner des valeurs agiles. Présentez votre vision de l'agilité, rendez-la claire et puissante. Montrez-leur votre engagement à "agile bien fait".

Pour ce faire, parcourez-les à travers le manifeste agile et les valeurs Scrum. Demandez-leur ce que la collaboration signifie pour eux et pourquoi c'est important. Demandez-leur quel est le rôle de la confiance dans l'agile. C'est le moment idéal pour expliquer pourquoi il n'y a pas de rôle de chef d'équipe et de chef de projet dans Scrum et qu'il est de la responsabilité de toute l'équipe de créer un excellent logiciel, pas de l'individu.

Planifiez une séance rétrospective entière autour de cela. Demandez-leur de s'engager sur certaines valeurs et de les suivre lors de la prochaine rétrospective. Ne pointez pas du doigt, utilisez des méthodes neutres.

Introduisez des méthodes qui obligent les autres membres à exprimer leurs opinions en toute sécurité. Quelque chose de simple comme un coup de cinq est idéal pour faire entendre les voix silencieuses de l'équipe. Il est douloureusement évident que l'équipe n'est pas d'accord avec le gars dominant. La planification du poker fonctionne bien mais la clé est de ne permettre aucune discussion avant que les cartes ne soient montrées. Tout ce qui aide à faire entendre les autres sans déclencher de conflit est utile.

Si cela se passe bien, vous êtes prêt. Sinon, parlez-lui du problème. Utilisez le coaching et posez des questions puissantes qui peuvent l'aider à comprendre clairement le problème. Essayez de trouver la cause profonde de la raison pour laquelle il a assumé le rôle dominant. Peut-être qu'il manque de confiance dans l'équipe (pourquoi?) Et peut-être qu'il se sent responsable du succès (pourquoi?). Je soupçonne que ce rôle n'est pas quelque chose qu'il veut et il est fort possible qu'il aimerait qu'il change. Il peut venir et s'en rendre compte.

Peut-être que le développeur "dominant" est récompensé par ses performances individuelles plutôt que par les réalisations de l'équipe?

Dans le passé, j'ai veillé à ce que les personnes très vocales et ayant des idées claires soient également récompensées (via leurs objectifs) en encourageant les contributions des autres.

En général, je pense que c'est une mauvaise idée de récompenser solidement les membres de Scrum pour leur contribution individuelle plutôt que pour les réalisations de l'équipe.

Vous pouvez également essayer de faire un tour de rétroaction 360 dans votre équipe pour tous les membres de l'équipe, uniquement si vous pensez que les autres membres de l'équipe seront véridiques dans leurs commentaires.

Proposer qu'il devienne le Scrum Master pour le sprint suivant.

Les personnes désireuses d'assumer des responsabilités ne sont pas un problème (tant qu'elles ne veulent pas de monopole sur elles), c'est précisément ce que nous cherchons à réaliser avec l'auto-organisation.

Soit dit en passant, les équipes avec un rôle de Scrum Master en rotation ne sont pas rares.

La seule tâche du Scrum master est de s'assurer que tout le monde respecte les règles du livre Scrum. Si les maîtres non scrum le faisaient par eux-mêmes sans interférence du maître Scrum, cela montrerait simplement que vous êtes en grande forme (Scrum-)! Moins le Scrum master a à faire, plus votre équipe est méchante et maigre du point de vue de Scrum. Finalement, le rôle de Scrum master pourrait / devrait être éliminé, il est là pour vous aider à démarrer et à vous enseigner Scrum.

Encore une fois, le Scrum master ne participe pas au processus de développement. Il doit s'assurer que toutes les parties prenantes communiquent à temps sur les bonnes choses, il connaît Scrum et fournit des conseils pour faire Scrum, il n'est pas propriétaire de produit ou chef de projet. Si vous vivez quelque chose de différent, vous ne faites peut-être pas Scrum dans un esprit agile. Bien sûr, dans des environnements plus petits, Scrum master pourrait être un rôle que l'un des membres de l'équipe ou des parties prenantes joue de côté. Ensuite, ce n'est qu'un plafond que l'on met au moment des formalités. Ne le confondez pas avec un rôle de leadership, c'est un rôle d'orientation.

Adoptez l'individualisme et la performance individuelle, mais essayez également de permettre aux individus passifs de devenir plus participatifs.

D'après mon expérience, bien qu'ils puissent sembler similaires à première vue, le communisme et l'agilité ne sont pas les mêmes. Agile ne vise pas une société sans classe (une équipe) mais un logiciel qui fonctionne.

Essayez de faire comprendre à votre développeur alpha qu'il pourrait vous aider à développer les compétences des autres en demandant et en encadrant plutôt qu'en répondant toujours en premier et en réalisant des réalisations individuelles. Certes, votre développeur alpha se soucie des bons logiciels, et c'est quelque chose que vous ne pouvez pas vous permettre de perdre.