Sprints de microgestión de gestión

Estás lidiando con un conflicto sistémico y su alcance supera con creces lo que puedes hacer en tu puesto. Digo esto como alguien que pasó por más o menos la misma prueba y tuvo que darse por vencido y marcharse al final después de una contrapresión increíble más allá de mi imaginación más salvaje cuando traté de impulsar el cambio.

Su alta dirección se suscribe al feudalismo corporativo. Hay buenos trabajadores y malos trabajadores. El estrés es un indicador de productividad, y los trabajadores de línea deben ser presionados y controlados. Se debe alentar la competencia agresiva entre pares, ya que permite que los buenos trabajadores asciendan y los malos trabajadores dejen su lugar a los buenos trabajadores. El valor de un trabajador está determinado por cuánto sacrifica y cuánto escucha a sus gerentes. Y si un trabajador de línea demuestra su compromiso, puede obtener rangos más altos, lo cual es el epítome del éxito al unirse a los rangos de la nobleza gerencial. Esto no es solo mi cinismo, es un remanente cultural de siglos anteriores de aristocracia y doctrinas militares que alimentan las doctrinas de gestión empresarial y, a pesar de sus deficiencias, ha producido valor demostrable desde la era victoriana.

Agile es la alternativa popular a esto con la idea central de que hay partes interesadas que quieren que se hagan ciertas cosas, y lo que quieren que se haga se puede definir de una manera estándar, dividir en partes donde los expertos en el tema pueden elegir y trabajar, entregar y mejorar. con el mismo proceso nuevamente basado en los comentarios de las partes interesadas. Esto es muy nuevo y requirió dos siglos y medio de conocimiento acumulado desde el comienzo de la revolución industrial y todos los medios para compartirlo que llegaron con la era de la información. Esto era imposible hace solo 50 años, necesitabas que alguien le dijera a alguien que le dijera a alguien que clavara una viga en un lugar específico.

Mi punto es que sus opciones son adaptarse o irse. No se puede convencer a la alta dirección acerca de sus formas. Apenas lo ven como un ser humano tal como es, dado que no ven problemas con el desgaste por la sobreasignación constante. El tipo de cambio que podría estar esperando debe venir desde arriba e incluso entonces, por lo general, se convierte en cripto-feudos de bolsillos de déspotas gerenciales y sus lacayos. Su mejor apuesta es encontrar una nueva organización que no sea la misma si desea ese tipo de cambio. Si no lo hace, le recomendaría leer algo sobre Maquiavelo y Sun Tzu para entrar en la mentalidad.

Creo que deberías buscar trabajo.

No veo ningún indicio de que la gerencia te escuche. Tu redacción demuestra que rechazan incluso los pequeños cambios que solicitas y, sin embargo, quieres cambios grandes.

todavía tenemos que tener problemas para alcanzar nuestros hitos

Esta frase lo hace especialmente difícil. Después de 3 o 4 meses de esto, es probable que la gerencia lo acredite en su estrategia. Estás buscando cambiar un sistema que desde su perspectiva está funcionando espléndidamente.

Tengo un par de opciones para ti, pero todas dependen de que puedas alejarte de manera segura. Además, si su salud y bienestar están sufriendo, es mejor buscar trabajo ahora que luchar para hacerlo después de haber sido despedido o tener que renunciar.

Entonces, el paso 1 de cualquiera de estos es pulir su currículum y solicitar algunos trabajos. Mi apuesta es que tendrás que irte para mantener la cordura.

El paso 2 tiene algunas opciones para ti.

Opción 1: Simplemente renuncie.

He conocido a más gerentes que harían volar un avión contra el suelo por arrogancia que los que estaban dispuestos a pivotar completamente en función de los comentarios. Al diablo con las matemáticas, al diablo con las leyes, seguirán su curso.

Los primeros intentos de cambio no han tenido éxito. A menos que tenga razones convincentes para quedarse en esta empresa (y debe verificar qué tan convincentes son esas razones en el mercado laboral), ahórrese la miseria y simplemente renuncie. Puedo decir por el tono de su escritura que no se siente tan cómodo con el conflicto como la típica persona de negocios mientras oculta sus opiniones.

Encuentre un nuevo trabajo, avise con dos semanas de anticipación, ofrezca a sus subordinados una referencia sólida en caso de que ellos también deseen escapar y deje atrás el desorden. En muchos lugares, es un momento dorado para ser desarrollador, especialmente uno senior.

Opción 2: El Caso de Negocios Contundente

La mayoría de las razones que le diste a la gerencia no tienen nada que ver con el éxito del proyecto, sino con el bienestar de tu equipo. Muchos gerentes están felices de agotar a los desarrolladores para que un proyecto tenga éxito. Históricamente, matar y mutilar trabajadores al por mayor ha sido perfectamente aceptable para los empresarios.

Básicamente, debe presentar un caso de por qué es mejor para un proyecto que cambien. El problema es que tales razones a menudo no existen mientras los desarrolladores estén dispuestos a soportar lo que sea que se les presente. Pasar todo su tiempo en análisis en lugar de producir código es básicamente el único caso comercial que tiene en este momento.

