Comment puis-je reprendre le contrôle de mon équipe "auto-organisée" ?

Vous lancez un regard bizarre au directeur de la formation, vous lui dites “au revoir Felicia” et le lendemain, vous convoquez une réunion de toute l'équipe et vous lui demandez de vous expliquer ces absurdités.

Si cela se produisait vraiment, je renverrais cet idiot de directeur de la formation en une minute à New York. Ce chef de section est dangereux, non professionnel et totalement inapte à son travail. Le moyen de “virer son manager” est de démissionner : il ne fait que donner des démissions pour toute l'équipe.

Je ne comprends pas pourquoi vous êtes inquiet. Ils sont tous sous vos ordres dans la hiérarchie, et n'ont pas le pouvoir de vous virer.

Plus important encore, vous devez comprendre ce qui se passe. Le maître de mêlée lui-même peut avoir besoin d'être licencié selon la situation.

Faites-le avant qu'il ne soit trop tard, avant que votre patron (ou le DSI) ne vous dise la même chose.

Bien que j'aie travaillé avec plusieurs équipes qui ont suivi la même ligne de conduite, il ne semble pas que cette affaire ait été traitée avec le soin qu'elle mérite. J'aimerais partager ce que j'ai vu pour voir si cela peut vous aider à aller de l'avant.

Premièrement, Scrum encourage les équipes qui s'organisent elles-mêmes. Ce que le guide Scrum dit spécifiquement sur les équipes auto-organisées est le suivant :

Elles s'auto-organisent. Personne (pas même le Scrum Master) ne dit à l'équipe de développement comment transformer le retard de production en une augmentation de fonctionnalités potentiellement exploitables ;

Cette approche, ainsi que beaucoup d'autres sur la transversalité et la responsabilité générale, est destinée à encourager les membres de l'équipe à se poser des questions difficiles sur leur capacité à répondre aux demandes qui leur sont adressées. Cela vaut vraiment la peine de lire le Guide Scrum - il est court.

En ce qui concerne un gestionnaire, si vous avez constaté que votre travail dans le passé consistait à attribuer des tâches et à suivre des éléments de travail, Scrum vous demande de prendre du recul. Franchement, si le Scrum Master ne vous a pas parlé de cela bien avant la première rétrospective, c'est peut-être qu'il a un peu manqué son coup. Mais la dure réalité est que beaucoup d'équipes habituées à ce qu'un manager organise leurs tâches à leur place ne sont pas bien préparées à se lancer dans cette approche. Si vous pensez que votre équipe se trouve dans cette situation, je vous recommande d'en parler au Scrum Master. Il existe de nombreuses techniques pour faciliter cette transition. J'aimerais notamment consulter l'ouvrage de David Marquet intitulé “Ladder of Leadership” et peut-être même son livre “Turn the Ship Around”. Vous constaterez que dans les deux cas, aucun manager n'est licencié.

Enfin, voyons pourquoi vous voudriez faire cette transition si vous avez réussi à gérer des personnes dans le passé. La version courte est que vous aurez encore plus de succès si vous les aidez à apprendre à se gérer eux-mêmes. Il y a tellement de recherches et de données à ce sujet qu'il est difficile de savoir par où commencer - mais je dirai que c'est un fait assez bien démontré que tous les gens sont potentiellement capables de s'auto-organiser et que dans une équipe de, disons, dix, onze cerveaux (le vôtre inclus), ils résoudront toujours les problèmes plus efficacement qu'un seul et qu'il y en a dix autres qui attendent de vous faire porter le chapeau si la solution est mauvaise.

J'ai vu beaucoup de managers qui ont réussi dans des environnements Scrum. Je mettrais toujours une équipe en garde contre le fait de “virer” quelqu'un. Même si vous êtes intimidant comme le dit votre question et que vous gérez chaque tâche devant eux, j'ai travaillé avec beaucoup de managers de ce genre qui sont toujours des atouts incroyables pour l'équipe. Dans ces équipes auto-organisées, vous ne passez plus tout votre temps à diriger les actions de l'équipe, mais vous vous assurez que la voie de la réussite est claire et qu'elle est toujours meilleure dans tous les domaines, les équipes étant plus performantes et les managers ayant la réputation de créer des rockstars.

Bonne chance, j'espère que cela vous donnera des angles de travail.

