Le das al scrummaster una mirada extraña y dices "adiós Felicia", y al día siguiente convocas a una reunión de todo el equipo y les preguntas qué demonios fueron esas tonterías.

Si esto realmente sucediera, entonces despediría al scrummaster idiota en un minuto de Nueva York. Este scrummaster es peligroso, poco profesional y tremendamente inadecuado para su trabajo. La forma de "despedir a su gerente" es renunciar: básicamente, solo ha presentado renuncias para todo el equipo.

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

Más importante aún, necesitas averiguar qué diablos está pasando. Es posible que sea necesario despedir al propio scrum master dependiendo de la situación.

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

Si bien he trabajado con varios equipos que han seguido el mismo curso de acción, no parece que se haya manejado con el cuidado que merece. Me gustaría compartir lo que he visto para ver si les ayuda a avanzar.

Primero, Scrum fomenta los equipos autoorganizados. Lo que la Guía Scrum dice específicamente sobre los equipos autoorganizados es lo siguiente:

Se autoorganizan. Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo convertir el Backlog del Producto en Incrementos de funcionalidad potencialmente liberable;

Eso, junto con muchas otras cosas sobre la funcionalidad cruzada y responsabilidad amplia, tiene como objetivo alentar a los miembros del equipo a hacerse preguntas difíciles sobre qué tan bien están preparados para atender cualquier solicitud que les llegue. Definitivamente vale la pena el tiempo para leer la Guía de Scrum; es breve.

En cuanto a un gerente, si ha descubierto que su trabajo en el pasado ha sido Al asignar tareas y rastrear elementos de trabajo, Scrum le pide que dé un paso atrás en esto. Francamente, si el Scrum Master no te habló de esto mucho antes de la primera retrospectiva, puede que haya sido un error de su parte. Sin embargo, una dura realidad es que muchos equipos que están acostumbrados a que un gerente organice sus tareas por ellos no están bien preparados para lanzarse a este enfoque. Si sientes que tu equipo está en esta situación, te recomiendo hablar con el Scrum Master al respecto. Existen muchas técnicas para facilitar esta transición. En particular, miraría La escalera del liderazgo de David Marquet y tal vez incluso su libro Turn the Ship Around . Verá que en ambos, no se despide a ningún gerente.

Por último, veamos por qué le gustaría hacer esta transición si ha tenido éxito en la gestión de personas en el pasado. La versión corta es que tendrás aún más éxito ayudándolos a aprender a manejarse por 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 autoorganizarse y en un equipo de, digamos, diez, Once cerebros (el tuyo incluido) siempre resolverán problemas de manera más efectiva que uno y tener otros diez a tu lado esperando para culparte si la solución es incorrecta.

He visto muchos gerentes exitosos en entornos Scrum. Siempre advertiría a un equipo que no "dispara" directamente. Incluso si eres intimidante como dice tu pregunta y manejas todas las tareas que tienen por delante, he trabajado con muchos gerentes como ese que siguen siendo activos increíbles para el equipo. En estos equipos autoorganizados, pasa de dedicar todo su tiempo a dirigir las acciones del equipo a asegurarse de que el camino para que tengan éxito sea claro y siempre salga mejor en todos los ámbitos con equipos que entregan más y gerentes que tienen una reputación de crear estrellas de rock.

Buena suerte. Espero que esto les brinde algunos ángulos con los que trabajar.

• En el contexto de scrum: ¿Qué dice el propietario del producto? No es función del scrum master pedir más (o menos) recursos. Esto es algo que el Product Owner necesita alinearse con las partes interesadas

• En el contexto de scrum: una retrospectiva se trata del proceso y el equipo y el proyecto (no de "cómo hacer lo que siento por mi jefe "). Si formaba parte del equipo, debería haber sido invitado. Si no formaba parte del equipo, la retrospectiva solo debería haber abordado su rol en el proyecto.

• Los scrum masters decirle a los gerentes de línea qué hacer son al menos tan absurdos como el gerente de línea se involucró directamente en el scrum

Así que el scrum master claramente superó sus límites. Su función era mantener la retrospectiva enfocada en identificar problemas específicos que necesitan ser abordados.

Cómo proceder:

• Hablas con el equipo en una -a-una sesión y pregúnteles qué está pasando. Explica claramente que el Scrum Master no es una función de línea y que no ensambla los equipos. Pregúnteles también dónde creen que debería haberse mantenido al margen de las actividades cotidianas

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

