¿Cómo puedo recuperar el control gerencial de mi equipo "auto-organizado"?

Le das al scrummaster una mirada extraña, y le dices “adiós Felicia”, y al día siguiente llamas a una reunión de todo el equipo y les preguntas de qué diablos se trataba esa tontería.

Si esto realmente sucediera, entonces despediría al idiota del scrummaster en un minuto de Nueva York. Este maestro de scrummaster es peligroso, poco profesional y muy poco apto para su trabajo. La forma de “despedir a tu manager” es renunciar: básicamente es una renuncia para todo el equipo.

No entiendo por qué estás preocupado. Todos están bajo tu mando en la jerarquía, y no tienen el poder de despedirte.

Más importante, tienes que averiguar qué demonios está pasando. El maestro de scrum podría necesitar ser despedido dependiendo de la situación.

Hazlo antes de que sea demasiado tarde, antes de que tu jefe (o CIO) te diga lo mismo.

Aunque he trabajado con varios equipos que han seguido este mismo curso de acción, no parece que esto se haya manejado con el cuidado que merece. Me gustaría compartir lo que he visto para ver si ayuda a darle una avenida hacia adelante.

Primero, Scrum alienta a los equipos auto-organizados. Lo que la guía Scrum dice específicamente sobre los equipos auto-organizados es esto:

Son auto-organizados. Nadie (ni siquiera el Scrum Master) le dice al equipo de desarrollo cómo convertir el atraso del producto en incrementos de funcionalidad potencialmente liberable;

Eso, junto con mucho más acerca de ser interfuncional y de amplia responsabilidad, tiene como objetivo alentar a los miembros del equipo a hacerse preguntas difíciles acerca de cuán bien están configurados para responder a cualquier solicitud que les llegue. Definitivamente vale la pena leer la Scrum Guide - es corta.

En cuanto a un gerente, si has encontrado que tu trabajo en el pasado ha sido asignar tareas y rastrear elementos de trabajo, Scrum te pide que des un paso atrás de esto. Francamente, si el Scrum Master no te habló de esto mucho antes de la primera retrospectiva, puede que haya sido un poco de mala suerte por su parte. La dura realidad es que muchos equipos que están acostumbrados a que un gerente les organice sus tareas no están bien preparados para saltar a este enfoque. Si sientes que tu equipo está en esta situación, te recomiendo que hables con el Scrum Master sobre ello. Hay muchas técnicas para facilitar esta transición. En particular, yo miraría la Escalera de Liderazgo de David Marquet y tal vez incluso su libro Turn the Ship Around. Verás que en ambos, ningún gerente es despedido.

Por último, veamos por qué querrías hacer esta transición si has tenido éxito dirigiendo a la gente en el pasado. La versión corta es que tendrás aún más éxito ayudándoles a aprender a manejarse a sí mismos. Hay tanta investigación y datos sobre esto que es difícil saber por dónde empezar, pero diré que es un hecho bastante bien demostrado que todas las personas son potencialmente capaces de auto-organizarse y en un equipo de, digamos, diez, once cerebros (el tuyo incluido) siempre resolverán los problemas de manera más efectiva que uno y teniendo otros diez a un lado esperando a echarte la culpa si la solución es incorrecta.

He visto muchos gerentes exitosos en entornos Scrum. Siempre advertiría a un equipo contra el “despido” directo de uno. Incluso si eres intimidante como dice tu pregunta y manejas cada tarea frente a ellos, he trabajado con muchos gerentes como ese que siguen siendo activos increíbles para el equipo. En estos equipos auto-organizados, pasas de pasar todo tu tiempo dirigiendo las acciones del equipo a asegurarte de que el camino para que tengan éxito está claro y siempre sale mejor en general con equipos que dan más y gerentes que tienen una reputación de crear estrellas de rock.

Buena suerte, espero que esto te dé algunos ángulos con los que trabajar.

