Cuando la supervisión se disfraza de agilidad

El riesgo de confundir facilitar con controlar.

Por donde quiero empezar...

Hace algunos años pensaba que uno de los beneficios de adoptar Scrum era dejar atrás la microgestión. La idea parecía lógica: equipos más autónomos, decisiones más cercanas a quienes realizan el trabajo y menos necesidad de controlar cada actividad del día a día.

Con el tiempo descubrí que la realidad suele ser distinta.

La microgestión no desaparece cuando una organización empieza a trabajar con Scrum. En muchos casos simplemente cambia de forma. Ya no siempre aparece representada por un jefe de proyecto que pregunta constantemente por las tareas pendientes o exige explicaciones sobre cada retraso. A veces adopta comportamientos mucho más difíciles de identificar porque se presentan como parte de las buenas prácticas de la agilidad.

He participado en organizaciones donde la principal preocupación era que todas las historias estuvieran correctamente actualizadas en Jira. También he visto Dailies en las que la conversación se detenía para recordar a alguien que cambiara el estado de una tarea antes de continuar. Incluso he escuchado afirmar que una historia que sigue en "To Do" demuestra que el desarrollo todavía no ha comenzado, aunque el equipo lleve horas trabajando sobre ella.

No hay nada malo en mantener un tablero actualizado. De hecho, es una práctica recomendable porque facilita la transparencia y ayuda al propio equipo a visualizar el trabajo. El problema aparece cuando el tablero deja de ser una herramienta al servicio del equipo y comienza a convertirse en un mecanismo para supervisarlo.

Es una diferencia pequeña, pero cambia completamente el propósito.

A partir de ese momento la conversación deja de girar alrededor de los impedimentos, de la colaboración o de cómo entregar más valor al cliente. En su lugar, empieza a centrarse en comprobar si cada estado refleja exactamente lo que está ocurriendo en cada minuto del Sprint.

Y ese es solo uno de los síntomas.

Con los años he observado distintos comportamientos que, aunque suelen presentarse como ejemplos de una buena implantación de Scrum, terminan alejando al Scrum Master del propósito real de su rol. Lo más curioso es que casi ninguno nace de una mala intención. En muchos casos aparecen porque existe la necesidad de demostrar que se está aportando valor.

El problema es que aquello que resulta más fácil de mostrar no siempre coincide con aquello que más ayuda al equipo a mejorar.

La microgestión ya no tiene el mismo aspecto

Cuando pensamos en microgestión, la imagen que suele venir a la cabeza es bastante parecida: un responsable que pregunta constantemente por el estado de las tareas, que quiere estar presente en todas las decisiones y que necesita aprobar cualquier cambio antes de que el equipo pueda avanzar.

Ese modelo sigue existiendo, pero cada vez es menos frecuente verlo de una forma tan evidente.

En organizaciones que trabajan con Scrum, la microgestión suele aparecer de maneras mucho más sutiles. Ya no se presenta como una orden directa, sino como una preocupación permanente por el proceso. Poco a poco, la conversación empieza a girar alrededor de los estados del tablero, de la actualización de Jira, de los reportes, de las métricas o de la necesidad de justificar continuamente en qué se está utilizando el tiempo.

Todas esas prácticas tienen sentido cuando ayudan al equipo a organizarse mejor. El problema comienza cuando dejan de ser un medio y pasan a convertirse en el objetivo.

He visto Scrum Masters dedicar una parte importante de su jornada a comprobar que cada historia esté en la columna correcta. También he conocido equipos que reciben recordatorios constantes para actualizar Jira antes incluso de terminar una conversación técnica. En algunos casos, el éxito del Sprint parecía depender más del orden del tablero que de la capacidad del equipo para resolver problemas o colaborar entre sí.

Curiosamente, pocas personas cuestionan estos comportamientos porque resultan fáciles de justificar. Al fin y al cabo, mantener la información actualizada mejora la transparencia. Y eso es cierto.

