Siete errores comunes de los nuevos Scrum Masters al servicio de sus equipos

Siete errores comunes de los nuevos Scrum Masters al servicio de sus equipos

En mi artículo anterior, les hablé principalmente a los Scrum Masters. Les conté como, basado en un video de Mike Cohn, quise hablar de mi experiencia acompañando Scrum Masters a asistir a sus Product Owners, equipos y organizaciones. Empecé hablando de los errores que cometen con mayor frecuencia cuando se trata de colaborar con sus PO.

Si no lo han hecho, pueden leer el artículo aquí:

Siete errores comunes de los nuevos Scrum Masters al servicio de los Product Owners – Lucho Salazar

Pues bien, en este nuevo artículo, continuaré abordado el tema, pero ahora me referiré al servicio que prestan los Scrum Masters al equipo Scrum. Una vez más, veamos cuáles son esos desaciertos que tienen los Scrum Masters Kohai, en el sentido de aprendices, cuando de estar al servicio del equipo se trata. Y recordemos, son errores, más no pecados.

1. Fomentas inadecuadamente la autogestión

De mi observación general, la ausencia de confianza es la llave a la caja de Pandora que abre todos los males organizacionales y he visto cómo los nuevos Scrum Masters obstaculizan involuntariamente la autonomía del equipo al tomar decisiones por ellos o, incluso, dirigiendo su trabajo de manera minuciosa, al infame estilo del micromanejo. Este comportamiento desgasta la capacidad del equipo para gestionar sus tareas de manera efectiva.

Ejemplo: Un Scrum Master podría asignar tareas a los miembros del equipo durante la Sprint Planning, en lugar de permitir que el equipo tome estas decisiones colectiva y colaborativamente.

Recomendación: tu intención como Scrum Master siempre debe ser enseñar y alentar al equipo a adjudicarse la responsabilidad de su propia planificación y toma de decisiones. Entrenarlos en técnicas e instrumentos para la descomposición efectiva de tareas, la colaboración y la gestión de la carga de trabajo.

Ejemplo de Corrección: durante la Sprint Planning, facilitar una discusión donde los miembros del equipo decidan quién realizará cada tarea y cómo trabajarán juntos para lograr el objetivo de sprint.

Recordatorio: asegúrate de emplear y de que el equipo use preguntas poderosas como «¿Cuál es el enfoque más efectivo?» o «¿Cómo podemos asegurar el cumplimiento de la meta de sprint?» para estimular la autogestión.

2. Descuidas el desarrollo de la multifuncionalidad

Hubo una época en que hacíamos de todo. Luego llegó una era medio oscura en la que la gente se superarchirecontraespecializó, pero además dejaron de tener una visión sistémica de las cosas. Los equipos no eran más que grupos amorfos de personas que se encontraban en el camino y compartían el progreso de las actividades, pero no eran capaces de ayudarse los unos a los otros.

Quizás vienes de un grupo así. O quizás la escuela que tuviste te enseñó que así debía ser. Y tal vez por eso, como Scrum Master tiendes a priorizar las habilidades individuales sobre las capacidades multifuncionales en las personas y los equipos. Pues bien, esto conduce a cuellos de botella e ineficiencias en el trabajo.

Ejemplo: lideras un equipo donde los desarrolladores solo se centran en programar, incluso de forma altamente especializada: que los de la base de datos, que los de la UI/UX, que los de las API, entre otros; y también están quienes hacen aseguramiento de la calidad, etcétera. Todo esto crea retrasos, más cuando una persona o un área de trabajo está atascada.

Recomendación: facilitar la capacitación cruzada entre los miembros del equipo y cultiva una cultura de responsabilidad compartida, donde los individuos se apoyan mutuamente para completar tareas independientemente de su experiencia principal. Promueve las habilidades T o Pi, algo de lo que te hablaré en otra oportunidad. Haz que los miembros del equipo hagan pasantías en otros equipos, promueve el trabajo par o el enjambre.

Ejemplo de corrección: organiza sesiones de enjambre donde unos y otros especialistas colaboren en la implementación de las historias de usuario, en las pruebas inmediatas y en el despliegue. De esta manera, fomentas habilidades multifuncionales y un equipo más versátil y, sobre todo, colaborativo.

Recordatorio: utiliza matrices de habilidades para identificar áreas de desarrollo multifuncional y promueve la tutoría dentro del equipo para fortalecer estas capacidades.

3. Permites que los impedimentos persistan

Es bastante probable que no sepas que hacer con muchos de los impedimentos que plantea el equipo a medida que avanzan los sprints. Además, como Scrum Master novel puedes pasar por alto la importancia de identificar y remover o ayudar a eliminar proactivamente estas inconveniencias en el trabajo, permitiendo la acumulación de obstáculos y limitando el progreso del equipo.