• En el contexto del scrum: ¿Qué dice el propietario del producto? No es función del maestro de scrum pedir más (o menos) recursos. Es algo que el propietario del producto debe alinear con las partes interesadas

• En el contexto del scrum: Una retrospectiva es sobre el proceso y el equipo y el proyecto (no sobre “cómo me siento sobre mi jefe”). Si eras parte del equipo, deberías haber sido invitado. Si no eras parte del equipo, la retrospectiva debería haber tratado sólo de tu papel en el proyecto.

• Los maestros de scrum que le dicen a los gerentes de línea lo que deben hacer son al menos tan absurdos como los gerentes de línea que se involucran en el scrum directamente

• Así que el maestro de scrum claramente sobrepasó sus límites. Su función era mantener la retrospectiva enfocada en la identificación de problemas específicos que necesitan ser tratados.

Cómo proceder:

• Hablas con el equipo en sesiones individuales y les preguntas qué está pasando. Explicas claramente que el maestro de scrum es no una función de línea y que él no no reúne a los equipos. También pregúntales dónde creen que deberías haberte mantenido al margen de los asuntos diarios

• Deja claro al equipo a quién deben dirigirse los problemas

• Vas al siguiente en la fila (si es el CIO, es el CIO - no es aceptable que no tengas un manager durante meses), diciendo que la situación debe resolverse inmediatamente (despidiendo al maestro de scrum o el CIO teniendo una palabra con él de que será despedido en el curso actual), de lo contrario se pone en peligro el proyecto, a mí me parece que el maestro de scrum no entiende sus deberes y límites. Una respuesta profesional al equipo tratando de “despedir” a su gerente como parte de una retrospectiva habría sido “No es mi negocio resolver la relación entre usted y su jefe, y definitivamente no es para lo que el proyecto nos paga”.

He recalcado al equipo los beneficios de la auto-organización de los equipos y la potenciación del equipo.

Bueno, ciertamente se tomaron _ esa_ parte a pecho.

Parece claro que estás en una situación muy emocional en este momento. Aparentemente, tu equipo tiene algunos problemas importantes con la relación actual entre tú y ellos. Probablemente fue bueno que no estuvieras en la retrospectiva, porque esa suele ser la razón por la que la gente de repente está dispuesta a hablar sobre lo que realmente les molesta. Si están dispuestos a hacerlo alrededor de un Scrum Master con el que han estado trabajando sólo por unas pocas semanas, entonces ya confían en el tipo o están tan molestos que realmente no les importan las consecuencias.

De cualquier manera; este no es un nuevo problema que apareció de repente cuando te cambiaste a Scrum o contrataste a una nueva persona. Es un problema que se ha enconado sin ser visto durante mucho tiempo. A menudo se dice que el trabajo Agile no crea tanto nuevos problemas, sino que hace que los ya existentes sean extremadamente obvios. Este es probablemente un caso de eso.

Dicho esto; tu Scrum Master dejó caer la pelota, con fuerza. Es su trabajo ayudar al equipo a crecer hacia la auto-organización, seguro. Pero esta no es la manera correcta. Por un lado, no puede despedirte y decirte “esto es lo que el equipo quiere” no es nada constructivo. No estoy seguro de lo que él piensa que va a ser el resultado de esto, pero no puede ser lo que el equipo piensa que es.

Además, eliminar a la gente es la decisión más difícil que un equipo o Scrum-Master ) puede hacer y nunca debe nunca tomarse a la ligera y sin hablar (repetidamente) con los involucrados. No puedes salir y remover a alguien que no tiene idea de que alguien tiene un problema con ellos. Por lo menos, va a dejar a todos con el temor de que si se pierden una retrospectiva, podrían volver de repente al trabajo y descubrir que han sido expulsados del equipo. Va a crear una atmósfera de miedo, no de confianza. Una atmósfera de confianza y apertura es lo que quieres cuando trabajas con Agile.

Así que con tu Scrum Master fallando en trabajar en una atmósfera abierta (al menos fuera del equipo; parece que ha conseguido que la gente se abra bastante internamente) y no buscando una solución constructiva, parece que te toca a ti hacerlo.