Si perdiera un desarrollador a manos de otra empresa debido al tratamiento, también tendría alguna evidencia, pero es probable que eso aún no haya sucedido. Necesita algún tipo de métrica de dólares y centavos de por qué vale la pena implementar algunos de sus cambios.

Parte del problema también debe ser su tono, ya que su tono no proyecta confianza ni autoridad.

Cambiar

Personalmente, creo que la sobreasignación constante de personas solo hace que parezca que no están haciendo nada.

a

La sobreasignación constante de personas solo hace que parezca que no están haciendo nada

y

especialmente porque administrar estas expectativas me lleva a no tener casi tiempo para desarrollar y, en cambio, dedico mi tiempo a hacer análisis.

a

especialmente porque manejar estas expectativas me obliga a evitar el desarrollo y, en cambio, a perder el tiempo haciendo análisis.

Probablemente no tenga tanta confianza en persona, así que póngalo por escrito y envíelo. Ahí es donde tengo la ventaja y sospecho que también puede funcionar para la tuya.

Siempre me ha gustado esta carta de un alto directivo de Blackberry a sus jefes. Se demostró que tenía razón. El problema fue que nadie escuchó en ese momento y Mike y Jim estrellaron el avión contra el suelo. ¿No sabes qué es Blackberry? Fue lo más importante antes del iPhone.

Tenga otro trabajo en fila en caso de que lo despidan por esto. Nunca he visto este trabajo.

Opción 3: El ultimátum

Si la opción 2 viene antes que la 3 (o la 3 como un componente de dos) o si salta directamente a la tres depende de cuánto quiera cambiar las cosas, cuánto conflicto esté dispuesto a soportar y cuánto la compañía /proyecto significa para usted.

Usted cree que es respetado dentro de la organización, pero no estoy seguro. La microgestión es una forma insidiosa de falta de respeto en el lugar de trabajo, ya que lo ven como poco confiable o incompetente o ambos. Personalmente, mido el respeto en función de la influencia y el trato, ya que los elogios son gratuitos y las escuelas de negocios fomentan que fluyan libremente como una forma de mantener a los empleados satisfechos de forma gratuita.

El tipo de gente que cree esto

Me dijeron que el equipo debe tener una sobreasignación del 10 % (es decir, todos deben tener un 10 % más de capacidad para un sprint) ya que uno de los gerentes cree que esto ayuda a motivar al equipo a trabajar más duro.

Es casi seguro que están dispuestos a elogiar a las personas sin sinceridad para "mantenerlos motivados".

todos en la gerencia me han dicho que hice un muy buen trabajo administrando lo que estaba bajo mi control.

Para que quede claro, no hay razón para creer que eres un mal líder de equipo, así que no te desanimes solo porque algunos de los elogios pueden ser egoístas.

El ultimátum consiste esencialmente en obtener otra oferta de trabajo en otro lugar y decirle a la gerencia que o la microgestión se va o usted se va.

¡Buena suerte!

Desarrollador + PSM aquí,

Me pregunto por qué su organización quiere hacer AGILE si van a ignorar porciones significativas. Si su objetivo no es que sus equipos se vuelvan autoorganizados y autónomos, entonces no tiene sentido buscar metodologías AGILE. No puede simplemente elegir partes de una metodología y descartar las partes que no le gustan y aún así esperar que haga lo que fue diseñado para hacer. Dicho esto, convencer a la gerencia obtusa de que sus formas son contrarias a la intuición nunca es un proceso sencillo.

