Vous jetez un regard bizarre au Scrummaster, et vous dites "bye Felicia", et le lendemain, vous convoquez une réunion de toute l'équipe et leur demandez ce qu'est cette absurdité.

Si cela arrivait réellement, je congédierais le scrummaster idiot dans une minute à New York. Ce scrummaster est dangereux, non professionnel et totalement inapte à son travail. La façon de «renvoyer votre manager» est de démissionner: il vient de démissionner pour l’ensemble de 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 renvoyer.

Plus important encore, vous devez comprendre ce qui se passe. Le Scrum Master lui-même devra peut-être être licencié selon la situation.

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

Bien que j'aie travaillé avec un certain nombre d'équipes qui ont suivi le même plan d'action, il ne semble pas que cela ait été traité avec le soin que cela mérite. J'aimerais partager ce que j'ai vu pour voir si cela vous aide à avancer.

Premièrement, Scrum encourage les équipes auto-organisées. Voici ce que le Guide Scrum dit spécifiquement sur les équipes auto-organisées:

Elles sont auto-organisées. Personne (pas même le Scrum Master) ne dit à l'équipe de développement comment transformer le backlog produit en incréments de fonctionnalités potentiellement libérables;

Cela, avec beaucoup d'autres choses sur le fait d'être interfonctionnel et large responsabilité, vise à encourager les membres de l'équipe à se poser des questions difficiles sur la façon dont ils sont bien préparés pour répondre aux demandes qui leur parviennent. Il vaut vraiment la peine de lire le Guide Scrum - il est court.

Quant à un manager, si vous avez constaté que votre travail dans le passé a été en attribuant des tâches et en suivant les éléments de travail, Scrum vous demande de prendre du recul par rapport à cela. Franchement, si le Scrum Master ne vous a pas parlé de cela bien avant la première rétrospective, cela a peut-être été un peu raté de sa part. Cependant, une dure réalité est que de nombreuses é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 sentez que votre équipe est dans cette situation, je vous recommande d'en parler au Scrum Master. Il existe de nombreuses techniques pour faciliter cette transition. En particulier, je regarderais l'échelle de leadership de David Marquet et peut-être même son livre Turn the Ship Around . Vous constaterez que dans les deux cas, aucun responsable 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 en les aidant à apprendre à se gérer. Il y a tellement de recherches et de données à ce sujet, il est même difficile de savoir par où commencer - mais je dirai que c'est un fait assez bien démontré que tout le monde est potentiellement capable de s'auto-organiser et dans une équipe de, disons dix, onze cerveaux (y compris le vôtre) résoudront toujours les problèmes plus efficacement qu'un seul et en avoir dix autres en attente de vous rejeter la faute si la solution est erronée.

J'ai vu beaucoup de gestionnaires qui réussissent dans les environnements Scrum. Je mettrais toujours en garde une équipe contre un «licenciement» pur et simple. Même si vous êtes intimidant comme le dit votre question et que vous gérez toutes les tâches qui leur incombent, j'ai travaillé avec de nombreux managers comme celui-là qui sont toujours des atouts incroyables pour l'équipe. Dans ces équipes auto-organisées, vous passez de passer tout votre temps à diriger les actions de l'équipe pour vous assurer que la voie de leur réussite est claire et que cela ressort toujours mieux dans tous les domaines, les équipes livrant plus et les managers ayant la réputation de créer. rockstars.

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

• Dans le contexte de Scrum: que dit le product owner? Ce n'est pas la fonction du scrum master de demander plus (ou moins) de ressources. C'est quelque chose dont le Product Owner doit s'aligner avec les parties prenantes

• Dans le contexte de Scrum: Une rétrospective porte sur le processus, l'équipe et le projet (pas sur "comment faire je me sens pour 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û traiter que de votre rôle dans le projet.

• Les Scrum Masters indiquant aux supérieurs hiérarchiques ce qu'il faut faire sont au moins aussi absurdes que le supérieur hiérarchique s'implique directement dans la mêlée

Ainsi, le scrum master a clairement dépassé ses limites. C'était sa fonction 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 en un -en une session et demandez-leur ce qui se passe. Vous expliquez clairement que le scrum master n'est pas une fonction de ligne et qu'il ne rassemble pas les équipes. Demandez également où ils pensent que vous auriez dû rester en dehors des activités quotidiennes

• indiquez clairement à l'équipe à qui les problèmes doivent être adressés