En este punto, no creo que nada basado en la autoridad vaya a ser útil. Scrum y Agile se trata de capacitar a la gente para que haga lo suyo, y afirmar tu autoridad en este punto probablemente termine con el despido de todo el equipo. El equipo ya ha declarado que están en el punto en el que quieren que la gente se vaya, así que aunque se hayan equivocado con la persona, el enfrentamiento con ellos probablemente terminará con al menos unas pocas personas que se vayan. (Y recuerden la regla más importante sobre la partida: las personas más valiosas serán las primeras en irse.)

Así que si realmente quieres hacer un Scrum con este equipo, aquí es donde tienes que aceptar su capacidad de decidir cómo quieren trabajar y tener una discusión abierta sobre cómo quieren organizar su equipo. No pueden despedirte, pero dejaron muy claro que lo que estás haciendo ahora no funciona para ellos. Necesitas tener una charla sobre cuál será tu papel en el futuro, qué necesitan de ti, qué necesitas de ti, y cómo se va a organizar todo eso. Tengan en cuenta que ellos deciden cómo trabajan, pero en última instancia todavía hay un producto que necesita ser entregado; ellos _serán juzgados por la calidad de lo que entregan. Y si hay cosas de organización que necesitas de ellos, ellos tendrán que hacer esas cosas también. (Dicho esto; trabajar con ellos en la forma de esas cosas, y asegurarse de que son realmente necesarias antes de hacerlas cumplir).

Asegurarse de que en esa reunión, no se aborden las cosas desde su autoridad; la idea es conseguir que todos estén al mismo nivel. Ustedes son colegas e individuos que tienen un trabajo que hacer, todos quieren hacer un buen trabajo, y todos tienen que trabajar juntos en el día a día. Ser un autoritario normalmente sólo hace que las personas sean antagónicas entre sí, lo cual no es productivo. Así que trata de ser vulnerable y estar dispuesto a admitir las cosas que hiciste mal. Necesitas averiguar cómo seguir desde aquí como seres humanos.

Suena como si tu equipo golpeara la Fase de Tormenta de su desarrollo como equipo, y lo golpearon duro. Ahora depende del equipo (y te incluyo en él, al menos por ahora) para averiguar cómo ir desde allí. Estén advertidos; no todos los equipos salen de esta fase y no puedo prometer que este enfoque vaya a solucionar el problema. Puedo garantizar que no será peor que renunciar o despedir a todos, sin embargo.

Y asegúrate de tener una charla con el Scrum Master por separado. No estoy seguro de qué lo hizo abrir con un primer mensaje tan poco constructivo, pero necesita trabajar en sus habilidades de comunicación y de resolución de problemas.

Buena suerte con su situación. Ciertamente vives en tiempos interesantes; saca lo mejor de ellos y aprende lo que puedas de esto.

(También asumo aquí que el Scrum Master no conseguirá que todo el equipo se revuelva contra ti sin algunos problemas serios de fondo. Si puede y está buscando tu trabajo, es un maestro manipulador. Tan pronto como llegues al punto en el que crees que eso es lo que está pasando, tienes que deshacerte del tipo asap. Ese es probablemente el único caso en el que consideraría usar tu autoridad como la persona que lo contrató y despedir al tipo).

Ya sea que tengan o no el poder real de despedirte como su gerente, tú provocaste esta situación al ordenar un cambio en el scrum simplemente porque lo prefieres. No lo discutiste con ellos. Usted podría haber estado dentro de sus derechos como gerente, pero sin embargo fue una tontería, y por supuesto ahora se cuestionan si quieren trabajar más para usted.

¿No ve el sarcasmo en su afirmación de auto-empoderamiento y auto-organización como su base para tomar tal acción?

Necesita convocar una reunión mañana a las 9:15am y disculparse por tomar una decisión tan importante sin tomar en cuenta su aporte. Luego puede pedirles su opinión sobre cómo pensaron que fue su primer sprint y qué se podría haber hecho de forma diferente.