• Dans le cadre de la mêlée : Que dit le propriétaire du produit ? Ce n'est pas la fonction du maître de mêlée de demander plus (ou moins) de ressources. C'est quelque chose que le propriétaire du produit doit aligner avec les parties prenantes

• Dans le contexte de la mêlée : Une rétrospective porte sur le processus, l'équipe et le projet (et non sur “comment je me sens par rapport à mon patron”). Si vous faisiez partie de l'équipe, vous auriez dû être invité. Si vous ne faisiez pas partie de l'équipe, la rétrospective n'aurait dû porter que sur votre rôle dans le projet.

• Les maîtres de mêlée qui disent aux responsables hiérarchiques ce qu'ils doivent faire sont au moins aussi absurdes que les responsables hiérarchiques qui s'impliquent directement dans la mêlée

Le maître de mêlée a donc clairement dépassé ses limites. Sa fonction était de garder la rétrospective concentrée sur l'identification des problèmes spécifiques qui doivent être traités. Comment procéder :

• Vous parlez à l'équipe lors de sessions individuelles et leur demandez ce qui se passe. Vous expliquez clairement que le maître de mêlée n'est pas une fonction de ligne et qu'il ne pas assemble les équipes. Demandez également à l'équipe où elle estime que vous auriez dû rester en dehors des affaires quotidiennes, en déclarant que la situation doit être résolue immédiatement (en renvoyant le chef de mêlée ou le DSI en lui disant qu'il sera renvoyé sur la base du cours actuel), sinon cela met en danger le projet - pour moi, il me semble que le chef de mêlée ne comprend pas ses devoirs et ses limites. Une réponse professionnelle à l'équipe qui tente de “virer” son chef dans le cadre d'une rétrospective aurait été : “Ce n'est pas à moi de régler la relation entre vous et votre chef, et ce n'est certainement pas ce pour quoi le projet nous paie”.

J'ai souligné à l'équipe les avantages de l'auto-organisation des équipes et de la responsabilisation des équipes.

Eh bien, ils ont certainement pris cette partie à cœur.

Il semble clair que vous êtes dans une situation très émotionnelle en ce moment. Apparemment, votre équipe a de gros problèmes avec la relation actuelle entre vous et eux. C'est probablement une bonne chose que vous n'ayez pas assisté à la rétrospective, car c'est généralement la raison pour laquelle les gens sont soudainement prêts à parler de ce qui les dérange vraiment. S'ils sont prêts à le faire autour d'un Scrum Master avec lequel ils ne travaillent que depuis quelques semaines, alors soit ils lui font déjà confiance, soit ils sont tellement ennuyés qu'ils ne se soucient pas vraiment des conséquences.

Quoi qu'il en soit, ce n'est pas un nouveau problème qui est soudainement apparu lorsque vous avez changé de Scrum ou que vous avez engagé une nouvelle personne. Il s'agit d'un problème qui se développe sans qu'on s'en aperçoive depuis longtemps. On dit souvent que travailler [ Agile ne crée pas tant de nouveaux problèmes que de rendre ceux qui existent déjà extrêmement évidents. Cela dit, votre Scrum Master a laissé tomber la balle, durement. C'est son travail d'aider l'équipe à s'auto-organiser, c'est sûr. Mais ce n'est pas la bonne façon de faire. D'une part, il ne peut pas vous virer, et vous dire “c'est ce que l'équipe veut” est complètement non constructif. Je ne suis pas sûr de ce qu'il pense qu'il en résultera, mais cela ne peut pas être ce que l'équipe pense que c'est.

Aussi, retirer des personnes est le choix le plus difficile qu'une équipe ou Scrum-Master ) puisse faire et ne devrait jamais être pris à la légère et sans parler (de façon répétée) avec les personnes concernées. Vous ne pouvez pas vous contenter de renvoyer une personne qui n'a aucune idée que quelqu'un a un problème avec elle. Au pire, tout le monde aura peur que s'ils manquent une rétrospective, ils puissent soudainement retourner au travail et découvrir qu'ils ont été virés de l'équipe. Cela va créer une atmosphère de peur, et non de confiance. Une atmosphère de confiance et d'ouverture est ce que vous voulez lorsque vous travaillez en Agile.

Donc, comme votre Scrum Master n'a pas réussi à travailler dans une atmosphère ouverte (du moins en dehors de l'équipe ; il semble avoir amené les gens à s'ouvrir un peu en interne) et qu'il ne cherche pas de solution constructive, il semble qu'il vous incombe de le faire.

Pour l'instant, je ne pense pas que quelque chose basé sur l'autorité sera utile. Scrum et Agile visent à donner aux gens le pouvoir de faire ce qu'ils veulent, et affirmer votre autorité à ce stade va probablement finir par entraîner le licenciement de toute l'équipe. L'équipe a déjà déclaré qu'elle en était au point où elle souhaitait que les gens partent, donc même si elle s'est peut-être trompée sur la personne, le fait d'avoir un face-à-face avec elle se terminera probablement par le départ d'au moins quelques personnes. (Et n'oubliez pas la règle la plus importante concernant le départ : les personnes les plus précieuses seront les premières à partir)

Donc si vous voulez vraiment faire une Mêlée avec cette équipe, c'est là que vous devez accepter leur capacité à décider comment ils veulent travailler et avoir une discussion ouverte sur la façon dont ils veulent organiser leur équipe. Ils ne peuvent pas vous virer, mais ils ont clairement indiqué que ce que vous faites maintenant ne leur convient pas. Vous devez discuter de votre rôle futur, de ce qu'ils attendent de vous, de ce que vous attendez de vous, et de la manière dont tout cela sera organisé. Gardez à l'esprit qu'ils peuvent décider de la façon dont ils travaillent, mais qu'en fin de compte, il y a toujours un produit à livrer ; ils seront jugés sur la qualité de ce qu'ils livrent. Et si vous avez besoin de leur aide pour des questions d'organisation, ils devront également s'en charger. (Cela dit, travaillez avec eux sur la forme de ces choses et assurez-vous qu'elles sont vraiment nécessaires avant de les faire appliquer).

Assurez-vous que lors de cette réunion, vous n'abordez pas les choses sous l'angle de votre autorité ; l'idée est de mettre tout le monde au même niveau. Vous êtes des collègues et des individus qui ont tous un travail à faire, qui veulent tous faire du bon travail et qui doivent tous travailler ensemble au quotidien. Être autoritaire ne fait généralement que rendre les gens antagonistes les uns envers les autres, ce qui n'est pas productif. Essayez donc d'être vulnérable dans ce domaine et soyez prêt à admettre les choses que vous avez mal faites. Vous devez trouver un moyen de vous en sortir en tant qu'êtres humains.

On dirait que votre équipe a atteint la Phase de tempête de son développement en tant qu'équipe, et qu'elle l'a atteinte durément. Maintenant, c'est à l'équipe (et je vous y inclus, au moins pour l'instant) de trouver comment partir de là. Soyez avertis, toutes les équipes ne sortent pas de cette phase et je ne peux pas vous promettre que cette approche va régler le problème. Mais je peux vous garantir que ce ne sera pas pas pire que de démissionner ou de licencier tout le monde.

Et assurez-vous de parler séparément avec le Scrum Master. Je ne suis pas sûr de ce qui l'a poussé à s'ouvrir avec un premier message aussi peu constructif, mais il doit travailler sur ses compétences en matière de communication et de résolution de problèmes.

Bonne chance avec votre situation. Vous vivez certainement une époque intéressante ; tirez-en le meilleur parti et apprenez ce que vous pouvez en tirer.

(Je suppose également ici que le Scrum Master ne fera pas se révolter toute l'équipe contre vous sans que cela ne pose de sérieux problèmes sous-jacents. S'il le peut et qu'il pêche à la ligne pour votre poste, c'est un maître-manipulateur. Dès que vous en arrivez au point où vous pensez que c'est ce qui se passe, vous devez vous débarrasser du type asap. C'est probablement le seul cas où j'envisagerais d'utiliser votre autorité en tant que personne qui l'a engagé et de virer le gars).

Qu'ils aient ou non le pouvoir effectif de vous licencier en tant que leur directeur, vous avez provoqué cette situation en demandant un changement en mêlée simplement parce que vous le préférez. Vous n'en avez pas discuté avec eux. Vous étiez peut-être dans votre droit en tant que manager, mais c'était néanmoins une chose stupide à faire, et bien sûr ils se demandent maintenant s'ils veulent encore travailler pour vous.

Ne voyez-vous pas le sarcasme dans leur revendication d'autonomie et d'auto-organisation comme base pour prendre une telle mesure ?

Vous devez convoquer une réunion demain à 9h15 et vous excuser d'avoir pris une décision aussi importante sans tenir compte de leur avis. Vous pouvez ensuite leur demander leur avis sur la manière dont ils ont vécu leur premier sprint et sur ce qui aurait pu être fait différemment.

Si vous souhaitez introduire un nouveau flux de travail dans le processus de cette équipe, vous pouvez l'essayer à plus petite échelle, avec des tâches spécifiques comme programme pilote, avec quelques membres de l'équipe suffisamment ouverts d'esprit pour l'évaluer de manière équitable.

Avec des employés responsabilisés, il vaut mieux persuader, inclure et encourager que mandater.

Une perspective différente : vous est-il venu à l'esprit qu'ils se moquent simplement du processus de Scrum et de son aspect “auto-organisateur” ? Franchement, je ne peux pas imaginer qu'ils étaient sérieux du tout et qu'ils ont bien ri en lisant votre billet. Les développeurs de logiciels (j'en suis un) ont tendance à être des gens assez cyniques avec un sens de l'humour aride que tout le monde n'aime pas ou ne reconnaît même pas. Je suis sûr qu'ils vous disaient simplement qu'ils n'aimaient pas Scrum.

La meilleure chose à faire serait peut-être d'essayer de parler à certains d'entre eux de façon informelle de Scrum et des raisons pour lesquelles ils ne l'aiment pas.

Comme @Sascha l'a correctement observé , cela ne ressemble pas du tout à Scrum :

• Une équipe Scrum n'a pas de manager, elle répond plutôt à un Product Owner. Le Product Owner représente les intérêts des actionnaires vis-à-vis de l'équipe, organise les livrables pour le sprint au début de celui-ci, accepte les résultats à la fin, et clarifie les choses sur les demandes de l'équipe entre-temps. Il est essentiellement un mandataire entre l'équipe et l'entreprise.
• Si vous faisiez partie de l'équipe Scrum, vous assisteriez à une réunion rétrospective. Si vous ne faites pas partie de l'équipe Scrum, la réunion aurait dû se limiter à votre rôle par rapport à l'équipe au sein du modèle Scrum.

Donc, la question est Où vous situez-vous sur cette photo ? Quel est votre rôle au sein du modèle Scrum ? ** Puisque c'est **vous qui avez eu l'idée d'essayer Scrum en premier lieu, vous avez certainement fait des recherches sur Scrum et y avez réfléchi avant de le proposer, non?

Et si vous ne l'avez pas fait, il est temps de le faire maintenant. **Vous continuerez à faire la même chose, mais maintenant l'équipe vous répond collectivement plutôt que chaque membre individuellement, et vous cessez de la micro-gérer à moins qu'elle ne le demande spécifiquement (cette dernière option est sans doute une bonne chose pour les deux parties).

Puisque vous avez apparemment échoué dans vos recherches en suggérant Scrum, je pense que vous n'avez pas trouvé de responsable de produit dédié - vous êtes donc exactement dans la position d'assumer ce rôle maintenant.

Cela n'annule pas le fait que le Scrum Master n'a aucune idée de ce qu'il fait, ou qu'il est à la recherche de votre travail - les autres réponses ont couvert de manière adéquate la manière de procéder.

*Comment puis-je désamorcer cette situation et rétablir mon autorité en tant que manager, tout en restant fidèle aux principes d'auto-organisation et de responsabilisation de l'équipe de l'agile ? *

Depuis quand êtes-vous le manager de cette équipe ? Je ne pense pas qu'une équipe se rebellera contre le manager direct pour un désaccord sur un seul sujet. Le problème pourrait être plus grave que la seule méthode agile.

C'est quelque chose d'essentiel pour un manager et vous devez l'aborder, cela devrait être votre priorité numéro un pour les prochaines semaines.

Vos n+1, n+2 sont en congé pour plusieurs mois ? peut-être que cela a influencé votre équipe à se rebeller. Quelle est la situation financière de votre entreprise (si elle est mauvaise, les employés pourraient penser que vous faites un mauvais travail et que vous pouvez faire mieux sans vous).

que faire : - organiser une réunion avec toute l'équipe : “le chef de mêlée m'a dit que vous vouliez me renvoyer, que se passe-t-il ? (il est très important que vous abordiez le sujet avec tout le monde car ils le connaissent tous et si cela affecte le travail quotidien). -Identifier le vrai problème (seulement cette méthode agile ou vous avez déjà eu un problème avec l'équipe auparavant ?) -Une fois que vous connaissez le véritable problème, vous devez enquêter : qui a raison ? vous ou vos employés ? -Identifiez qui est le chef de cette rébellion (il y a toujours un employé qui défie les autorités plus que les autres). Si vous pensez qu'il est hors sujet, vous devez prendre des mesures disciplinaires.

Je ne suis pas sûr de ce qu'un “manager” signifie dans votre entreprise, mais en général, je pense qu'il s'agit de quelqu'un qui aide les équipes à répondre à leurs besoins et à améliorer leurs performances. Maintenant :

Je suis un grand partisan de l'agile, alors j'ai engagé un maître de mêlée et j'ai dit que nous suivrions la mêlée.

Ça ressemble plus à “j'ai une grande idée”, je veux que vous la réalisiez. Au lieu de consolider d'abord l'équipe autour de votre idée. Je pense que chaque équipe a le droit de critiquer votre idée et de faire des trous dans votre idée. Si votre idée ne tient pas, vous devriez pouvoir la laisser tomber.

Il n'est pas sûr que le fait que l'idée tienne puisse dire à l'équipe que vous voulez une période d'essai et/ou migrer lentement vers la nouvelle structure du projet.

De cette façon, vous pourriez toujours rencontrer de la résistance mais probablement pas autant que maintenant.

Je pense qu'il faut résumer : Vous êtes leur manager, pas leur patron. Ce sont deux emplois très distincts !

“Le code est plus ce que vous appelleriez des "lignes directrices” que de véritables règles.“ - Capitaine Barabossa

Il me semble que vous êtes dans une situation difficile et que vous essayez de vous accrocher à des idéaux déraisonnables.

J'ai souligné à l'équipe les avantages de l'auto-organisation des équipes et de la responsabilisation des équipes.

Expliquez à vos enfants que l'auto-organisation et la responsabilisation ne signifient pas qu'ils peuvent faire ce qu'ils veulent. Si votre équipe a décidé d'aller voler des armes automatiques et de braquer une banque, vous n'êtes pas obligé de les suivre simplement parce qu'ils sont responsabilisés.

Ils ne peuvent pas vous "virer”. C'est le rôle de votre manager. Les tirs viennent toujours du haut de la chaîne, et non du bas. Bien sûr, ils peuvent sauter des échelons dans la hiérarchie et travailler avec votre patron pour vous renvoyer, mais comme apparemment votre patron et le patron de votre patron sont tous deux en congé sans avoir mis quelqu'un en place en leur absence, il n'y a pas beaucoup de hiérarchie à laquelle se référer. Vous avez quelques mois.

J'ai dit au maître de mêlée que j'aimerais en parler à l'équipe, mais il a été ferme sur le fait qu'ils se sont sentis “intimidés” quand j'étais dans la pièce, et qu'ils ne voulaient pas en discuter avec moi.

Eh bien, c'est dommage pour eux. Parlez-leur quand même. L'autonomisation peut vous donner la capacité de prendre vos propres décisions, mais elle ne vous libère pas de la responsabilité de respecter ces décisions. Si j'avais une équipe comme ça, leur parler serait le niveau de réponse le plus gentil que j'envisagerais.

On pourrait dire “Oh, mais le maître de la SCRUM est censé résoudre des obstacles comme celui-ci. Tout devrait passer par lui.” Bien dur. Il a tout gâché quand il est allé vous voir pour vous dire que vous étiez viré et n'a pas fait preuve de suffisamment de courtoisie pour que vous l'acceptiez. On attend d'un maître de la SCRUM qu'il ait de meilleures qualités relationnelles que cela.

Alors qu'en dites-vous ?

D'abord, vous voulez savoir s'ils ont vraiment décidé de vous “virer”. Vous avez la parole d'une personne à ce sujet, et je crois que c'est le genre de situation où l'équipe devrait pouvoir dire directement ce qu'elle pense.

Deuxièmement, considérez ce que signifie “virer”. Vous prétendez être un manager sans mains, mais ils veulent que vous partiez. Ils n'écrivent pas les chèques de paie, donc la décision de vous licencier n'est pas du genre “oh, ils ne font pas leur part”. C'est une décision du genre “cette personne se met activement en travers de la route”. Il y a quelque chose qui ne colle pas. Vous avez besoin de faire le calcul pour vous avant de prendre des décisions importantes. Étant une personne anonyme sur Internet, je ne peux pas dire si c'est vous ou eux ou le maître de SCRUM, mais quelque chose ne va vraiment vraiment pas dans ce scénario, et vous feriez mieux de savoir ce que c'est quand vous aurez fini de parler avec eux.

Travaillez avec eux. Soyez un manager. Trouvez un moyen de résoudre le problème. Trouvez un moyen pour que vous puissiez faire votre travail, pendant qu'ils font le leur. Maintenant, si leurs réponses vous permettent de faire le point et de respecter leur autonomie, vous devez montrer à l'équipe ce qui se passe lorsque vous “virez” le leadership comme ça. Dites “Bien. Je vais arrêter d'agir comme votre manager. Vous ne pouvez pas en fait me virer, parce que ce n'est pas votre position, mais si vous voulez jouer à ce jeu, nous pouvons jouer. J'étais votre manager, je vous aidais à vous isoler de la politique d'entreprise et du stress lié au fait de devoir rendre des comptes à la direction. Maintenant, je suis votre cadre supérieur, et vous n'avez plus cette isolation. Maintenant que je ne peux pas me retirer de ce poste, je vais simplement commencer à relayer les tâches depuis la haute direction”. Expliquez que ce n'est pas parce que l'équipe a voté que vous n'avez pas d'obligations envers la direction que vous devez remplir et que vous continuerez à le faire.

Alors, demandez de l'aide.

Une mutinerie n'est pas une petite chose. Toute votre équipe vient de vous voter le départ de l'île. Ne la sous-estimez pas. Obtenez l'aide de quelqu'un au-dessus de vous. Peut-être que tu appelleras ton patron en congé. Peut-être que vous parlerez à votre DSI. Quelqu'un doit savoir qu'il y a un problème majeur de personnes dans votre entreprise, et que vous le résolvez. La deuxième moitié est clairement importante. La solution que je recommande est de vous faire passer pour le “manager qui a des exigences” en choisissant les choses dont la direction (c'est-à-dire le DSI) a besoin et qui sont conçues pour favoriser l'épanouissement personnel et l'autonomisation. Ils peuvent penser qu'ils sont libres de faire ce qu'ils veulent, mais vous êtes toujours obligé d'en faire une équipe qui réussit _ Si vous devez le faire à distance, faites-le à distance. Découvrez ce qui a rendu votre approche de non-intervention si intimidante, et assurez-vous de ne jamais faire cela.

L'objectif final est de leur faire comprendre que vous êtes de leur côté. S'ils sont vraiment autonomes, alors ils doivent se rendre compte que vous êtes un élément bénéfique de l'équipe. Ils n'arriveront à cette conclusion que s'ils réussissent. S'ils sont submergés par des des délais et une bureaucratie sans espoir, ils ne le verront jamais.

Assurez-vous simplement que tout s'additionne. 2+2=4. Un manager “sans mains” est “viré” par le nouveau maître de la SCRUM pour s'être montré trop intimidant alors que deux niveaux de direction sont en congé ? Il y a quelque chose qui ne colle pas à partir de là. Vous êtes plus proche de la situation. Trouvez ce qui ne va pas et corrigez-le.

Soit : a) Ils ont raison et vous n'avez pas réussi à justifier votre existence. (Ils ne peuvent toujours pas vous virer) ou b) Le maître de mêlée veut votre emploi.

Je pense que la meilleure chose à faire pour vous est d'aller suivre un cours de maître de mêlée de 2 jours et de vous débarrasser de votre maître de mêlée. Vous pourrez alors probablement recevoir une prime à la fin de l'année pour avoir fait deux boulots.

Il n'y a pas de rôle de gestionnaire dans une équipe de mêlée. La vraie question est de savoir pourquoi vous pensiez être un membre de l'équipe en premier lieu. Si vous ne participez pas à la diffusion d'un film, vous n'avez pas votre place dans cette équipe - donc ce que l'équipe a fait était correct.

S'ils vous considèrent comme un obstacle, découvrez pourquoi - le scénario probable est que vous vous immisciez, et la solution est que vous vous retiriez et les laissiez faire leur travail.

Que pensez-vous que votre rôle soit dans l'équipe ? Trouvez une réponse utile qui corresponde aux objectifs de la mêlée, puis soulignez à l'équipe que vous avez l'intention de faire ce travail, et de ne pas interférer avec le leur.

Je ne vois donc pas pourquoi vous ne pouvez pas voir cela comme quelque chose de positif ? Je crois comprendre que l'objectif d'une équipe autogérée est de ne pas avoir besoin d'un manager.

Ce que vous devez faire, c'est examiner les opportunités que cela présente. En gros, vous avez une super équipe qui peut se gérer elle-même et vous êtes maintenant capable de faire ce qui suit :

• Vous êtes capable de tenir plus facilement l'équipe responsable des engagements de l'entreprise. Si l'équipe ne peut pas atteindre les objectifs de l'entreprise, elle ne peut tout simplement pas s'autogérer
• Vous pouvez développer les compétences de l'équipe. Vous pouvez donc maintenant vous concentrer davantage sur l'aspect humain de l'équipe. L'évolution de carrière, l'autonomisation et ce genre de choses.

• Réalisez que l'équipe + le chef de mêlée sont toujours responsables devant vous dans la hiérarchie de l'entreprise, les budgets et le processus d'évaluation des performances. Ce n'est donc pas comme s'ils pouvaient passer par-dessus votre tête.

• Considérez donc cela comme un succès pour l'instant. Pensez plutôt aux possibilités de renforcer l'équipe. **Réalisez aussi que vous devez être là pour le scénario où cette approche d'autogestion échoue.

Lao Tseu a dit

Le mauvais leader est celui que le peuple méprise,

Le bon leader est celui que le peuple vénère,

Quand un grand leader dirige, les gens disent “nous l'avons fait nous-mêmes”.

Un leader est meilleur quand les gens savent à peine qu'il existe,

quand son travail est terminé, son but atteint,

ils diront : nous l'avons fait nous-mêmes.

et je suis cette maxime depuis le premier jour de la direction des équipes de développement. Si tout le monde sait ce qu'il faut faire, alors je ne suis pas nécessaire et mon travail est mieux servi de cette façon - en profitant de la vie en dehors du bureau.

Vous suivez les mesures, vous vérifiez leur code, vous faites de légères corrections de trajectoire, vous encouragez et permettez tout ce qui doit être encouragé et permis - communication, coopération, tests écrits, etc, vous les protégez des cadres supérieurs et des clients - et idéalement vous n'agissez jamais. Mais quand vous le faites, vous le faites et vous leur donnez des coups de pied au nez quand c'est nécessaire, vous êtes le responsable de leur travail, après tout - les gens se font virer sur votre recommandation et vous virer vous devriez, et à temps. Je ne sais pas pourquoi un développeur virerait quelqu'un qui ne le gêne pas et qui est là pour réparer les choses et les protéger des clients et parfois même des supérieurs hiérarchiques, qui s'occupe de la disponibilité des équipements, de la documentation, qui les pousse un peu à devenir de meilleurs programmeurs et de meilleures personnes et qui leur permet de se concentrer sur le code. Vous avez juste été jugé inutile ou nuisible à l'effort de développement et ils préfèrent jouer sans vous.

Soit cela, soit il y a une sérieuse pathologie dans la culture de l'équipe.

Je dirais que c'est une opportunité incroyable pour une grande réflexion et une grande croissance.

Je vois ici deux points de vue :

• Vous étiez le directeur hiérarchique d'une équipe de développement dans une organisation matricielle, et vous êtes toujours le directeur hiérarchique. Votre travail a peut-être changé un peu, mais il est fondamentalement le même : vous fournissez des jours-homme de développement au PO conformément aux processus de budgétisation et de ressources humaines de l'entreprise, vous vous occupez de l'embauche (et, si nécessaire, du licenciement), vous planifiez les congés en coopération avec l'équipe, etc.
• Dans le développement agile, votre rôle est peut-être un peu moins compliqué qu'auparavant, mais surtout s'il y a plusieurs équipes de mêlée, votre rôle comprendra désormais des choses comme l'encouragement des “communautés de pratique” ou des “guildes”. Comme toute chose, la mêlée peut être nuisible si elle est poussée à l'extrême, et quelqu'un doit veiller, par exemple, à ce que les piles technologiques restent compatibles, à moins qu'il n'y ait une très bonne raison de faire une exception. C'est le travail de la hiérarchie dans une telle organisation.
• Vous étiez un membre de l'équipe de développement et vous avez eu une influence directe sur les décisions technologiques, l'architecture, etc. Dans ce cas, je vous suggère de vous tromper en ne vous impliquant pas assez dans ce premier sprint, parce qu'ils ne voient pas comment vous allez apporter vos compétences à l'équipe. Dans le prochain sprint, travaillez avec l'équipe.

Je suis responsable d'une équipe de développement.

Je suis un grand partisan de l'agile

Bien ! Si par “agile” vous voulez dire “Scrum” (pourquoi auriez-vous engagé un Scrum Master, sinon…), alors tout va bien.

Ils ont historiquement suivi une méthodologie très “waterfall” et ont été résistants au changement.

l'équipe a collectivement accepté de me “virer” en tant que leur manager

Good ! Ils ont changé de méthode, ils ont abandonné leur résistance (vous ne nous avez pas dit à quoi ils résistaient, avant…). Comme vous le savez certainement, un manager n'a que des responsabilités très limitées dans le contexte d'une Scrum Team ; vous n'êtes ni le Scrum Master, ni le Product Owner, ni l'un des Stakeholders, ni une partie de la Scrum Team elle-même. Je me souviens quand j'ai obtenu mon certificat Scrum Master lors d'un séminaire de 3 jours ; le rôle de “manager” n'y figurait même pas.

Si votre entreprise utilise la structure matricielle typique de la gestion hiérarchique verticale par rapport à la gestion horizontale liée au projet (ou au produit) (c'est-à-dire le responsable hiérarchique <> les responsables de projet/produit), alors tout semble se dérouler comme prévu. Vous aurez toujours des responsabilités managériales, c'est-à-dire que vous devrez gérer tout ce qui est en dehors du travail productif quotidien de votre équipe.

Permettez-moi de répéter votre phrase clé :

Je suis un grand partisan de l'agile

C'est le bon moment pour embrasser cela, et apprendre ce que signifie gérer une Scrum Team. Vos responsabilités ont également changé. Vous faites les choses habituelles (intégrer de nouveaux membres, gérer les salaires, aider votre équipe à travailler (leur fournir le matériel/logiciel/etc. et un bon environnement de travail), peut-être collaborer avec d'autres responsables de Scrum). Le fait que votre entreprise semble reconnaître les unités organisationnelles n'a pas changé. Les membres de votre équipe auront toujours besoin de vous parler, mais pas de leur travail.

En fonction de ce que vous faisiez auparavant comme travail quotidien (distribution de paquets de travail à des développeurs individuels), vous voudrez peut-être envisager d'autres choses que vous pouvez faire. Par exemple, vous pourriez avoir votre mot à dire sur les projets pour lesquels votre équipe travaille, ou si un responsable de produit devient méchant d'une manière ou d'une autre, il pourrait être de votre devoir de le calmer. Vous pourriez être responsable de la gestion des contrats avec les clients (ventes, etc.). Vous serez un partenaire et un bouclier pour votre équipe en cas d'escalade. Vous êtes gestionnaire. Gérer n'est pas la même chose que développer des logiciels ; et assigner des tâches à des personnes individuelles n'en est qu'une petite partie.

Franchement, je dirais que vous avez beaucoup de chance. Surfez sur la vague. Laissez-les faire leur travail. Évitez de gérer leur nouvelle Scrum à distance ; Scrum a été créée précisément pour rendre l'équipe autonome et capable de fonctionner sans microgestion constante de l'extérieur. De nombreuses parties de Scrum sont faites pour protéger une équipe d'une gestion indésirable.

Votre travail pourrait être très facile maintenant. Si tout fonctionne comme prévu, ils s'occuperont de beaucoup de choses que vous deviez faire auparavant. Tout le monde peut être très heureux à partir de maintenant, surtout s'il n'aimait pas votre micro-gestion avant.

l'équipe a collectivement accepté de me “virer” en tant que leur manager

Evidemment, je suppose que puisque vous avez cité le mot “virer”, ils n'ont pas littéralement envoyé un courrier aux RH pour vous exclure de la paie, mais ils vous ont dit qu'ils veulent vivre Scrum dans toute son étendue (et son intention). Je suppose évidemment qu'ils ne veulent pas couper les lignes de l'organigramme de votre entreprise. Même une équipe Scrum pure doit encore être enracinée quelque part dans l'entreprise, c'est-à-dire faire partie de la gestion hiérarchique, et c'est vous. Vous n'êtes tout simplement plus impliqué dans le travail quotidien.