• Pasas al siguiente en la fila (si ese es el CIO, es el CIO; no es aceptable que no tengas un gerente durante meses), indicando que la situación debe resolverse de inmediato (por despedir al scrum master o al CIO que ha hablado con él de que lo despedirán en el curso actual), de lo contrario, pone en peligro el proyecto; a mí me parece que el scrum master no comprende sus deberes y límites. Una respuesta profesional al equipo que intenta "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 por lo que el proyecto nos paga".

Le recalqué al equipo los beneficios de los equipos autoorganizados y el empoderamiento del equipo.

Bueno, ciertamente tomaron esa parte para corazón.

Parece claro que estás en una situación muy emocional en este momento. Aparentemente, su equipo tiene algunos problemas importantes con la relación actual entre usted y ellos. Probablemente fue algo bueno que no estuvieras en la retrospectiva, porque esa es generalmente 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 con un Scrum Master con el que solo han estado trabajando durante algunas semanas, entonces ya confían en él o están tan molestos que realmente no les importan las consecuencias.

De cualquier manera; este no es un problema nuevo que apareció repentinamente cuando cambió a Scrum o contrató a una nueva persona. Este es un problema que ha estado creciendo sin ser visto durante mucho tiempo. A menudo se dice que trabajar Agile no crea nuevos problemas, sino que hace que los ya existentes sean extremadamente obvios. Este es probablemente un caso de eso.

Dicho esto; su Scrum Master dejó caer la pelota, con fuerza. Es su trabajo ayudar al equipo a crecer hacia la autoorganización, claro. Pero esta no es la forma correcta. Por un lado, él no puede en realidad despedirte, y simplemente decirte "esto es lo que el equipo quiere" no es nada constructivo. No estoy seguro de lo que él piensa que será el resultado de esto, pero no puede ser lo que el equipo piensa que es.

Además, eliminar personas es la elección más difícil que puede tomar un equipo ( o Scrum-Master) y nunca debe tomarse a la ligera y sin hablar (repetidamente) con ellos. involucrado. No puede simplemente salir y eliminar a alguien que no tiene idea de que alguien tiene un problema con ellos. Por lo menos, dejará a todos asustados como el infierno de que si se pierden una retrospectiva, podrían regresar repentinamente 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 quiere cuando trabaja con Agile.

Entonces, con su Scrum Master fallando en trabajar en una atmósfera abierta (al menos fuera del equipo; parece han conseguido que la gente se abra un poco internamente) y no buscas una solución constructiva, parece que te toca a ti hacerlo.

En este punto, no creo que nada basado en la autoridad esté va a ser útil. Scrum y Agile se trata de empoderar a las personas para que hagan sus propias cosas, y afirmar su autoridad en este punto probablemente terminará 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, por lo que, si bien es posible que se hayan equivocado con la persona, enfrentarse cara a cara probablemente terminará con al menos algunas personas que se van. (Y recuerde la regla más importante para irse: las personas más valiosas serán las primeras en irse).

Entonces, si realmente quieres hacer Scrum con este equipo, aquí es donde debes aceptar su capacidad para 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 les está funcionando. Necesita tener una charla sobre cuál será su función en el futuro, qué necesitan de usted, qué necesita de usted y cómo se organizará todo eso. Tenga en cuenta que ellos pueden decidir cómo trabajar, pero en última instancia, todavía hay un producto que debe entregarse; serán juzgados por la calidad de lo que entreguen. Y si hay cosas organizativas que necesita de ellos, también tendrán que hacer esas cosas. (Dicho esto, trabaje con ellos en la forma de esas cosas y asegúrese de que sean realmente necesarios antes de hacerlos cumplir).

Asegúrese de que en esa reunión, no aborde las cosas desde su autoridad ; la idea es que todos estén al mismo nivel. Ustedes son colegas e individuos que todos 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 autoritario generalmente solo hace que las personas se enfrenten entre sí, lo cual no es productivo. Así que trate de ser vulnerable aquí y esté dispuesto a admitir las cosas que hizo mal. Necesitas descubrir cómo avanzar desde aquí como seres humanos.

Parece que tu equipo llegó a la fase de asalto de su desarrollo como equipo, y lo consiguieron duro . Ahora le toca al equipo (y te incluyo en él, al menos por ahora) descubrir cómo ir desde allí. Sea advertido; no todos los equipos salen de esta fase y no puedo prometer que este enfoque solucionará el problema. Sin embargo, puedo garantizar que no será peor que renunciar o despedir a todos.

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

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