Si quiere introducir un nuevo flujo de trabajo en el proceso de este equipo, puede intentarlo a una escala más pequeña, con tareas específicas como un programa piloto, con unos pocos miembros selectos del equipo que sean lo suficientemente abiertos para darle una evaluación justa.

Con empleados capacitados, es mejor persuadir, incluir y animar que obligar.

Una perspectiva diferente: ¿se te ocurrió que simplemente se están burlando del proceso de Scrum y su aspecto “auto-organizado”? Francamente, no puedo imaginar que fueran en serio y se rieran mientras leían tu post. Los desarrolladores de software (yo soy uno de ellos) tienden a ser personas bastante cínicas con un sentido del humor seco que no a todo el mundo le gusta o ni siquiera reconoce. Estoy seguro de que simplemente te estaban diciendo que no les gusta Scrum.

Tal vez el mejor curso de acción sería tratar de hablar con algunos de ellos informalmente sobre Scrum y las razones por las que no les gusta.

Como @Sascha observó correctamente , esto no se parece en nada a Scrum:

• Un equipo de Scrum no tiene un gerente, sino que responden al dueño del producto. El dueño del producto representa los intereses de los accionistas con respecto al equipo, organiza las entregas para el sprint al comienzo del mismo, acepta los resultados al final y aclara las cosas sobre las peticiones del equipo mientras tanto. Es esencialmente un apoderado entre el equipo y la compañía.
• Si fueras parte del equipo Scrum, asistirías a una reunión retrospectiva. Si no eres parte del equipo Scrum, la reunión debería haberse limitado a tu papel con respecto al equipo dentro del modelo Scrum.

Entonces, la pregunta es: ¿Dónde te encuentras en esta foto? ¿Cuál es su papel dentro del modelo Scrum? ** Ya que fue **usted cuya idea de probar Scrum fue en primer lugar, definitivamente ha investigado Scrum y pensado en esto antes de sugerirlo, no?

Y si no lo hizo, es hora de hacer esto ahora. Seguramente, la transición más perfecta para un gerente si no se le considera parte del equipo al pasar a Scrum es el Propietario del Producto. Seguirás haciendo lo mismo - pero ahora el equipo te responde colectivamente en lugar de cada miembro individualmente, y dejas de microgestionarlos a menos que ellos lo pidan específicamente (esto último es sin duda algo bueno para ambas partes).

Viendo que aparentemente usted ha hecho un fallo crítico de investigación al sugerir Scrum, creo que no ha conseguido un propietario de producto dedicado – así que está exactamente en posición de asumir este papel ahora.

** Esto no niega el hecho de que el Scrum Master no tiene ni idea de lo que está haciendo, o está detrás de su trabajo** – que otras respuestas cubrieron adecuadamente cómo hacerlo.

¿Cómo puedo desactivar esta situación y restablecer mi autoridad como su gerente, mientras me mantengo fiel a los principios de auto-organización y potenciación del equipo de ágiles?

¿Desde cuándo eres el gerente de este equipo? No creo que un equipo se rebele contra el gerente directo por un desacuerdo sobre un solo tema. El tema podría ser más grave que sólo el método ágil.

Esto es algo crítico para un gerente y necesitas abordarlo, debería ser tu prioridad número uno para las próximas semanas.

Tus n+1, n+2 están de licencia por varios meses… tal vez influyó en tu equipo para rebelarse. ¿Cuál es la situación financiera de su empresa? (si es mala, los empleados podrían pensar que está haciendo un mal trabajo y pueden hacerlo mejor sin usted).

qué hacer : - organizar una reunión con todo el equipo : “el scrum master me ha dicho que quiere despedirme, ¿qué está pasando?”. (es muy importante que abordes el tema con todo el mundo ya que todos lo saben y si afecta al trabajo diario). -Identificar el verdadero problema (sólo este método ágil o tienes algún problema con el equipo antes?). -Una vez que conoces el problema real, necesitas investigar: ¿Quién tiene razón? ¿Tú o tus empleados? -Identificar quién es el líder de esta rebelión (siempre hay un empleado que desafía a las autoridades más que los demás). Si cree que está fuera de lugar, debe tomar medidas disciplinarias.