¿Cuánto tiempo estamos dedicando a mejorar la transparencia y cuánto a mejorar realmente la forma en que el equipo trabaja?

Un tablero perfectamente actualizado no elimina dependencias entre equipos. Tampoco mejora un refinamiento deficiente, resuelve conflictos entre Desarrollo y Producto o ayuda a que una retrospectiva termine convirtiéndose en cambios reales. Sin embargo, es mucho más sencillo comprobar que una historia ha pasado de una columna a otra que medir cualquiera de esas mejoras.

Quizá por eso terminamos dedicando tanta energía a aquello que resulta visible.

Cuando demostrar que trabajas se vuelve más importante que mejorar al equipo

Existe algo de lo que pocas veces se habla cuando se analiza el rol del Scrum Master.

Su trabajo no siempre produce resultados visibles.

Cuando un equipo aprende a resolver conflictos por sí mismo, cuando Producto y Desarrollo empiezan a colaborar con mayor fluidez o cuando una retrospectiva consigue eliminar un problema que llevaba meses repitiéndose, resulta difícil señalar un momento concreto y decir: "esto ocurrió gracias al Scrum Master".

Son cambios que aparecen poco a poco y cuyos efectos, muchas veces, solo se perciben con el paso del tiempo.

Quizá por eso existe la tentación de dedicar más energía a actividades cuyo impacto es inmediato y, sobre todo, fácil de mostrar.

Preparar un dashboard, automatizar un informe o construir un prompt que ordene la información de Jira puede aportar valor. El problema aparece cuando esas actividades empiezan a ocupar el espacio que debería destinarse a desarrollar la autonomía del equipo.

No resulta extraño encontrar profesionales capaces de explicar con detalle cuántas historias permanecen en progreso, cuánto tiempo lleva abierta una tarea o quién olvidó actualizar su estado. Sin embargo, cuando la conversación gira hacia la colaboración del equipo, los bloqueos recurrentes o la calidad de los refinamientos, el nivel de profundidad suele ser muy distinto.

Es mucho más sencillo demostrar el trabajo mediante aquello que puede enseñarse en una pantalla.

El mayor valor que aporta un Scrum Master está en la mejora continua del equipo. Y eso difícilmente se refleja en un dashboard.

Confundir actividad con impacto

Existe una pregunta que pocas veces nos hacemos cuando analizamos el trabajo de un Scrum Master.

¿Cómo sabemos que está aportando valor?

Muchas veces terminamos asociando aportar valor con aquello que cualquiera puede observar: organizar reuniones, elaborar informes, crear dashboards, automatizar tareas administrativas o construir nuevos mecanismos para hacer más visible el trabajo del equipo.

Todo eso puede aportar valor pero realmente ¿El equipo trabaja mejor o simplemente el tablero refleja mejor lo que está ocurriendo?

Un equipo puede tener un tablero impecable y seguir sufriendo los mismos problemas Sprint tras Sprint. Refinamientos poco efectivos, dependencias que nadie gestiona, conversaciones difíciles que se posponen, decisiones que llegan demasiado tarde o retrospectivas que terminan sin generar ningún cambio.

Nada de eso desaparece porque una historia cambie de estado.

Esto pasa porque resulta mucho más sencillo medir el orden de un tablero que medir cuánto ha evolucionado un equipo.

Y si lo que resulta más fácil de medir termina convirtiéndose en la referencia para valorar nuestro trabajo, existe el riesgo de dedicar cada vez más tiempo a mejorar los indicadores, en vez de mejorar lo que representan los indicadores.

Cuando facilitar deja de ser suficiente

Pocas veces se reconoce a un Scrum Master porque una conversación difícil entre Producto y Desarrollo terminó con un acuerdo o porque el equipo aprendió a resolver un conflicto sin necesidad de su intervención. Tampoco suele recibir reconocimiento cuando una retrospectiva consigue evitar que un mismo problema vuelva a repetirse.

Ese tipo de logros casi nunca aparecen en un comité de seguimiento.