(También estoy asumiendo aquí que el Scrum Master no hará que todo el equipo se rebele contra ti sin algunos problemas subyacentes serios. 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, debes deshacerte del tipo lo antes posible . Ese es probablemente el único caso donde consideraría usar su autoridad como la persona que lo contrató y despedir al tipo).

Independientemente de si tienen el poder real para despedirlo como su gerente, usted se trajo esta situación al ordenar un cambio en scrum simplemente porque lo prefiere. No lo discutiste con ellos. Es posible que haya estado dentro de sus derechos como gerente, pero de todos modos fue una tontería y, por supuesto, ahora se preguntan si quieren seguir trabajando para usted.

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

Debe convocar una reunión mañana a las 9:15 a. m. y disculparse por tomar una decisión tan importante sin tener en cuenta sus aportes. . Luego, puedes pedirles sus comentarios sobre cómo pensaron que fue su primer sprint y qué se podría haber hecho de otra manera.

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

Con empleados capacitados, es mejor persuadir, incluir y alentar que exigir.

Una perspectiva diferente: ¿se te ocurrió que simplemente se estaban burlando del proceso Scrum y su aspecto de "autoorganización"? Francamente, no puedo imaginar que hablaran en serio y se rieron mucho mientras leían tu publicación. 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 todos les gusta o ni siquiera reconocen. Estoy seguro de que simplemente te estaban diciendo que no les gusta Scrum.

Quizás el mejor curso de acción sería tratar de hablar con algunos de ellos de manera informal 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 Scrum no tiene un gerente, responde a un Propietario del producto en su lugar. El Product Owner representa los intereses de los accionistas con respecto al equipo, organiza los entregables para el sprint al comienzo, acepta los resultados al final y aclara las cosas sobre las solicitudes del equipo mientras tanto. Básicamente, es un representante entre el equipo y la empresa.
• Si fueras parte del equipo Scrum, asistirías a una reunión retrospectiva. Si no es parte del equipo Scrum, la reunión debería haberse limitado a su rol con respecto al equipo dentro del modelo Scrum.

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

Y si no lo hizo, es hora de hacer esto ahora . Podría decirse que la transición más fluida para un gerente si no se lo considera parte del equipo cuando se cambia a Scrum es el propietario del producto. Continuará haciendo el Lo mismo, pero ahora el equipo te responde colectivamente en lugar de cada miembro individualmente, y dejas de microgestionarlos a menos que lo pidan específicamente (lo último es posiblemente algo bueno para ambas partes).

Al ver que aparentemente ha cometido un error crítico en la investigación al sugerir Scrum, creo que no organizó un Product Owner dedicado, por lo que está exactamente en la posición de asumir este rol ahora.

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

¿Cómo puedo calmar esta situación y restablecer mi autoridad como su gerente, mientras me mantengo fiel a los principios de autoorganización y empoderamiento del equipo de ágil?

¿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 problema puede ser más grave que solo el método ágil.

Esto es algo fundamental para un gerente y debe abordarlo, debería ser su prioridad número uno durante las próximas semanas.

¿Sus n + 1, n + 2 están de licencia durante varios meses? tal vez influyó en su equipo para que se rebelara. ¿Cuál es el estado financiero de su empresa? (si es malo, los empleados pueden pensar que estás haciendo un mal trabajo y que puedes hacerlo mejor sin ti).

qué hacer: - organizar una reunión con todo el equipo: "scrum master me dijo que quieres para despedirme, ¿qué está pasando? ". (es muy importante que le dirijas el tema a todo el mundo ya que todos lo conocen y si afecta el trabajo diario) .- identifica el problema real (¿solo este método ágil o tienes algún problema con el equipo antes?) .- una vez que sepas el problema real, es necesario investigar: ¿quién tiene la razón? ¿Tú o tus empleados? -identifica quién es el líder de esta rebelión (siempre hay un empleado que está desafiando a las autoridades más que a 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 los equipos a necesitar y aumentar su desempeño. Ahora:

Soy un gran defensor de lo ágil, así que contraté a un scrum master y dije que estaríamos siguiendo a scrum.

Suena más como 'tengo una gran idea', quiero que lo hagan. En lugar de consolidar el equipo primero sobre tu idea. Creo que todos los equipos tienen derecho a criticar tu idea y hacer agujeros en tu idea. si su idea no se sostiene, debería descartarla.

Si no está seguro de que la idea se mantenga, puede decirle al equipo que desea un período de prueba y / o migrar lentamente a la nueva estructura del proyecto.

De esta manera, es posible que aún encuentres resistencia, pero probablemente no tanto como ahora.

Creo resumir: Tú eres su gerente, no su jefe . ¡esos son dos trabajos muy distintos!

O bien: a) Tienen razón y no ha podido justificar su existencia. (Todavía no pueden despedirte) orb) El scrum master quiere tu trabajo.