No estoy seguro de lo que significa un “gerente” en su empresa, pero en general creo que significa alguien que ayuda a las necesidades de los equipos y aumenta su rendimiento. Ahora:

Soy un gran defensor de lo ágil, así que contraté a un maestro de scrum y dije que seguiríamos el scrum.

Suena más como ‘tengo una gran idea’ quiero que ustedes la hagan. En lugar de consolidar el equipo primero sobre su idea. Creo que todos los equipos tienen el derecho de criticar su idea y hacer agujeros en su idea. si su idea no se sostiene, debería estar bien dejarla caer.

No es seguro que la idea se sostenga puede decirle al equipo que quiere un período de prueba y/o migrar lentamente a la nueva estructura del proyecto.

De esta manera podría encontrar todavía resistencia pero probablemente no tanta como la que tiene ahora.

Creo que para resumir: Eres su manager, no su jefe. ¡Son dos trabajos muy distintivos!

“El código es más lo que llamarías "directrices” que reglas reales". - Capitán Barabossa

Me parece que tienes un gran problema, y estás tratando de mantener algunos ideales irracionales.

He recalcado al equipo los beneficios de la auto-organización de los equipos y la potenciación del equipo.

Explica a tus hijos que la auto-organización y la potenciación no significa que puedan hacer lo que quieran. Si su equipo decide ir a robar algunas armas automáticas y robar un banco, no están obligados a seguir con ellos sólo porque tienen poder.

No pueden “despedirlos”. Ese es el papel de tu manager. Los disparos siempre vienen de arriba de la cadena, no de abajo. Claro, pueden saltar escalones en la jerarquía y trabajar con tu jefe para removerte, pero como aparentemente tu jefe y el jefe de tu jefe están ambos de licencia sin haber puesto a cualquiera en su lugar en su ausencia, no hay mucha jerarquía a la que ir. Tienes unos meses.

Le dije al maestro de scrum que me gustaría hablar con el equipo sobre esto, pero fue firme en que se sintieron “intimidados” cuando yo estaba en la habitación, y no querían discutirlo conmigo.

Bueno, eso es muy malo para ellos. Hable con ellos de todos modos. El autocontrol puede darte la capacidad de tomar tus propias decisiones, pero no te libera de la responsabilidad de estar a la altura de esas decisiones. Si tuviera un equipo como ese, hablar con ellos sería el nivel de respuesta más amable que consideraría.

Uno podría decir “Oh, pero el maestro de SCRUM se supone que debe resolver impedimentos como este. Todo debería pasar por él”. Bueno, es difícil. Lo arruinó cuando fue a decirle que estaba despedido y no lo hizo de una manera suficientemente cortés como para que usted lo aceptara. Se espera que un maestro de SCRUM tenga mejores habilidades con la gente que eso.

Entonces, ¿qué dices?

Primero, quieres saber si realmente decidieron “despedirte”. Tienes la palabra de una persona sobre eso, y creo que este es el tipo de situación en la que el equipo debería ser capaz de decir directamente su pieza.

Segundo, considera lo que significa “despedir”. Afirmas que no eres un gerente, pero ellos quieren que te vayas. Entienda por qué. No están escribiendo los cheques de pago, así que la decisión de despedirte no es una decisión del tipo “oh, no están haciendo su trabajo”. Es una decisión del tipo “esta persona se está interponiendo activamente”. Algo que realmente no tiene sentido aquí. Necesitas que se sume para ti antes de tomar cualquier decisión significativa. Siendo una persona anónima en Internet, no puedo decir si eres tú o ellos o el maestro de SCRUM, pero algo está realmente mal en este escenario, y es mejor que sepas lo que es para cuando termines de hablar con ellos. Sé un gerente. Encuentra una manera de resolver el problema. Encuentra una manera de que puedas hacer tu trabajo, mientras ellos hacen el suyo. Haz que suceda.