Ejemplo: un retraso debido a un lento proceso de revisión externo o a una decisión que proviene del entorno del equipo puede persistir si no lo abordas de inmediato. Aquí, “abordar” tiene distintos matices: desde hacer el trabajo necesario, hasta gestionar que alguien más lo haga.

Recomendación: vigila la identificación de bloqueadores tanto internos como externos. Facilita discusiones durante las Daily Scrums y las Retrospectivas, entre otras sesiones, para descubrir impedimentos y trabajar activamente en su solución.

Ejemplo de corrección: si el equipo está estancado debido a una revisión externa, o está a la espera de una decisión, como Scrum Master debes comprometer al área externa y negociar ciclos de revisión más rápidos o trabajar con otros líderes para eliminar el cuello de botella.

Recordatorio: cultiva y práctica una cultura donde el equipo informe los impedimentos tan pronto como surjan y utiliza un tablero de impedimentos o algún otro instrumento visual que les permita a todos en el equipo rastrear y priorizar su resolución.

4. No enfocas al equipo en entregar incrementos de alto valor

“El Scrum Master es responsable de lograr la efectividad del Scrum Team”. Así lo traduje para la guía de Scrum 2020. Entre otras cosas, un equipo Scrum efectivo significa: 1) entregar valor en cada sprint (temprano y frecuente); y 2) mejorar continuamente, implacablemente un paso a la vez. Entonces tu trabajo como Scrum Master es conseguir que el equipo haga eso.

Sin embargo, si apenas has entrado al gran laberinto que supone la agilidad y ser un Scrum Master, hay un gran chance de que priorices la cantidad sobre la calidad, permitiendo que el equipo entregue incrementos incompletos o de bajo valor y que no haya ningún programa de mejoramiento.

Ejemplo: un equipo puede entregar características parcialmente funcionales al final de un Sprint, sin proporcionar un valor tangible a los usuarios o a los interesados. O puede no entregar nada. Todo le quedó “casi terminado”. Pues bien, casi terminado definitivamente no es terminado.

Recomendación: haz que el equipo sea consciente de la importancia de la Definición de Terminado y del concepto de entregar al menos un incremento Terminado que sea de valor y utilizable al final de cada Sprint. Y que haya implementado o, al menos, avanzado en la implementación de una acción de mejora. ¡Al menos una!

Ejemplo de corrección: durante la Sprint Planning, recuerda al equipo que divida el trabajo (Sprint Backlog) en tareas alcanzables y que cada una de ellas sea un pequeño paso hacia el cumplimiento de la Definición de Terminado al final del Sprint. Motívalos a que tengan discusiones frecuentes para aclarar lo que significa «Terminado» para cada historia de usuario.

Recordatorio: impulsa el uso de herramientas y técnicas como el User story Map (Mapa de historias de usuario) para ayudar al equipo a ordenar la entrega de las características de mayor valor en primer lugar, asegurando que cada incremento contribuya directamente al objetivo del producto.

5. Facilitas de forma ineficaz los eventos scrum

Lo anticipaba Mike Cohn en el video que suscitó esta serie de artículos. Dirigir la Daily Scrum u omitir otros eventos clave es algo que sucede muy a menudo cuando los equipos son liderados por Scrum Masters con poca experiencia. Y es que los nuevos Scrum Masters pueden no garantizar que los eventos Scrum y otras reuniones como las de refinamiento sean limitados en tiempo, positivos y, sobre todo, productivos. Esto puede resultar en sesiones improductivas o extremadamente prolongadas.

Ejemplo: permitir que la Daily Scrum de tu equipo se convierta en una extensa actualización de estado, misma que incluso se documenta al detalle en un acta (minuta) para enviar a otras personas. Esto es bastante frustrante para el equipo y usualmente conduce a una desconexión no solo con los principios ágiles, sino también con el trabajo mismo y su objetivo principal.

Recomendación: prepárate para ser un gran facilitador y prepara cada evento y sesión. Usa distintas técnicas para mantener a las personas enfocadas en el propósito previsto de cada evento, por ejemplo, asegurándote de que no existan distintas conversaciones al tiempo, subgrupos o personas rezagadas. Además, la experiencia te dirá cuáles son los mejores límites de tiempo para cada sesión.

Ejemplo de corrección: para la Daily Scrum, entrena al equipo para limitar la conversación a 15 minutos, enfocándola en cómo va el equipo hacia el logro del objetivo del sprint.  Las técnicas pueden ser diversas. Sobre este asunto puedes leer mi artículo:

Cómo ayudar a tu equipo a mejorar su Daily Scrum – Gazafatonario IT

Recordatorio: revisar regularmente la intención de cada evento Scrum con el equipo para evitar que se vuelvan rutinarios o carentes de significado. Usa temporizadores o ayudas visuales para mantener los eventos en el camino correcto. Enséñales técnicas, instrumentos, tácticas y estrategias para que sean los miembros del equipo quienes elijan la forma de llevar a cabo las reuniones y, para algunas de estas, sino todas, las conduzcan.

