3 preguntas contra el micromanagement en Scrum
Uno de los principios fundamentales de Agile y Scrum es exactamente lo opuesto al micromanagement: la creencia en el poder de los equipos autoorganizados. Precisamente por eso, un jefe, Scrum Master o Product Owner que practica el micromanagement es un problema especialmente difícil para los equipos ágiles.
He encontrado tres preguntas que son útiles para lidiar con micromanagers:
¿Quién?
La primera pregunta es "¿Quién?". ¿Quién sufre el micromanagement? Si tú eres el afectado por el micromanagement pero el resto del equipo Scrum no, eso quizás indique que alguien está preocupado por tu rendimiento. Si es así, necesitas trabajar en tu propio rendimiento y mejorar la percepción que ese stakeholder tiene sobre ti.
Sin embargo, si todo el equipo está bajo micromanagement, este comportamiento probablemente se debe al stakeholder en cuestión.
Para averiguar si solo tú o todo el equipo están afectados por el micromanagement, deberías anotar durante uno o dos Sprints en qué cosas se enfoca especialmente el micromanager. Registra todas las actividades de micromanagement para poder revisarlas después y determinar quién está concretamente afectado.
¿Cuándo?
Llevar un registro del micromanagement también te ayudará a responder la segunda pregunta: ¿Cuándo ocurre el micromanagement?
¿Ocurre el micromanagement más bien antes o después de una reunión? Por ejemplo, el Product Owner quizás salga estresado todos los martes de la llamada con el cliente y por eso tenga una mayor tendencia al micromanagement. O el Scrum Master tiende al micromanagement el día antes de la reunión mensual con el VP de Ingeniería.
A veces las personas también tienden al micromanagement a ciertas horas del día. Un antiguo jefe mío tendía especialmente al micromanagement antes de su primera taza de café.
Otros tienden al micromanagement en ciertos momentos durante una iteración. Quizás la persona con la que tratas tiende especialmente al micromanagement durante los últimos días de una iteración, porque empieza a ponerse nerviosa y se pregunta si se logrará completar todo. También aquí deberías registrar esta información para poder reconocer patrones posteriormente.
Utilizo una tabla con las siguientes columnas:
Fecha: La fecha concreta (p. ej., 8 de marzo de 2017). Con esto normalmente no se pueden identificar patrones, pero puedes volver a revisar los datos cuando quieras recordar qué estaba pasando exactamente en la organización en ese momento.
Día de la semana: En ciertas circunstancias, el micromanagement solo ocurre en ciertos días de la semana (p. ej., los viernes). Por eso deberías anotar el día de la semana.
Día en el Sprint: Para poder reconocer si el micromanagement ocurre regularmente en un momento específico del Sprint, anota en qué día del Sprint hubo micromanagement. Puede ser simplemente "Día 3" o "7/10" para indicar que fue el séptimo día de un Sprint de 10 días.
Hora: Anota también la hora correspondiente (p. ej., 10:15).
A quién afectó el micromanagement: ¿Te afectó a ti, a todo el equipo Scrum o a un compañero de equipo?
De qué se trataba: En esta columna registra de qué se trataba el micromanagement.
El contexto: ¿Hubo eventos especiales al mismo tiempo en el Sprint, el proyecto o la organización? ¿Ocurrió el micromanagement justo antes o después de una reunión? ¿Qué reunión era? ¿Y qué estaba pasando en general durante la iteración?
Notas: Anota aquí todo lo que consideres importante en este contexto. La siguiente tabla sirve como ejemplo.
¿Por qué?
Después de haber registrado las actividades de micromanagement durante algunas semanas, es hora de plantear la tercera pregunta: ¿Por qué ocurrió el micromanagement en primer lugar?
Busca patrones en tu registro. Intenta encontrar los desencadenantes.
Quizás tu Product Owner tiende al micromanagement después de la reunión semanal con su jefe.
Quizás tu superior directo tiende al micromanagement a fin de mes, cuando tiene que escribir un informe para su jefe.
A partir de estos patrones, deberías intentar tener conversaciones constructivas con las personas correspondientes. Con gran seguridad no tendrás éxito si simplemente dices: "¡Por favor, deja de hacer micromanagement!" En su lugar, intenta hablar con ellos sobre lo que les preocupa y, por lo tanto, cuál es la causa de ese comportamiento.
Una vez que hayas identificado algunas de las causas del micromanagement, deberías poder anticiparlas y eliminarlas en el futuro.
Anticipar y eliminar los desencadenantes
Si eres capaz de anticipar el comportamiento no deseado mediante la observación precisa, deberías trabajar en eliminar los desencadenantes. Frecuentemente esto se logra acercándote proactivamente al micromanager y proporcionándole información.
Si tu Product Owner, por ejemplo, está regularmente estresado después de la reunión semanal con su jefe y recae en el micromanagement, siéntate con el Product Owner antes de esa reunión. Asegúrate de que tu Product Owner esté bien informado y preparado para la reunión con su jefe.
Acude activamente a los stakeholders propensos al micromanagement y proporciónales la información necesaria. Intenta hacerlo justo antes de que se presente el desencadenante respectivo. Así te aseguras de que estas personas tengan toda la información importante o la recuerden.
Sin embargo, ten cuidado de no crear nuevos procesos engorrosos para ti mismo. Pero sí tienes control sobre la relación con el Stakeholder (o jefe) cuando ofreces información activamente, en lugar de esperar hasta que te la pidan y luego tener que adaptarte al calendario de otras personas.
A algunas personas no se les puede ayudar
Incluso con estos consejos, no siempre podrás eliminar todo el micromanagement. Algunos stakeholders son micromanagers incorregibles. Los consejos mencionados aquí te ayudarán a tener más control sobre la mayoría de las situaciones y hacerlas más llevaderas.
Este texto proviene del blog de Mike Cohn y fue traducido al español.
¿Qué es realmente la productividad?
=> Desmontamos los mayores mitos sobre la productividad.
Priorización y objetivos a mediano plazo
=> Aprende cómo puedes priorizar mejor como Product Owner.
Toma de decisiones en equipo
=> Así llegas más rápido a mejores decisiones con Scrum.