Ahora, si sus respuestas te dan el cierre suficiente para honrar su auto-empoderamiento, ahora tienes que mostrarle al equipo lo que sucede cuando “despides” el liderazgo de esa manera. Digan “Bien. Dejaré de actuar como tu manager. No puedes en realidad despedirme, porque esa no es tu posición, pero si quieres jugar este juego, podemos jugar. Yo era tu manager, ayudándote a aislarte de la política corporativa y el estrés de informar a la alta dirección. Ahora, soy tu gerente superior, y ya no tienes ese aislamiento. Ahora, como no puedo quitarme de esta posición, simplemente empezaré a transmitir tareas desde arriba.” Explique que sólo porque el equipo haya votado, no significa que no tenga obligaciones con la alta dirección que tenga que cumplir, y seguirá haciéndolo.

Entonces, busque ayuda.

Un motín no es algo pequeño. Todo tu equipo acaba de expulsarte de la isla. No lo subestimes. Consigue a alguien por encima de ti para que te ayude. Tal vez llames a tu jefe de permiso. Tal vez hables con tu CIO. Alguien tiene que saber que hay un problema de gente importante en tu empresa, y que lo estás resolviendo. La segunda mitad es claramente importante. Nunca vayas al liderazgo con problemas, ve a ellos con soluciones.

La solución que yo recomendaría es crear tu imagen como el “gerente que lleva los requisitos” eligiendo cosas que requieren que el liderazgo (es decir, el CIO) quiera, que se crea para construir algo de auto-realización para ir con este auto-empoderamiento. Si tienes que hacerlo desde lejos, hazlo desde lejos. Averigua qué es lo que te intimida de tu enfoque de no intervención y asegúrate de no hacerlo nunca.

El objetivo final es que se den cuenta de que estás de su lado. Si ellos están realmente auto fortalecidos, entonces necesitan darse cuenta de que tú eres una parte beneficiosa del equipo. Sólo se darán cuenta de ello si tienen éxito. Si se llenan de cosas imposibles… los plazos y la burocracia sin esperanza, nunca lo verán.

Sólo asegúrate de que todo suma. 2+2=4. ¿Un gerente “sin manos” es “despedido” por el nuevo maestro de SCRUM por ser demasiado intimidante mientras dos niveles de la gerencia están de licencia? Algo no tiene sentido desde aquí. Estás más cerca de la situación. Averigua lo que no tiene sentido y arréglalo.

Cualquiera de los dos: a) Tienen razón y usted no ha justificado su existencia. (Todavía no pueden despedirte) o b) El maestro de scrum quiere tu trabajo.

Creo que lo mejor que puedes hacer es ir a hacer un curso de 2 días de maestro de scrum y deshacerte de tu maestro de scrum. Entonces probablemente puedas obtener un bono al final del año por hacer dos trabajos.

No hay un papel de gerente en un equipo de scrum. La verdadera pregunta es por qué pensaste que eras un miembro del equipo en primer lugar. Si no estás participando en la entrega de la película, no tienes lugar en ese equipo, así que lo que el equipo hizo fue correcto.

Si ellos te consideran un impedimento, averigua por qué - el escenario probable es que estabas interfiriendo, y la solución es que no te metas y les dejes hacer su trabajo.

¿Qué crees que es tu papel en el equipo? Piense en una respuesta útil que esté alineada con los objetivos del scrum, y luego enfatice al equipo que usted tiene la intención de hacer ese trabajo, y no interferir con el suyo.

Así que no veo por qué no puedes ver esto como algo positivo. Mi entendimiento es que el objetivo de un equipo autogestionado es no necesitar un manager.

Lo que necesitas hacer es mirar las oportunidades que esto presenta. Básicamente tienes un súper equipo que puede autogestionarse y ahora eres capaz de hacer lo siguiente:

• Eres capaz de hacer que el equipo sea responsable de los compromisos de la empresa más fácilmente. Si no pueden cumplir con los objetivos de la empresa, entonces simplemente no pueden ser autogestionados
• Eres capaz de hacer crecer las habilidades en el equipo. Así que ahora puedes enfocarte más en el aspecto humano del equipo. Crecimiento de la carrera, capacitación y ese tipo de cosas.
• Date cuenta de que el equipo + scrum master siguen siendo responsables ante ti en la jerarquía de la empresa, los presupuestos y el proceso de evaluación del rendimiento. Así que no es como si pudieran pasar por encima de tu cabeza.

Así que piensa en esto como un éxito por ahora. Piensa más en las oportunidades de cómo puedes fortalecer el equipo. También date cuenta de que necesitas estar ahí para el escenario en el que este enfoque de autogestión falle.

Lao Tzu dijo

El líder malvado es aquel a quien el pueblo desprecia,

El líder bueno es aquel a quien el pueblo venera,

Cuando un gran líder lidera, la gente dice “lo hicimos nosotros mismos”.

Un líder es mejor cuando la gente apenas sabe que existe,

cuando su trabajo está hecho, su objetivo cumplido,

dirán: lo hicimos nosotros mismos.

y he estado siguiendo esta máxima básicamente desde el día 1 de liderar equipos de desarrollo. Si todo el mundo sabe qué hacer, entonces no soy necesario y mi trabajo está mejor servido de esta manera - disfrutando de la vida fuera de la oficina.

Sigues las métricas, auditas su código, haces ligeras correcciones de curso, fomentas y permites lo que sea necesario fomentar y permitir - comunicación, cooperación, pruebas de escritura, etc., los proteges de la alta dirección y de los clientes - e idealmente nunca actúas. Pero cuando lo haces, lo haces y pateas narices cuando es necesario, tú eres el responsable de su trabajo, después de todo, la gente es despedida por recomendación tuya y tú deberías despedirla, y a tiempo.

No estoy seguro de por qué un desarrollador despediría a alguien que no está en su camino y que básicamente está ahí para arreglar las cosas por ellos y protegerlos de los clientes y ocasionalmente incluso de los superiores, se ocupa de la disponibilidad de los equipos, la documentación, los codigos, y les permite ser mejores programadores y mejores personas y centrarse en el código.

Sigues siendo su superior - todavía puedes despedirlos si lo necesitas, no te han despedido de este puesto. Sólo fuiste considerado inútil o perjudicial para el esfuerzo de desarrollo y ellos prefieren jugar sin ti.

Esto o hay alguna patología seria en la cultura del equipo.

Diría que es una oportunidad increíble para una gran reflexión y crecimiento.

Puedo ver dos puntos de vista aquí:

• Fuiste el gerente de línea de un equipo de desarrollo en una organización matricial, y sigues siendo el gerente de línea. Tu trabajo puede haber cambiado un poco, pero es fundamentalmente el mismo: proporcionas días-hombre de desarrollo al PO de acuerdo con los procesos de presupuesto/ RRHH de la empresa, te ocupas de la contratación (y si es necesario, del despido), programas los permisos en cooperación con el equipo, etc. En el desarrollo ágil, tu papel puede ser un poco menos loco de lo que solía ser, pero especialmente si hay múltiples equipos de scrum, tu papel ahora incluirá cosas como fomentar “comunidades de práctica” o “gremios”. Como todo, el scrum puede ser perjudicial si se lleva a los extremos, y alguien debe tener cuidado, por ejemplo, de que las pilas de tecnología sigan siendo compatibles a menos que haya una muy buena razón para hacer una excepción. Ese es el trabajo de la gerencia de línea en tal organización.
• Usted fue un miembro del equipo de desarrollo y tuvo una participación directa en las decisiones de tecnología, arquitectura, etc. En ese caso sugeriría que la cagaste al no involucrarte lo suficiente en este primer sprint, porque no ven cómo contribuirás con tus habilidades al equipo. En el siguiente sprint, trabaja con el equipo.