En cambio, el control sí es visible. Preguntar por el estado de las tareas, recordar que se actualice Jira, convocar reuniones de seguimiento o estar presente en todas las conversaciones transmite la sensación de que se está liderando.

Y ahí empieza a producirse un cambio sutil.

El éxito deja de medirse por la capacidad del equipo para trabajar con autonomía y empieza a medirse por el nivel de control que alguien consigue mantener sobre el proceso.

No resulta extraño encontrar Scrum Masters que responden preguntas dirigidas al Product Owner, intervienen en decisiones que el propio equipo podía resolver o convierten la Daily en un espacio para justificar el avance de cada tarea.

No porque sean malas personas.

Sino porque, casi sin darse cuenta, han terminado asociando su utilidad con su presencia constante.

Paradójicamente, cuanto más necesita una persona intervenir para sentirse útil, más se aleja del propósito del rol.

Scrum nació para fomentar equipos capaces de organizarse, aprender y tomar decisiones cada vez con mayor autonomía. Sin embargo, en algunas organizaciones parece que simplemente hemos sustituido una figura de control por otra.

El nombre del rol cambió.

La forma de ejercerlo, en algunos casos, no tanto.

Cuando el rol empieza a confundirse con la autoridad

Uno de los riesgos menos comentados de este rol es que, con el tiempo, la influencia termine confundiéndose con la autoridad.

No suele ocurrir de un día para otro.

Empieza con pequeños comportamientos casi imperceptibles: recordar constantemente que se actualice Jira, intervenir en conversaciones que el propio equipo ya estaba resolviendo o asumir que determinadas decisiones deberían pasar antes por quien facilita el proceso.

A simple vista parecen gestos de ayuda.

El problema aparece cuando el equipo se acostumbra a que siempre exista alguien supervisando el proceso.

No resulta extraño encontrar Scrum Masters que participan prácticamente en todas las reuniones relacionadas con el equipo, responden preguntas dirigidas al Product Owner o intervienen antes de que el propio equipo tenga la oportunidad de encontrar una solución.

Desde fuera puede parecer liderazgo.

En ocasiones solo es una forma de mantener el control.

Y ahí aparece una contradicción difícil de ignorar.

El propósito del rol nunca fue convertirse en el centro de las conversaciones ni supervisar cada movimiento del equipo. Su mayor aportación consiste en ayudar a que las personas colaboren mejor, resuelvan sus diferencias con mayor autonomía y aprendan a mejorar continuamente.

Hay una paradoja que siempre me ha parecido interesante.

Cuanto mejor desempeña alguien este rol, menos necesita intervenir en el funcionamiento cotidiano del equipo.

No porque deje de aportar valor.

Sino porque ese valor ya forma parte de la manera en que el equipo trabaja.

Cuando la necesidad de demostrar valor termina ocultando el verdadero valor

Es comprensible que quien desempeña este rol quiera demostrar que está aportando valor.

A diferencia de otros perfiles, su trabajo rara vez se traduce en un entregable visible. Mientras un desarrollador entrega una funcionalidad o un Product Owner toma una decisión sobre el producto, gran parte del trabajo consiste en mejorar la forma en que el equipo colabora. Y ese tipo de resultados no siempre son fáciles de reconocer.

Quizá por eso existe la tentación de centrar los esfuerzos en aquello que la organización puede percibir con mayor facilidad.

No porque sea lo más importante.

Sino porque es lo más visible.

Con el tiempo, la conversación empieza a girar alrededor de aquello que resulta sencillo explicar en un comité o en una reunión de seguimiento, mientras quedan en un segundo plano preguntas mucho más difíciles de responder.

¿El equipo toma mejores decisiones que hace seis meses?

¿Los conflictos se resuelven antes de convertirse en bloqueos?

¿Producto y Desarrollo colaboran mejor que antes?

¿Las retrospectivas están produciendo cambios que permanecen en el tiempo?

