3 errores de Scrum Masters y cómo solucionarlos

Ser Scrum Master puede ser una tarea bastante difícil.

Si das demasiados consejos y ayuda a un equipo, pronto el equipo se acostumbrará a que el Scrum Master le diga todo. Sin embargo, si das muy poca ayuda al equipo, se desarrollará más lentamente de lo que podría. Resuelve algunos problemas para el equipo y pronto se esperará de ti que resuelvas todos los problemas. Pero si no resuelves los problemas del equipo, los miembros del equipo eventualmente dejarán de informar a su Scrum Master sobre sus impedimentos y problemas.

Los Scrum Masters caminan por una línea muy delgada y es fácil cometer errores. En este artículo se describen tres errores que los Scrum Masters cometen frecuentemente, y para cada uno de estos errores se ofrece una breve propuesta de solución.

1) Dejar que el trabajo se desborde al siguiente Sprint

El primer error es, en mi opinión, uno de los peores hábitos que un equipo puede desarrollar: dejar que el trabajo se desborde de un Sprint al siguiente.

Esto ocurre cuando un equipo no completa todos los Product Backlog Items que estaban planificados para un Sprint y simplemente los lleva al siguiente Sprint.

No me malinterpretes: de vez en cuando sucederá que un equipo no termine con todo. De hecho, es incluso una buena señal cuando eso ocurre a veces. Significa que el equipo se pone un plan exigente y no planifica demasiado poco trabajo para un Sprint por miedo a no poder completarlo todo.

Sin embargo, un Scrum Master tampoco debería considerar como algo menor que un equipo no termine con el trabajo planificado, porque de lo contrario los Sprints se convierten en límites artificiales y sin significado. Los equipos deberían sentir una ligera presión cuando se acerca el final del Sprint. Un equipo debería pensar: “Uff, el Sprint termina mañana. Tengo que mantenerme realmente enfocado hoy y terminar.”

Si el desbordamiento de trabajo al siguiente Sprint es un problema en tu equipo, hay varias cosas que puedes hacer al respecto:

En primer lugar, debes eliminar este mal hábito. Anima a los miembros del equipo a planificar su próximo Sprint de manera que definitivamente puedan completar todo el trabajo. Eso significa que deberían tomarlo con calma y planificar el próximo Sprint con algo de precaución. Si luego todo va bien, se puede añadir más trabajo al Sprint.

Además, puedes intentar que el equipo sienta un pequeño sentimiento de culpa cuando no se complete todo. No se trata de que alguien se sienta realmente mal. Los miembros del equipo solo deben tener la misma mala conciencia que tengo yo ahora mismo. Estoy intentando no beber tantos refrescos. Ya estoy progresando y no he bebido ninguno desde hace una semana. Pero hoy, mientras escribía este artículo, me apetecía uno. Así que me permítí un refresco. No me siento mal por ello, pero definitivamente no quiero beber otro mañana para no volver a caer en viejos hábitos.

2) Dirigir los Daily Scrums

Un segundo error que observo frecuentemente en los Scrum Masters es que asumen la dirección de los Daily Scrums. Por supuesto, el Scrum Master debería participar en los Daily Scrums y también dar su propia actualización. Sin embargo, el Scrum Master no necesita dirigir la reunión ni pedir constantemente a los miembros del equipo que participen, etc.

El Scrum Master debería explicar las reglas y la razón del Daily Scrum y dirigir las primeras dos o tres reuniones y pedir a las personas que participen. Después, debería dejar que el equipo dirija los Daily Scrums por sí mismo.

Las actividades de un Daily Scrum no son particularmente difíciles. No se necesita un “policía” que lo regule todo, porque si el Scrum Master dirigiera la reunión de esa manera, la discusión se centraría demasiado en el Scrum Master.

Con un nuevo equipo, me gusta empezar moderando definitivamente las primeras reuniones yo mismo. Luego, en algún momento, solo digo “Bien equipo, es hora de empezar” y quizás pregunto quién quiere comenzar. Pero pronto también dejo de hacer eso.