Creo que lo mejor que puedes hacer es hacer un curso de scrum master de 2 días y deshacerte de tu scrum master . Luego, probablemente pueda obtener una bonificación al final del año por hacer dos trabajos.

"El código es más lo que llamaría" pautas "que reglas reales". - Capitán Barabossa

Me parece que tienes una gran situación y estás tratando de aferrarte a algunos ideales irrazonables.

I ' He recalcado al equipo los beneficios de los equipos autoorganizados y el empoderamiento del equipo.

Explíqueles a sus hijos que la autoorganización y el empoderamiento no significan que puedan hacer lo que quieran. Si tu equipo decidió ir a robar algunas armas automáticas y robar un banco, no estás obligado a seguir adelante con ellas solo porque están habilitadas.

No pueden "dispararte". Ese es el papel de su gerente. El disparo siempre proviene de la cadena, no de abajo. Claro, pueden saltar peldaños en la jerarquía y trabajar con su jefe para destituirlo, pero dado que aparentemente su jefe y su jefe están de licencia sin haber puesto a nadie en su lugar en su ausencia, no hay mucha de una jerarquía a la que ir. Tienes unos meses.

Le dije al scrum master que me gustaría hablar con el equipo sobre esto, pero él estaba firme en que se sentían "intimidados" cuando estaba en la habitación, y no quería discutirlo conmigo.

Bueno, eso es una lástima para ellos. Habla con ellos de todos modos. El autoempoderamiento puede darle la capacidad de tomar sus propias decisiones, pero no lo libera de la responsabilidad de estar a la altura de esas decisiones. Si tuviera un equipo así, hablar con ellos sería el más amable nivel de respuesta que consideraría.

Uno podría decir "Oh, pero se supone que el maestro de SCRUM Resolver impedimentos como este. Todo debe pasar por él ". Bueno, duro. Lo arruinó cuando se acercó a usted para decirle que fue despedido y no lo hizo de una manera lo suficientemente cortés como para que lo aceptara. Se espera que un maestro de SCRUM tenga mejores habilidades con las personas.

Entonces, ¿qué dices?

Primero, quieres saber si realmente decidieron "despedirte". Tienes la palabra de una persona al respecto, y creo que este es el tipo de situación en la que el equipo debería poder decir directamente su pieza.

En segundo lugar, considera lo que significa "disparar". Afirmas ser un gerente de manos libres, pero quieren que te vayas. Entienda por qué. No están escribiendo los cheques de pago, por lo que la decisión de despedirlo no es una decisión del tipo "oh, no están haciendo todo lo posible". Esa es una decisión del tipo "esta persona se interpone activamente en el camino". Algo realmente no cuadra aquí. Necesita que se sume antes de tomar decisiones importantes. Siendo una persona anónima en Internet, no puedo decir si eres tú o ellos o el maestro de SCRUM, pero algo está realmente realmente mal en este escenario, y es mejor que sepas qué es por el Es hora de que termine de hablar con ellos.

Trabaje con ellos. Sea un gerente. Encuentra una forma de resolver el problema. Encuentre una manera de que pueda hacer su trabajo, mientras ellos hacen el de ellos. Haz que suceda.

Ahora, si sus respuestas te brindan un cierre suficiente para honrar su autoempoderamiento, ahora debes mostrarle al equipo lo que sucede cuando "despides" un liderazgo de esa manera. Di "Bien. Dejaré de actuar como tu gerente. No puedes en realidad despedirme, porque esa no es tu posición, pero si quieres jugar a este juego, podemos jugar. Yo era tu gerente, lo que lo ayuda a aislarse de la política corporativa y el estrés de informar a la alta gerencia. Ahora, soy su alta gerencia y usted ya no tiene ese aislamiento. Ahora que no puedo retirarme de este puesto, simplemente lo haré comenzar a transmitir tareas desde lo alto ". Explique que el hecho de que el equipo haya votado no significa que no tenga obligaciones con la alta dirección que deba cumplir y que continuará haciéndolo.

Luego, busque ayuda.