Responder a esas preguntas exige observar la evolución del equipo, no solo su actividad.

He llegado a pensar que existe una paradoja en este rol.

Cuanto más necesita una persona demostrar continuamente que está aportando valor, mayor es el riesgo de dedicar menos tiempo a generar el tipo de valor que realmente transforma a un equipo.

Porque las mejoras más importantes rara vez llevan el nombre de quien las impulsó.

Simplemente pasan a formar parte de la forma de trabajar del equipo.

Cuando el liderazgo se confunde con protagonismo

Scrum nunca definió este rol como un responsable del equipo, un supervisor o la persona que autoriza decisiones. Su propósito siempre fue diferente: ayudar a que el equipo mejore la forma en que trabaja.

Sin embargo, no es extraño encontrar organizaciones donde termina ocupando un espacio muy parecido al de una jefatura. No porque Scrum lo plantee así, sino porque todavía existe una forma de entender el liderazgo basada en controlar el proceso y convertirse en el centro de las decisiones.

Ese cambio no suele producirse de un día para otro.

Empieza cuando quien facilita el proceso siente la necesidad de validar acuerdos a los que el equipo ya había llegado, responder preguntas dirigidas a otras personas o participar en conversaciones que el propio equipo podía resolver sin ayuda.

Desde fuera puede parecer liderazgo.

En ocasiones solo es una forma de mantener el control.

Hay algo de lo que rara vez se habla dentro de la comunidad ágil.

El ego también llega a Scrum.

No necesita un cargo con autoridad formal. Le basta con convertirse en la persona alrededor de la que gira el equipo.

Con frecuencia aparecen situaciones en las que el equipo funciona correctamente, pero aun así alguien siente la necesidad de intervenir, añadir la última palabra o validar una decisión que ya estaba tomada. Poco a poco deja de facilitar el trabajo del equipo para empezar a dirigirlo.

Paradójicamente, cuanto más necesita una persona estar presente para sentirse útil, más se aleja del propósito del rol.

La contradicción aparece cuando hablamos de autonomía mientras construimos equipos que dependen constantemente de nuestra presencia. Se habla de autoorganización, pero el equipo sigue esperando que alguien confirme si va por el camino correcto.

Lo preocupante es que estos comportamientos suelen recibir reconocimiento. Se interpretan como compromiso, liderazgo o cercanía con el equipo, y la propia organización termina reforzándolos.

Con el tiempo he llegado a una conclusión.

Facilitar implica renunciar al protagonismo.

Aceptar que las mejores decisiones pueden producirse sin nuestra intervención y que el reconocimiento muchas veces se lo llevará el propio equipo.

Para mí, esa es una de las pruebas más difíciles de este rol.

Si el equipo necesita cada vez más la presencia de quien lo acompaña para funcionar, probablemente algo no esté evolucionando en la dirección correcta.

Si, por el contrario, toma mejores decisiones, resuelve conflictos con mayor autonomía y sigue mejorando incluso cuando esa persona no está presente, entonces el verdadero trabajo ya habrá dado sus frutos.

Entonces, ¿cómo se mide realmente el trabajo de un Scrum Master?

Después de todo lo anterior, sería fácil concluir que Jira, las métricas o los dashboards no sirven para nada.

No sería una conclusión justa.

Todas esas herramientas pueden aportar valor cuando ayudan al equipo a comprender mejor su trabajo y a tomar mejores decisiones.

El problema aparece cuando dejan de ser un medio y se convierten en una forma de demostrar que estamos trabajando.

Quizá por eso siempre me ha parecido tan difícil medir el impacto de este rol. No porque no genere resultados, sino porque los más importantes rara vez aparecen en un indicador. No existe un dashboard que muestre que Producto y Desarrollo colaboran mejor, que un conflicto recurrente ha desaparecido o que el equipo mantiene conversaciones más honestas.

Con el tiempo he dejado de fijarme tanto en lo que hace un Scrum Master y prefiero observar qué ocurre cuando no está.