• Vous passez à la suivante (si c'est le CIO, c'est le CIO - il n'est pas acceptable que vous n'ayez pas de manager pendant des mois), déclarant que la situation doit être résolue immédiatement (en renvoyer le scrum master ou le CIO ayant un mot avec lui qu'il sera viré sur le parcours actuel), sinon cela met en danger le projet - pour moi, il semble que le scrum master ne comprend pas ses devoirs et ses limites. Une réponse professionnelle à l'équipe essayant de «licencier» son manager dans le cadre d'une rétrospective aurait été: «Ce n'est pas à moi de régler la relation entre vous et votre patron, 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 l'autonomisation des équipes.

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

Il semble clair que vous êtes actuellement dans une situation très émotionnelle. Apparemment, votre équipe a des problèmes majeurs avec la relation actuelle entre vous et eux. C'était probablement une bonne chose que vous n'ayez pas participé à 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, soit ils font déjà confiance au gars, soit ils sont tellement agacés qu'ils ne se soucient pas vraiment des conséquences.

De toute façon; ce n'est pas un nouveau problème qui est apparu soudainement lorsque vous êtes passé à Scrum ou que vous avez embauché une nouvelle personne. C'est un problème qui se répand depuis longtemps sans être vu. On dit souvent que travailler Agile ne crée pas tellement de nouveaux problèmes, mais rend les problèmes déjà existants extrêmement évidents. C'est probablement un cas de cela.

Cela dit; votre Scrum Master a lâché la balle, dur. C'est son travail d'aider l'équipe à s'auto-organiser, bien sûr. Mais ce n'est pas la bonne manière. D'une part, il ne peut pas en fait vous renvoyer, et vous dire simplement "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 très bien être ce que l'équipe pense que c'est.

De plus, supprimer 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 (à plusieurs reprises) avec ces impliqué. Vous ne pouvez pas simplement sortir et retirer quelqu'un qui n'a aucune idée que quelqu'un a un problème avec lui. Si rien d'autre, tout le monde aura peur du fait que s'ils ratent une rétrospective, ils pourraient soudainement retourner au travail pour constater qu'ils ont été expulsés de l'équipe. Cela va créer une atmosphère de peur, pas de confiance. Une atmosphère de confiance et d'ouverture est ce que vous voulez lorsque vous travaillez Agile.

Donc, avec votre Scrum Master qui ne parvient pas à travailler dans une atmosphère ouverte (au moins en dehors de l'équipe; il semble ont amené les gens à s'ouvrir un peu en interne) et à ne pas chercher une solution constructive, il semble que vous incombiez à le faire.

À ce stade, je ne pense pas que quoi que ce soit fondé sur l'autorité va être utile. Scrum et Agile visent à donner aux gens les moyens de faire leur propre travail, et affirmer votre autorité à ce stade va probablement finir par renvoyer toute l'équipe. L'équipe a déjà déclaré qu'elle en était au point où elle voulait que les gens s'en aillent, alors même s'ils se sont peut-être trompés sur la personne, se retrouver face à face avec elle se terminera probablement par au moins quelques personnes qui partent. (Et rappelez-vous 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 Scrum 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 licencier, mais ils ont clairement indiqué que ce que vous faites maintenant ne fonctionne pas pour eux. Vous devez avoir une discussion sur ce que sera votre rôle à l'avenir, ce dont ils ont besoin de vous, ce dont vous avez besoin de vous et comment tout cela va être organisé. Gardez à l'esprit qu'ils doivent décider comment ils fonctionnent, mais en fin de compte, il reste un produit à livrer; ils seront jugés sur la qualité de leurs prestations. Et s'il y a des choses organisationnelles dont vous avez besoin de leur part, ils devront également faire ces choses. (Cela dit; travaillez avec eux sur la forme de ces choses, et assurez-vous qu'ils sont vraiment nécessaires avant de les appliquer.)

Assurez-vous que lors de cette réunion, vous n'abordez pas les choses 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 jour le jour. Être autoritaire rend généralement les gens antagonistes les uns envers les autres, ce qui n'est pas productif. Alors essayez d'être vulnérable ici et soyez prêt à admettre les choses que vous avez mal faites. Vous devez comprendre comment partir d'ici en tant qu'êtres humains.

Il semble que votre équipe ait atteint la phase d'assaut de son développement en tant qu'équipe, et ils l'ont frappée dur . Maintenant, c'est à l'équipe (et je vous y inclue, du moins pour l'instant) de déterminer comment partir de là. Être averti; toutes les équipes ne sortent pas de cette phase et je ne peux pas promettre que cette approche résoudra le problème. Je peux garantir que ce ne sera pas pire que de quitter ou de renvoyer tout le monde.

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

Bonne chance avec votre situation. Vous vivez certainement à une époque intéressante; Tirez le meilleur parti d'eux et apprenez ce que vous pouvez de cela.

(Je suppose également ici que le Scrum Master n'amènera pas toute l'équipe à se révolter contre vous sans quelques problèmes sous-jacents sérieux. peut et il cherche votre travail, il est un maître-manipulateur. Dès que vous pensez que c'est ce qui se passe, vous devez vous débarrasser du gars dès que possible . C'est probablement le seul cas où j'envisagerais simplement d'utiliser votre autorité en tant que personne qui l'a embauché et le renvoyer.)

Qu'ils aient ou non le pouvoir réel de vous licencier en tant que manager, vous vous êtes attaqué à cette situation en ordonnant un changement de mêlée simplement parce que vous le préférez. Vous n'en avez pas discuté avec eux. Vous étiez peut-être dans vos droits en tant que manager, mais c'était quand même une chose stupide à faire, et bien sûr, ils se demandent maintenant s'ils veulent plus travailler pour vous.

Ne voyez-vous pas le sarcasme dans leur revendication d'autonomisation et d'auto-organisation comme base pour entreprendre une telle action?

Vous devez convoquer une réunion demain à 9h15 et vous excuser d'avoir pris une décision aussi importante sans prendre en considération leur contribution . Vous pouvez ensuite demander leurs commentaires sur la façon dont ils pensaient que leur premier sprint s'est déroulé et 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 en tant que programme pilote, avec quelques membres de l'équipe qui sont ouverts d'esprit assez pour lui donner une juste évaluation.

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 moquaient simplement du processus Scrum et de son aspect «auto-organisé»? Franchement, je ne peux pas imaginer qu'ils étaient sérieux du tout et ont bien ri en lisant votre message. Les développeurs de logiciels (j'en suis un) ont tendance à être des gens assez cyniques avec un sens de l'humour sec 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'aiment pas Scrum.

Peut-être que le meilleur plan d'action serait d'essayer de parler à certains d'entre eux de manière 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 à un Product Owner à la place. Le Product Owner représente les intérêts des actionnaires vis-à-vis de l'équipe, organise les livrables du sprint au début de celui-ci, accepte les résultats à la fin, et clarifie les choses sur les demandes de l'équipe en attendant. Il est essentiellement un proxy 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û être limitée à votre rôle vis-à-vis de l'équipe au sein du modèle Scrum.

La question est donc: Où vous situez-vous sur cette image? Quel est votre rôle au sein du modèle Scrum? Comme c'était vous l'idée d'essayer Scrum en premier lieu, vous avez certainement fait des recherches sur Scrum et y réfléchi avant de suggérer non?

Et si vous ne l'avez pas fait, il est temps de le faire maintenant . Sans doute, la transition la plus transparente pour un responsable s’il n’est pas considéré comme faisant partie de l’équipe lors du passage à Scrum est le Product Owner. Vous continuerez à faire le même chose - mais maintenant, l'équipe répond à vous collectivement plutôt qu'à chaque membre individuellement, et vous arrêtez de les microgérer à moins qu'ils ne le demandent spécifiquement (ce dernier est sans doute une bonne chose pour les deux parties).

Voyant que vous avez apparemment fait un échec critique de recherche en suggérant Scrum, je pense que vous n'avez pas arrangé pour un Product Owner dédié - vous êtes donc exactement en mesure d'assumer ce rôle maintenant.

Cela ne nie pas le fait que le Scrum Master soit n'a aucune idée de ce qu'il fait, soit est après votre travail - quelles autres réponses couvraient de manière adéquate comment s'y prendre.

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 d'autonomisation des équipes de l'agilité?

Depuis quand 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 peut être plus grave que la simple méthode agile.

C'est quelque chose de critique pour un gestionnaire et vous devez y remédier, cela devrait être votre priorité numéro un pour les semaines à venir.

Vos n + 1, n + 2 sont en congé pour plusieurs mois? peut-être que cela a incité votre équipe à se rebeller. Quelle est la situation financière de votre entreprise? (si c'est mauvais, 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: "Scrum Master m'a dit que vous voulez pour me virer, que se passe-t-il? ". (il est très important que vous adressiez le sujet à tout le monde car ils le savent tous et si cela affecte le travail quotidien) .- Identifiez le vrai problème (seulement cette méthode agile ou vous avez un problème avec l'équipe avant?) .- une fois que vous savez le vrai 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 de propos, vous devez prendre des mesures disciplinaires.

Je ne suis pas sûr de ce que signifie un «manager» dans votre entreprise, mais en général, je pense que cela signifie quelqu'un qui aide les équipes aux besoins et augmente leurs performances. Maintenant:

Je suis un fervent partisan de l'agilité, alors j'ai embauché un Scrum Master et j'ai dit que nous suivrions Scrum.

Cela ressemble plus à «j'ai une bonne idée», je veux que vous le fassiez. Au lieu de consolider d'abord l'équipe sur 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 être d'accord pour la laisser tomber.

Il n'est pas sûr que l'idée soit maintenue peut indiquer à 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 encore rencontrer de la résistance, mais probablement pas autant que vous en avez maintenant.

Je pense pour résumer: Vous êtes leur manager, pas leur patron . ce sont deux emplois très distincts!

Soit: a) Ils ont raison et vous n'avez pas justifié votre existence. (Ils ne peuvent toujours pas vous renvoyer) Orb) Le Scrum Master veut votre travail.

Je pense que la meilleure chose à faire pour vous est d'aller suivre un cours de Scrum Master de 2 jours et de vous débarrasser de votre Scrum Master . Vous pourrez alors probablement obtenir un bonus à la fin de l'année pour avoir fait deux jobs.

"Le code est plus ce que vous appelleriez des" directives "que des règles réelles." - Capitaine Barabossa

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

Je ' J'ai souligné à l'équipe les avantages des équipes auto-organisées et de l'autonomisation des équipes.

Expliquez à vos enfants que l'auto-organisation et l'autonomisation ne signifient pas qu'ils doivent le faire tout ce qu'ils veulent. Si votre équipe décide d'aller voler des armes automatiques et de braquer une banque, vous n'êtes pas obligé de les suivre simplement parce qu'elles sont habilitées.

Ils ne peuvent pas vous "tirer". C'est le rôle de votre manager. Le tir vient toujours du haut de la chaîne, pas du bas. Bien sûr, ils peuvent sauter des échelons dans la hiérarchie et travailler avec votre patron pour vous retirer, mais comme apparemment votre patron et votre patron sont tous deux en congé sans avoir mis personne en place en leur absence, il n'y a pas une grande hiérarchie à laquelle aller. Vous avez quelques mois.

J'ai dit au Scrum Master que j'aimerais en parler à l'équipe, mais il était ferme qu'ils se sentaient "intimidés" quand j'étais la salle, et je ne voulais 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é d'être à la hauteur de ces décisions. Si j'avais une équipe comme celle-là, leur parler serait le niveau de réponse le plus gentil que j'envisagerais.

On pourrait dire "Oh, mais le maître SCRUM est censé résoudre les obstacles comme celui-ci. Tout doit passer par lui. " Eh bien dur. Il a foiré cela quand il est allé vous voir pour vous dire que vous aviez été congédié et ne l'a pas fait d'une manière suffisamment courtoise pour que vous l'acceptiez. On s'attend à ce qu'un maître SCRUM ait de meilleures compétences en relations humaines que cela.

Alors qu'en dites-vous?

Tout d'abord, vous voulez savoir s'ils ont réellement décidé de vous «renvoyer». Vous avez la parole d'une personne à ce sujet, et je pense que c'est le genre de situation où l'équipe devrait être en mesure de dire directement son article.

Deuxièmement, réfléchissez à ce que signifie «tirer». Vous prétendez être un gestionnaire sans intervention, mais ils veulent que vous partez. Comprenez pourquoi. Ils n'écrivent pas les chèques de paie, donc la décision de vous licencier n'est pas une décision du genre "oh ils ne font pas leur poids". C'est une décision du genre «cette personne s'oppose activement». Quelque chose vraiment ne s’additionne pas ici. Vous avez besoin que cela s’additionne pour vous avant de prendre des décisions significatives. Étant une personne anonyme sur Internet, je ne peux pas dire si c'est vous ou eux ou le maître SCRUM, mais quelque chose est vraiment vraiment faux dans ce scénario, et vous feriez mieux de savoir ce que c'est par le lorsque vous avez 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. Faites en sorte que cela se produise.

Maintenant, si leurs réponses vous fournissent une clôture suffisante pour honorer leur autonomie, maintenant vous devez montrer à l'équipe ce qui se passe lorsque vous «renvoyez» le leadership comme ça. Dites "Très bien. Je vais arrêter d'agir en tant que votre manager. Vous ne pouvez pas en fait me renvoyer, car ce n'est pas votre position, mais si vous voulez jouer à ce jeu, nous pouvons jouer. J'étais votre directeur, vous aidant à vous isoler de la politique d'entreprise et du stress lié au reporting à la haute direction. Maintenant, je suis votre haute direction, et vous n'avez plus cette isolation. Maintenant que je ne peux pas vraiment me retirer de ce poste, je vais simplement commencez à relayer les tâches d'en haut. " Expliquez que ce n'est pas parce que l'équipe a voté que vous n'avez pas d'obligations envers la haute direction que vous devez remplir et que vous continuerez à le faire.

Ensuite, demandez de l'aide.

Une mutinerie n'est pas une mince affaire. Toute votre équipe vient de vous élire hors de l'île. Ne le sous-estimez pas. Faites appel à quelqu'un au-dessus de vous pour vous aider. Peut-être que vous appelez votre patron en congé. Peut-être que vous parlez à votre CIO. Quelqu'un a besoin de savoir qu'il existe un problème de personnel majeur dans votre entreprise, et que vous êtes en train de le résoudre. La seconde moitié est clairement importante. N'allez jamais au leadership avec des problèmes, allez-y avec des solutions.

La solution que je recommanderais est de façonner votre image en tant que "gestionnaire portant les exigences" en choisissant les choses qui exigent ce que le leadership (c'est-à-dire le CIO) voudrait , qui est conçu pour créer une certaine réalisation de soi pour accompagner cette autonomisation. Ils peuvent penser qu'ils sont libres de faire ce qu'ils veulent, mais vous êtes toujours obligé de faire d'eux une équipe performante. Si vous devez le faire de loin, faites-le de loin. Découvrez en quoi votre approche participative était si intimidante et assurez-vous de ne jamais le faire.

L'objectif final est de leur faire comprendre que vous êtes de leur côté. S'ils sont vraiment autonomes, ils doivent alors réaliser que vous faites partie de l'équipe. Ils ne parviendront à cette réalisation que s'ils réussissent. S'ils sont submergés par des délais impossibles et des formalités administratives sans espoir, ils ne le verront jamais.

Assurez-vous simplement que tout s'additionne. 2 + 2 = 4. Un manager «sans intervention» est «congédié» par le nouveau maître SCRUM pour avoir été trop intimidant alors que deux niveaux de direction sont en congé? Quelque chose ne va pas à partir d'ici. Vous êtes plus proche de la situation. Déterminez ce qui ne va pas et corrigez-le.

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

Si elle vous considère comme un obstacle, découvrez pourquoi - le scénario probable est interféraient, et la solution est que vous les laissiez faire leur travail.

En quoi vous pensez-vous que votre rôle dans l'équipe? Trouvez une réponse utile qui correspond aux objectifs de la mêlée, puis insistez auprès de l'équipe sur le fait 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 responsable .

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

• Vous êtes en mesure de tenir l'équipe responsable des engagements de l'entreprise plus facilement. S'ils ne peuvent pas atteindre les objectifs de l'entreprise, ils ne peuvent tout simplement pas être autonomes.
• Vous êtes en mesure de développer les compétences de l'équipe. Vous pouvez désormais vous concentrer davantage sur l'aspect humain de l'équipe. Croissance de carrière, habilitation et ce genre de choses.
• Sachez que l'équipe et le scrum master sont toujours responsables devant vous dans la hiérarchie de l'entreprise, les budgets et le processus d'évaluation des performances. Donc ce n'est pas comme s'ils pouvaient passer au-dessus de votre tête.

Pensez donc à cela comme un succès pour l'instant. Pensez davantage aux possibilités de renforcer l'équipe. Sachez également que vous devez être là pour le scénario où cette approche d'autogestion échoue.

Lao Tzu a dit

Le chef méchant est celui que le peuple méprise,

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

Lorsqu'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 objectif 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 quoi faire, alors je ne suis pas nécessaire et mon travail est mieux servi de cette façon - profiter de la vie en dehors du bureau.

Vous suivez les métriques, vérifiez leur code, vous faites de légères corrections de cap, vous encouragez & à activer tout ce qui a besoin d'encourager et de permettre - communication, coopération, rédaction de tests, etc., vous les protégez des clients d'& de la haute direction - et idéalement vous n'agissez jamais.

Mais quand vous le faites, vous le faites et vous botter le nez quand c'est nécessaire, vous êtes le gars qui est responsable de leur travail, après tout - les gens sont renvoyés sur votre recommandation et vous devriez le renvoyer, et à temps.

Je ne sais pas pourquoi un développeur le ferait renvoyer quelqu'un qui n'est pas sur leur chemin et qui est fondamentalement là pour réparer les choses pour eux et les protéger des clients et parfois même des supérieurs, s'occupe de la disponibilité de l'équipement, de la documentation, des coups de coude toujours légèrement pour être de meilleurs programmeurs et mieux les gens et leur permet de se concentrer sur le code.

Vous êtes toujours leur h Plus haut - vous pouvez toujours les tirer si vous en avez besoin, vous n'avez pas été renvoyé de cette position. Vous avez simplement été jugé inutile ou nuisible à l'effort de développement et ils préfèrent jouer sans vous.

Soit ceci, soit il y a une pathologie sérieuse en cours avec la culture d'équipe.

Je disent que c'est une formidable opportunité de réflexion et de croissance.

Je peux voir deux points de vue ici:

• Vous étiez le supérieur hiérarchique d'une équipe de développement dans une organisation matricielle, et vous êtes toujours le supérieur hiérarchique. Votre travail a peut-être un peu changé, mais c'est fondamentalement le même - vous fournissez des jours-homme de développeur au PO conformément aux processus de budgétisation / RH de l'entreprise, vous vous occupez de l'embauche (et si nécessaire, du licenciement), vous planifiez part en coopération avec l'équipe, et ainsi de suite.
  Dans le développement agile, votre rôle peut être un peu moins compliqué qu'auparavant, mais surtout s'il y a plusieurs équipes Scrum, votre rôle comprendra désormais des éléments comme encourager les «communautés de pratique» ou les «guildes». Comme tout, la mêlée peut être nocive si elle est poussée à l'extrême, et quelqu'un doit faire attention, par exemple. 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 direction hiérarchique dans une telle organisation.
• Vous étiez un membre de l'équipe de développement et vous aviez une contribution directe aux décisions technologiques, à l'architecture, etc. Dans ce cas, je suggérerais que vous vous trompiez en ne vous impliquant pas suffisamment dans ce premier sprint, car ils ne voient pas comment vous apporterez vos compétences à l'équipe. Au prochain sprint, travaillez avec l'équipe.

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

Je suis un fervent partisan de l'agilité

Bien! Si par "agile" vous entendez "Scrum" (pourquoi auriez-vous embauché un Scrum Master, sinon ...), alors tout va bien.

Ils ont toujours suivi une méthodologie en cascade et ont résisté au changement.

l'équipe a collectivement accepté de me «renvoyer» en tant que manager

Bien! Ils ont changé leurs habitudes; ils ont abandonné leur résistance (vous ne nous avez pas dit à quoi ils résistaient, avant ...). Ils ont appris les rôles entourant une équipe Scrum.

Comme vous le savez sûrement, un manager n'a qu'une responsabilité très éloignée dans le contexte d'une équipe Scrum; vous n'êtes ni le Scrum Master, ni le Product Owner, ni l'une des parties prenantes, ni une partie de l'équipe Scrum 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'était même pas sur le graphique.

Si votre entreprise utilise la structure matricielle typique de la gestion de ligne verticale par rapport à la gestion horizontale liée au projet (ou liée au produit) (c'est-à-dire le responsable hiérarchique <> chefs de projet / produit), alors tout semble se dérouler comme prévu. Vous aurez toujours des responsabilités de gestion, c'est-à-dire de 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 fervent partisan de l'agilité

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

En fonction de ce que vous faisiez auparavant dans votre travail quotidien (distribuer des packages de travail à des développeurs individuels), vous voudrez peut-être examiner 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 Product Owner 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 clients (ventes, etc.). Vous serez un partenaire et un bouclier pour votre équipe en cas d'escalade. Vous gérez . La gestion n'est pas la même chose que le développement de logiciels; et l'attribution de 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 truc. Évitez de gérer leur nouveau Scrum à distance; Scrum a été conçu exactement pour rendre l'équipe autosuffisante et capable de fonctionner sans microgestion constante de l'extérieur. De nombreuses parties de Scrum sont conçues 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 géreront beaucoup de choses que vous aviez à faire auparavant. Tout le monde peut être très heureux à partir de maintenant, surtout s'il n'aimait pas votre microgestion avant.

l'équipe a collectivement accepté de me «renvoyer» en tant que manager

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