Un motín no es poca cosa. Todo tu equipo te acaba de expulsar de la isla. No lo subestimes. Comuníquese con alguien por encima de usted para que lo ayude. Tal vez llame a su jefe de licencia. Quizás hable con su CIO. Alguien necesita saber que hay un gran problema de personas en su empresa, y que usted lo está resolviendo. La segunda mitad es claramente importante. Nunca vaya al liderazgo con problemas, vaya a ellos con soluciones.

La solución que recomendaría es crear su imagen como el "gerente con requisitos" eligiendo las cosas que requieran que el liderazgo (es decir, el CIO) quiera , que está diseñado para construir algo de autorrealización que vaya con este auto empoderamiento. Puede que piensen que son libres de hacer lo que quieran, pero tú estás obligado a convertirlos en un equipo exitoso. Si tienes que hacerlo desde lejos, hazlo desde lejos. Descubra por qué su enfoque de no intervención fue tan intimidante y asegúrese de no hacerlo nunca.

El objetivo final es hacer que se den cuenta de que está de su lado. Si están verdaderamente empoderados, entonces deben darse cuenta de que usted es una parte beneficiosa del equipo. Solo llegarán a esa conclusión si tienen éxito. Si se ven abrumados por plazos imposibles y una burocracia desesperada, nunca lo verán.

Solo asegúrese de que todo cuadre. 2 + 2 = 4. ¿Un gerente "sin intervención" es "despedido" por el nuevo maestro de SCRUM por ser demasiado intimidante mientras dos niveles de la gerencia están de licencia? Algo no cuadra desde aquí. Estás más cerca de la situación. Averigua qué no cuadra y arréglalo.

No hay un rol de gerente en un equipo de scrum. La verdadera pregunta es por qué pensó que era un miembro del equipo en primer lugar. Si no participa en la entrega de funciones, no tiene un lugar en ese equipo, por lo que lo que hizo el equipo fue correcto.

Si lo consideran un impedimento, averigüe por qué: lo más probable es que usted estaban interfiriendo, y la solución es que usted se enfrente y deje que ellos hagan su trabajo.

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

¿Entonces no veo por qué no puedes ver esto como algo positivo? Tengo entendido que el objetivo de un equipo de autogestión es no necesitar un gerente .

Lo que debe hacer es ver las oportunidades que esto presenta. Básicamente, tiene un súper equipo que puede administrarse a sí mismo y ahora puede hacer lo siguiente:

• Puede 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 autogestionarse.
• Usted puede desarrollar las habilidades en el equipo. Así que ahora puedes centrarte más en el aspecto de las personas del equipo. Crecimiento profesional, habilitación y ese tipo de cosas.
• Tenga en cuenta que el equipo + scrum master siguen siendo responsables ante usted en la jerarquía de la empresa, los presupuestos y el proceso de evaluación del desempeño. Por lo tanto, no es como si se te pasaran por la cabeza.

Piensa en esto como un éxito por ahora. Piense más en las oportunidades de cómo puede fortalecer el equipo. También tenga en cuenta que debe estar presente en el caso de que este enfoque de autogestión falle.

Lao Tse dijo

El líder malvado es aquel a quien la gente desprecia,

El buen líder es aquel a quien la gente 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á terminado, 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 todos saben qué hacer, entonces no soy necesario y mi trabajo se sirve mejor de esta manera: disfrutando de la vida fuera de la oficina.

Sigues las métricas, auditas su código, haces pequeñas correcciones de rumbo, animas a & a habilitar cualquier necesidad de fomento y habilitación: comunicación, cooperación, redacción de pruebas, etc., los proteges de la alta dirección de los clientes de &, e idealmente nunca actúas.

Pero cuando lo haces, lo haces y tú patear la nariz cuando sea necesario, después de todo, usted es el responsable de su trabajo; la gente es despedida por recomendación suya y debe despedirlo a tiempo.

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

Sigues siendo su h igher-up: aún puede dispararlos si lo necesita, no ha sido despedido desde esta posición. Se te consideró inútil o perjudicial para el esfuerzo de desarrollo y ellos prefieren jugar sin ti.

O esto o hay una patología grave en la cultura del equipo.

Yo dicen que es una oportunidad increíble para una gran reflexión y crecimiento.

Puedo ver dos puntos de vista aquí:

• Usted era el gerente de línea de un equipo de desarrollo en una organización matricial y sigue siendo el gerente de línea. Es posible que su trabajo haya cambiado un poco, pero es fundamentalmente el mismo: proporciona días de trabajo de desarrollador al PO de acuerdo con los procesos de presupuesto / recursos humanos de la empresa, se ocupa de la contratación (y si es necesario, del despido), programa se va en cooperación con el equipo, y así sucesivamente.
  En el desarrollo ágil, su rol puede ser un poco menos complicado de lo que solía ser, pero especialmente si hay varios equipos de scrum, su rol ahora incluirá cosas como fomentar "comunidades de práctica" o "gremios". Como todo, scrum puede ser dañino si se lleva a los extremos, y alguien debería tener cuidado, p. Ej. que las pilas de tecnología siguen 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 una organización de este tipo.
• Usted era un miembro del equipo de desarrollo y tenía una participación directa en las decisiones de tecnología, arquitectura, etc. En ese caso, te sugiero que te equivoques al no involucrarte lo suficiente en este primer sprint, porque no ven cómo contribuirás con tus habilidades al equipo. En el próximo sprint, trabaje con el equipo.

Soy 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, de lo contrario ...), entonces todo está bien.

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

el equipo ha acordado colectivamente "despedirme" como su gerente

¡Bien! Han cambiado sus caminos; han abandonado su resistencia (no nos dijiste a qué se resistían, antes ...). Han aprendido los roles que rodean a un Scrum Team.

Como seguramente sabrá, un gerente solo tiene una responsabilidad muy remota en el contexto de un Scrum Team; usted no es el Scrum Master, ni el Product Owner, ni uno de los Stakeholders, ni forma parte del Scrum Team en sí. Recuerdo cuando obtuve mi certificado de Scrum Master en un seminario de 3 días; el papel de "gerente" ni siquiera estaba en el gráfico.

Si su empresa utiliza la estructura matricial típica de la gestión de línea vertical frente a la gestión horizontal relacionada con el proyecto (o relacionada con el producto) (es decir, el gerente de línea <> gerentes de proyecto / producto), entonces todo parece ir de acuerdo al plan. Seguirás teniendo responsabilidades de gestión, es decir, gestionar todo lo que esté fuera del trabajo productivo diario de tu equipo.

Permíteme repetir tu frase clave:

Soy un gran defensor de lo ágil

Ahora es un buen momento para aceptar eso y aprender lo que significa administrar un equipo Scrum. Sus responsabilidades también han cambiado ahora. Haces las cosas habituales (incorporando nuevos miembros, manejando el salario, ayudando a tu equipo a poder trabajar (dándoles su hardware / software / etc. y un buen ambiente de trabajo), quizás colaborando con otros gerentes de Scrum). El hecho de que su empresa parezca reconocer unidades organizativas no ha cambiado. Los miembros de su equipo aún necesitarán hablar con usted; simplemente no sobre su trabajo.

Dependiendo de lo que hiciste antes como tu trabajo diario (repartiendo paquetes de trabajo a desarrolladores individuales), es posible que desees ver otras cosas que puedes hacer. Por ejemplo, podría tener voz y voto en los proyectos para los que trabaja su (!) Equipo, o si un Product Owner se pone desagradable de alguna manera, podría ser su trabajo calmarlo. Podría ser responsable de gestionar los contratos de los clientes (ventas, etc.). Serás un socio y un escudo para tu equipo en caso de escaladas. Estás administrando . Administrar no es lo mismo que desarrollar software; y asignar tareas a personas individuales es solo una pequeña parte.

Francamente, diría que tiene mucha suerte. Monta la ola. Déjalos hacer lo suyo. Evite administrar su nuevo Scrum; Scrum se hizo exactamente para hacer que el equipo fuera autosuficiente y capaz de desempeñarse sin una microgestión constante desde el exterior. Muchas partes de Scrum están diseñadas para proteger a un equipo de una gestió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ía que hacer antes. Todos pueden estar muy felices de ahora en adelante, especialmente si no les gustó su microgestión antes.

el equipo ha acordado colectivamente "despedirme" como su gerente

Obviamente, asumo que, dado que citó la palabra "fuego", no enviaron literalmente un correo a RR.HH. para excluirlo de la nómina, pero le dijeron que quieren vivir Scrum en toda su extensión ( e intención). Obviamente, asumo que en realidad no quieren cortar las líneas en el organigrama de su empresa. Incluso un Scrum Team puro necesita estar arraigado en algún lugar de la empresa, es decir, ser parte de la gerencia de línea, y ese eres tú. Simplemente ya no estás involucrado en el trabajo diario.