Lo único que su gerencia entenderá son los números. Afortunadamente, en este caso, pasa la mayor parte de su tiempo lidiando con análisis. Tendrá que comenzar realmente a profundizar en esos datos, pero puede tomar tiempo para que los datos que necesita se materialicen. El método más rápido para demostrar el error de sus formas es entregar su aviso de dos semanas con una explicación detallada de por qué. Sin embargo, me imagino que esta no es una opción factible, pero es algo a lo que comenzaría a prestar atención. Si su administración se está desempeñando de esta manera, incluso si soluciona este problema específico, su próximo problema con ellos siempre estará a la vuelta de la esquina. El papel más importante de la dirección, en mi opinión, es la delegación. Si no pueden confiar en sus informes, entonces no pueden delegar. Si no pueden delegar, entonces tienen que microgestionar. Y si tienen que microgestionar, no pueden dedicarse por completo a lo que se supone que deben entregar. El papel de la dirección es eliminar los impedimentos, no crearlos. Tendrá que ser creativo con sus datos para demostrar esto. Comience a observar cosas como el quemado, la rotación, las tasas de cierre de historias, las pruebas de monte carlo, la agrupación de PTO, los cuadros de mando ágiles, etc. Comience a buscar señales de que su equipo está retrocediendo. Están ahí, pero es posible que necesite más tiempo para permitir que los datos superen el umbral en el que pueden ignorarse como ruido estadístico. Solo su propia incapacidad para contribuir al desarrollo debería hacer mella en la efectividad de su equipo. El papel de la dirección es eliminar los impedimentos, no crearlos. Tendrá que ser creativo con sus datos para demostrar esto. Comience a observar cosas como el quemado, la rotación, las tasas de cierre de historias, las pruebas de monte carlo, la agrupación de PTO, los cuadros de mando ágiles, etc. Comience a buscar señales de que su equipo está retrocediendo. Están ahí, pero es posible que necesite más tiempo para permitir que los datos superen el umbral en el que pueden ignorarse como ruido estadístico. Solo su propia incapacidad para contribuir al desarrollo debería hacer mella en la efectividad de su equipo. El papel de la dirección es eliminar los impedimentos, no crearlos. Tendrá que ser creativo con sus datos para demostrar esto. Comience a observar cosas como el quemado, la rotación, las tasas de cierre de historias, las pruebas de monte carlo, la agrupación de PTO, los cuadros de mando ágiles, etc. Comience a buscar señales de que su equipo está retrocediendo. Están ahí, pero es posible que necesite más tiempo para permitir que los datos superen el umbral en el que pueden ignorarse como ruido estadístico. Solo su propia incapacidad para contribuir al desarrollo debería hacer mella en la efectividad de su equipo. Están ahí, pero es posible que necesite más tiempo para permitir que los datos superen el umbral en el que pueden ignorarse como ruido estadístico. Solo su propia incapacidad para contribuir al desarrollo debería hacer mella en la efectividad de su equipo. Están ahí, pero es posible que necesite más tiempo para permitir que los datos superen el umbral en el que pueden ignorarse como ruido estadístico. Solo su propia incapacidad para contribuir al desarrollo debería hacer mella en la efectividad de su equipo.

Para resumir, necesitas datos concretos. Tienes que demostrar con números que tu equipo está retrocediendo. Si eres miserable y tu equipo es miserable, tarde o temprano se mostrará en los análisis. Pero si es como usted dice, y esto realmente no es sostenible a corto plazo, comenzaría a analizar sus opciones. Resolver este dolor de cabeza no resolverá los futuros dolores de cabeza. Una gestión como esta mata equipos. Demonios, mata organizaciones enteras. Casi nunca lo ven venir, porque su solución para perder efectividad es restallar el látigo aún más fuerte. Desafortunadamente, pueden pasar años y docenas de renuncias antes de que vean la escritura en la pared.

Como Scrum Master certificado y desarrollador, intentaré dar una respuesta equilibrada:

• Le recomendaría que reconsidere su punto de vista "Estoy completamente en desacuerdo con todas estas metodologías" y dé un paso atrás para comprender cómo hacer que las ceremonias y los procesos de Scrum/Agile funcionen para usted. Daré ejemplos en breve.
• Es función del equipo de desarrollo estimar el esfuerzo para cada elemento de la cartera de productos. Tal vez sea útil obtener algunas cartas de póquer de planificación de Scrum y trabajar con sus compañeros para acostumbrarse a las técnicas de estimación.
• Los sprints deben dimensionarse en función de las horas de trabajo disponibles del equipo de desarrollo para realizar el trabajo asignado. Por lo tanto, si tiene 400 horas de trabajo por hacer dentro de un Sprint y 300 horas de recursos disponibles dentro del Sprint, la sobreasignación de PBI generalmente tendrá el efecto de que los PBI de baja prioridad se pierden y caen en el siguiente Sprint. Esto es de esperar a veces, pero hacerlo de forma regular es un poco inútil.
• Asegúrese de que usted y sus compañeros adquieran el hábito de escribir un breve "Enfoque de desarrollo" con viñetas para cada PBI, en otras palabras, un resumen de alto nivel de cómo pretende resolver el problema (por ejemplo, consulte vistas, modelos, controladores, elementos donde sea necesario, etc.). Entonces, un nivel un poco más alto que el pseudo código. Eso ayuda a proporcionar estimaciones más precisas.
• Construir una fuerte relación de trabajo con el propietario del producto. Su función es proporcionar tanta claridad como sea necesario para cada PBI, priorizarlos de manera efectiva y proporcionar una visión y objetivos generales claros. Por supuesto, Devs puede influir en esto, pero al final es el papel del PO.
• También trabaje en estrecha colaboración con el Scrum Master. Es parte de su rol ser un líder de servicio, por lo que si hay obstáculos que se interponen en el camino para que usted y el equipo sean efectivos, plantéelos.
• Por último, y no puedo enfatizar esto lo suficiente, contribuya activamente durante las Retrospectivas de Sprint. Esa es la oportunidad de discutir cuán efectivos son trabajando juntos como equipo y si tiene ideas para ayudar a mejorar las cosas, entonces ese es un gran foro para plantearlas y llegar a un consenso como equipo sobre qué recomendaciones tomará a bordo como un equipo y comprometerse a seguir adelante.

Scrum y Agile definitivamente pueden tomar algún tiempo para acostumbrarse, especialmente aquellos acostumbrados a las metodologías y comportamientos tradicionales de liderazgo y gestión de proyectos. No es perfecto, pero te recomiendo que te tomes un momento para reflexionar y realmente espero que los consejos anteriores te ayuden. ¡Buena suerte!