Soy el gerente de un equipo de desarrollo.

Soy un gran defensor de lo ágil

¡Bien! Si por “ágil” te refieres a “Scrum” (por qué habrías contratado a un Scrum Master, si no…), entonces todo está bien.

Históricamente han seguido una metodología muy cascada y se han resistido al cambio.

el equipo ha acordado colectivamente “despedirme” como su manager

¡Bien! Han cambiado su forma de actuar; han dejado de resistir (no nos has dicho a qué se resistían, antes…). Han aprendido los roles que rodean a un equipo de Scrum.

Como seguramente sabrás, un manager tiene una responsabilidad muy remota en el contexto de un equipo de Scrum; tú no eres ni el Scrum Master, ni el Propietario del producto, ni uno de los Stakeholders, ni parte del propio equipo de Scrum. Recuerdo cuando obtuve mi certificado de Scrum Master en un seminario de 3 días; el papel de “gerente” ni siquiera estaba en la tabla.

Si su empresa utiliza la típica estructura matricial de gestión de línea vertical frente a la gestión horizontal de proyectos (o productos) (es decir, gerente de línea <> gerentes de proyectos/productos), entonces todo parece ir según lo previsto. Seguirás teniendo responsabilidades de gestión, es decir, administrar todo lo que está fuera del trabajo productivo diario de tu equipo.

Déjame repetir tu frase clave:

Soy un gran defensor de la agilidad

Ahora es un buen momento para abrazar eso, y aprender lo que significa administrar un equipo Scrum. Tus responsabilidades también han cambiado ahora. Haces las cosas habituales (incorporar nuevos miembros, manejar el salario, ayudar a que tu equipo pueda trabajar (conseguirles su hardware/softwar/etc. y un buen ambiente de trabajo), tal vez colaborando con otros managers de Scrum). El hecho de que tu empresa parezca reconocer las unidades organizativas no ha cambiado. Los miembros de tu equipo seguirán necesitando hablar contigo, pero no sobre su trabajo.

Dependiendo de lo que hacías antes como trabajo diario (repartiendo paquetes de trabajo a los desarrolladores individuales), puede que quieras mirar otras cosas que puedes hacer. Por ejemplo, podrías opinar sobre los proyectos en los que trabaja tu equipo, o si el dueño de un producto se pone desagradable de alguna manera, tu trabajo podría ser calmarlo. Podrías ser responsable de la gestión de los contratos con los clientes (ventas, etc.). Serás un socio y un escudo para tu equipo en caso de escaladas. Tú eres el administrador. Gestionar no es lo mismo que desarrollar software; y asignar tareas a personas individuales es sólo una pequeña parte.

Francamente, diría que eres muy afortunado. Monta la ola. Déjalos hacer lo suyo. Evita manejar su nuevo Scrum lejos; Scrum fue hecho exactamente para hacer al equipo autosuficiente y capaz de desempeñarse sin la constante microgestión desde el exterior. Muchas partes de Scrum están hechas para proteger al equipo de una administración no deseada.

Su trabajo podría ser muy fácil ahora. Si todo funciona según lo planeado, se encargarán de muchas cosas que tenías que hacer antes. Todo el mundo puede estar muy contento a partir de ahora, especialmente si antes no les gustaba tu microgestión.

el equipo ha acordado colectivamente “despedirme” como su manager

Obviamente, asumo que ya que has citado la palabra “fuego”, no enviaron literalmente un correo a RRHH para excluirte de la nómina, sino que te dijeron que quieren vivir Scrum en toda su extensión (e intención). Obviamente, asumo que no quieren cortar las líneas del organigrama de tu empresa. Incluso un equipo de Scrum puro todavía necesita estar arraigado en algún lugar de la empresa, es decir, ser parte de la administración de la línea, y ese eres tú. Ya no estás involucrado en el trabajo diario.