6. Sobrepasas límites y te conviertes en un gerente de proyecto

¡Ah, el creer que no tienes poder! Sobre todo, si vienes de una oficina de proyectos. O si piensas que ser Scrum Master no te da estatus. Pero ese incluso no es el mayor error. La falla aquí, estimado Scrum Master, radica en que adoptes un enfoque de comando y control, propio de la escuela de management tradicional, a lo Taylor (Frederick). Y claro, este comportamiento frena una cultura de autonomía y de toma de decisiones en el lugar donde ocurre la acción.

Ejemplo: reiteradamente veo como Scrum Masters dirigen al equipo, asignando y diciéndoles cómo manejar sus tareas, en lugar de permitirles autoorganizarse y tomar decisiones por sí mismos. No hay un balance entre alineación (definición de objetivos) y autonomía (empoderamiento).

Recomendación: eres un Scrum Master. Quieres convertirte en un gran líder de equipo. Entonces da un paso atrás y brinda la confianza y los recursos necesarios para en que el equipo se autogestione. Un Scrum Master extraordinario interviene solo para facilitar o eliminar impedimentos, no para administrar las tareas del equipo.

Ejemplo de corrección: en lugar de decirle al equipo qué hacer durante la Sprint Planning, haz preguntas que motiven al equipo a que sientan el trabajo como algo de su propiedad y lo disfruten, por ejemplo: «¿Cuál es la mejor manera para que aborden este objetivo?» o “¿Cuál es la mejor estrategia para hacer el trabajo y lograr el objetivo del sprint?”.

Recordatorio: durante las retrospectivas, estimula en el equipo la reflexión sobre su nivel de autonomía y capacidad de toma de decisiones. Ayúdalos con diversos métodos para que sean autogestionados, un paso a la vez.

7. No fomentas la mejora continua

Un error común es tratar Scrum como un proceso fijo en lugar de fomentar la adaptación continua. Sin un enfoque en la mejora, los equipos pueden estancarse y dejar de evolucionar. Además, las presiones externas para “producir, producir y producir” a toda costa, hacen que muchos Scrum Masters abandonen la idea de que además de la entrega de valor, la mejora continua es lo más importante que debe promover un Scrum Master, como afirmé en el apartado 4 de este mismo artículo.

Ejemplo: los equipos repiten el mismo formato de Retrospectiva en cada Sprint sin identificar o implementar cambios significativos. Y lo que es peor, de estas sesiones no emerge ninguna acción de mejora. Se quedan en el puro juego de desconexión. ¡Y de aquello nada!

Recomendación: si quieres que tu equipo cambie, cultiva una cultura de mejora continua. Guía e inspira al equipo a reflexionar profundamente durante las Retrospectivas y a experimentar con nuevas ideas. Haz que se sientan en un entorno seguro. Usa la directiva primaria de la retrospectiva como un ancla. La puedes encontrar en:

Directiva Primaria de las Retrospectivas – Gazafatonario IT

Ejemplo de corrección: Variar el formato de las Retrospectivas para mantener al equipo comprometido y descubrir perspectivas más profundas. Por ejemplo, probar las Retrospectivas de Estrella de Mar (Continuar, Más de, Menos de, Detener, Iniciar) para fomentar diferentes perspectivas sobre lo que funciona y lo que necesita cambiar.

Recordatorio: haz que el equipo establezca objetivos de mejora pequeños y medibles después de cada Retrospectiva y verifica durante el próximo Sprint cómo progresan esas mejoras. Si quieres llevarlos a un nivel más alto de productividad, usa la técnica Scrumming the Scrum (algo así como “mejora tu Scrum”). Puedes encontrar una explicación detallada de este patrón en mi artículo:

Scrumming the Scrum – Gazafatonario IT

Llamado a la acción

Estimado Scrum Master:

Es hora de reflexionar sobre tus propias prácticas. Identifica errores comunes y toma medidas deliberadas para corregirlos. Busca ayuda. Un Coach está más cerca de lo que parece. Fomenta la autogestión, asegura eventos Scrum productivos y conviértete en un catalizador para la mejora continua dentro de tu equipo. Asume tu responsabilidad como un verdadero líder servidor y empodera a tu equipo para crear su mejor trabajo hasta ahora.

Una vez más, lee el libro:

[Nuevo Libro] Scrum: Epítome de experiencias – Lucho Salazar

En él, encontrarás desde los aspectos más esenciales para iniciar tu práctica ágil como Scrum Master, hasta tácticas, estrategias, patrones y otros energizantes Scrum que, como Jorge y yo decimos en el prólogo, te ayudarán a llevar a tu equipo al siguiente nivel de mejora.