Después de algunas reuniones empiezo a mirar mi reloj de manera obvia cuando es hora de comenzar la reunión. Si es necesario, me aclaro la garganta lo suficientemente alto para que todos entiendan lo que pasa. Y luego simplemente me quedo quieto hasta que alguien dice: “Oh, creo que deberíamos empezar.” Después de unos días en los que miro el reloj y me aclaro la garganta, doy un paso más y solo miro el reloj cuando es hora de empezar. Y después de unos días más, incluso dejo de hacer eso. Simplemente me quedo de pie y espero a que comience la reunión.

Por supuesto, no estoy en silencio durante toda la reunión. Bajo ciertas circunstancias, puedo necesitar hacer coaching a alguien para que entre más en detalle, o interrumpo a alguien cortésmente y sugiero si quizás podrían ocuparse de los detalles después del Daily Scrum.

Simplemente imagínate que yo (u otra persona desconocida) estuviera en tu Daily. En ese caso, no debería ser posible descubrir quién es el Scrum Master del equipo solo observando. Seguramente habrá veces en que el Scrum Master diga algo que solo un Scrum Master diría. Sin embargo, eso no debería ocurrir constantemente.

3) Dejar que el equipo se dirija hacia un burnout

No soy un gran fan de la mayoría de los términos de Scrum, pero el término Sprint es particularmente problemático. Cuando corro un sprint, me canso rápidamente y necesito tomar descansos una y otra vez. Esa es una metáfora bastante mala para un equipo.

Un Sprint termina y el siguiente comienza. Los equipos no deberían empezar el siguiente Sprint mientras aún se están recuperando del último. Más bien, los equipos deberían trabajar a una velocidad sostenible, lo que Kent Beck denominó Sustainable Pace.

El tercer error que veo a menudo es que los Scrum Masters permiten que sus equipos excedan esta velocidad sostenible y trabajen hacia un burnout. Un buen Scrum Master debería prestar mucha atención y proteger al equipo de un burnout si es necesario.

Muchos equipos tienen una mentalidad optimista y ese optimismo se traslada a la cantidad de trabajo que se comprometen a hacer en un Sprint. Los Scrum Masters deberían estar alerta y aconsejar precaución a los equipos cuando en el Sprint Planning corren el riesgo de comprometerse con más trabajo del que han logrado en Sprints anteriores. ¿Por qué? Porque el equipo, incluso si logra completar todo el trabajo del Sprint, corre el riesgo de empezar el siguiente Sprint agotado y con demasiado optimismo respecto a la cantidad de trabajo. En algún momento, el equipo ya no podrá mantener una velocidad sostenible y se “quemará”. Una buena manera de proteger a un equipo de esta situación es darle espacios donde puedan decidir por sí mismos en qué quieren trabajar.

6 x 2 + 1

Para ello me gusta usar un método que llamo “6 x 2 + 1”. Esto se refiere a seis Sprints de dos semanas más un Sprint de una semana al final. Los miembros del equipo pueden elegir por sí mismos en qué quieren trabajar durante ese último Sprint. Algunas personas usan ese tiempo para su desarrollo personal (leer un libro, formación en vídeo, etc.). Otros usan el tiempo para refactorizar código feo que el Product Owner no ha priorizado. Otros miembros del equipo quizás prueben con un experimento que creen que podría llevar a una gran nueva funcionalidad. Todo eso lo puede decidir el equipo por sí mismo.

Sin embargo, introducir un ciclo así puede tener muchas más ventajas. El Product Owner tiene de esta manera, por ejemplo, una semana completa sin ser “molestado” por el equipo. Y eso es a menudo el mejor argumento de venta para conseguir que el Product Owner se sume.

Este ciclo también puede ser beneficioso para toda la organización cuando se deben asumir compromisos como por ejemplo “¡Tenemos que entregar esta funcionalidad en 3 meses!” La semana 13 de los Sprints 6 x 2 + 1 también puede usarse para un Sprint normal si el equipo se ha retrasado respecto a una fecha límite. Si el equipo luego logra cumplir con la fecha límite, siempre se les puede dar un Sprint de una semana de libre disposición después.

Aprende más sobre estos puntos en nuestras formaciones para Scrum Master y prepárate en tres días para este rol ágil y aprende a asumir responsabilidad como Servant Leader.