Si el equipo deja de avanzar porque falta alguien que recuerde cómo trabajar, probablemente todavía exista una dependencia.

En cambio, cuando el propio equipo identifica problemas, propone mejoras y toma decisiones sin esperar que otra persona impulse cada conversación, suele existir un trabajo previo que pocas veces recibe reconocimiento.

Para mí, ahí está el verdadero impacto de este rol.

No en convertirse en la persona más importante del equipo, sino en ayudar a que el equipo siga mejorando incluso cuando su intervención deja de ser necesaria.

El trabajo más importante casi nunca se ve

Cuando un entrenador consigue que un equipo juegue mejor, pocas personas hablan del entrenador durante el partido.

La atención se la llevan los jugadores.

Y probablemente esa sea una buena señal.

Con un Scrum Master ocurre algo parecido.

Su mayor aportación no consiste en dirigir el trabajo del equipo ni en convertirse en el centro de todas las conversaciones. Consiste en crear las condiciones para que el propio equipo funcione mejor.

Eso significa detectar patrones antes de que se conviertan en problemas habituales, conseguir que una retrospectiva produzca cambios reales, ayudar al Product Owner y al equipo de desarrollo a colaborar mejor o hacer visible un impedimento que nadie había identificado.

Ninguna de esas cosas aparece automáticamente en Jira.

Tampoco se refleja en un dashboard.

Y, sin embargo, probablemente tengan mucho más impacto que cualquier indicador de seguimiento.

Quizá por eso el trabajo del Scrum Master resulta tan difícil de explicar.

Los resultados más importantes no se miden por la cantidad de reuniones organizadas ni por el estado de un tablero. Se perciben cuando el equipo empieza a resolver por sí mismo situaciones que meses atrás necesitaban la intervención constante de otra persona.

En ese momento podría parecer que el Scrum Master tiene menos trabajo.

En realidad ocurre exactamente lo contrario.

Ha conseguido que la mejora continua deje de depender de él y pase a formar parte de la manera de trabajar del equipo.

Ese, en mi opinión, es uno de los mayores éxitos que puede alcanzar alguien en este rol.

Y también uno de los menos visibles.

Palabras finales

Nunca he visto que un Sprint fracase porque una historia permaneciera demasiado tiempo en "In Progress" o que un producto no sea aceptado por el cliente final porque el dashboard no esté actualizado.

Sí he visto equipos dejar de mejorar porque nadie dedicaba tiempo a hablar de cómo estaban trabajando y también he visto productos perder oportunidades porque las conversaciones importantes se sustituyeron por actividades de seguimiento.

Tampoco he conocido un equipo que se volviera más autónomo porque alguien le recordara varias veces al día que debía actualizar Jira.

La autonomía aparece cuando las personas aprenden a tomar mejores decisiones, a colaborar con mayor confianza y a resolver sus propios problemas sin esperar constantemente a que alguien les indique el siguiente paso.

Me interesa menos cómo se utiliza una herramienta y mucho más cómo se comporta un equipo cuando nadie lo está observando.

Porque ahí se aprecia si existe una cultura de mejora continua o simplemente un conjunto de prácticas que seguimos por costumbre.

Scrum nunca pretendió que el éxito de un equipo dependiera de la persona que mejor conoce el tablero.

Pretendía construir equipos capaces de aprender, adaptarse y mejorar de manera constante.

Si para conseguirlo el Scrum Master necesita controlar cada conversación, revisar cada movimiento del tablero y convertirse en el centro del proceso, probablemente el equipo haya aprendido a depender de él, pero no a crecer.

Y esa, al menos para mí, es la diferencia entre acompañar a un equipo y dirigirlo.

La primera exige paciencia, escucha y muchas conversaciones que nadie verá.

La segunda solo necesita control.

Para mi la mejor forma de medir a quien desempeña este rol no debe ser preguntando cuánto controla al equipo, sino cuánto ha conseguido que el equipo deje de necesitar ese control.