Scrum Master, ¡Un café por favor!

Imagina que perteneces a un Development Team que trabaja con Scrum. Los últimos Sprints han ido genial, habéis cumplido con vuestro Sprint Goal y en la Sprint Review los interesados han mostrado que el producto está dando buenos resultados en el mercado. Llegas el lunes por la mañana, anoche te acostaste tarde viendo tu serie favorita y te espera por delante una semana muy larga. ¡Necesitas un café! sin ese café no vas a poder trabajar bien, esto es un impedimento claro para tu trabajo y… ¿Quién resuelve impedimentos en Scrum? Entonces dices “Scrum Master, tengo un impedimento, ¡Tráeme un café por favor!, con doble de leche, sacarina y un par de galletas para mojar”.

Este ejemplo es un poco exagerado, lo admito, incluso puede que sea clasista, sin embargo hay mucha confusión sobre la frase “el Scrum Master resuelve impedimentos”. Vamos a analizar diferentes situaciones para determinar qué es y qué no es un impedimento y quién debe resolverlos.

Cuando comenzamos a aprender Scrum leemos de todo, guías, libros, manuales, posts o cualquier cosa. En todos siempre pone lo mismo “El Scrum Master resuelve impedimentos” y entonces entendemos que el Scrum Master tiene que ayudar al resto del Scrum Team. Simplificándolo mucho, hay dos maneras de entender este concepto: el héroe o el mago.

El Scrum Master héroe es el que se echa a la espalda al equipo, lo salva de todos los peligros, se lleva todos los “golpes” y es apreciado por hacerlo. El Scrum Master mago es el auténtico Scrum Master, es muy poderoso pero nunca es el protagonista. El mago en la ficción siempre es un personaje que ayuda al héroe a salir adelante y este es el Development Team y el Product Owner, los verdaderos héroes.

Impedimento 1: El Product Owner no tiene experiencia con Scrum

La figura del Product Owner es complicada. Es una pieza clave del proceso y contar con un buen Product Owner cuesta porque es un rol nuevo en el mercado y pocas personas tienen experiencia desempeñándolo. En muchas compañías todavía no existe y cuesta saber quién es la persona adecuada. Cuando comenzamos con un equipo nuevo el Scrum Master tiene que pasar mucho tiempo con el Product Owner enseñando Scrum para conseguir un aliado más en el equipo.

Enseñar a alguien que no tiene tiempo, no entiende su rol o tiene objetivos difíciles de cumplir es complicado y lleva tiempo. El Scrum Master héroe lo que hace es asumir el rol de Product Owner, escribir los elementos del Product Backlog o Historias de Usuario, hacer los refinamientos, clarificar las dudas funcionales o lo sustituye en eventos como la Sprint Planning o la Sprint Review. Cuando esto ocurre veremos a un Scrum Master que ha abandonado Scrum porque la figura mixta rompe el marco de trabajo, no está concebido para que recayera sobre una persona las dos funciones.

El Scrum Master mago se pasa horas enseñando a su Product Owner Scrum: su función en los eventos, cómo usar el Product Backlog, técnicas como las Historias de Usuario o el Plan de Releases. En este sentido una compañera nos explicaba que le costó 7 meses enseñar a su Product Owner a escribir una Historia de Usuario que fuera útil para el Development Team. ¡Lo fácil hubiera sido escribirlo ella!

Impedimento 2: Hay que hacer una reunión en cliente, ve tu Scrum Master

En ciertos contextos para poder avanzar en el desarrollo de productos necesitamos tener muchas reuniones con cliente. Hay muchos desarrolladores que esto lo identifican como un impedimento y le piden al Scrum Master que sea él quien coja el conocimiento necesario para ir a las reuniones y que vuelva con la información resultante. La excusa es que así maximizan el tiempo que pasan desarrollando pero… ¿Y el tiempo perdido por hacer de “teléfono escacharrado” o el tiempo explicándole al Scrum Master lo que tiene que decir?

Un Scrum Master héroe se convierte en la voz del equipo, analista funcional, experto técnico y protector del tiempo de desarrollo. Un Scrum Master mago fomenta la comunicación entre el Development Team, Product Owner e interesados. Si el problema es que las reuniones son poco efectivas por falta de foco un buen Scrum Master ayudará a productivarlas.  También puede ocurrir que haya un problema de fondo más grande como falta de objetivos o caos organizacional, un Scrum Master mago se remangará para profundizar en el problema en vez de soportar las consecuencias.

Impedimento 3: ¿Me puedo ir de vacaciones Scrum Master?

Las vacaciones, teletrabajo, permisos u otras situaciones hay que gestionarlas. Muchos desarrolladores piensan que la coordinación de las vacaciones es algo de Scrum Master porque es un impedimento a su trabajo.

El Scrum Master héroe se encargará de tomar nota de todas las vacaciones, validarlas, y en caso de conflicto apaciguar a los implicados. El Scrum Master mago fomentará la auto-organización y enseñará al Development Team que este tipo de ausencias afectan al resto de compañeros y que tendrán que organizarse para reducir el impacto. Por ejemplo, hay técnicas que un buen mago enseñará cómo crear reglas de equipo del estilo “siempre tiene que haber un front y un back” o tener un tablero de vacaciones para que visualicemos las ausencias y actuemos en consecuencia.

Impedimento 4: Manejar el Jira

Muchos equipos tienen digitalizada la información en algún tipo de herramienta como puede ser Jira. Es bastante típico que se le pida al Scrum Master que sea él quien lo actualice o que lo acabe haciendo porque sabe que es importante. Al final estará horas actualizando tareas, desplazándolas, asignándolas y generando informes.

El héroe lo hará pensando que así aumenta el tiempo que el Development Team está programando y generando incremento. El mago enseñará la responsabilidad de actualizar al Development Team y de que las herramientas que se vayan a utilizar deben ser efectivas. Sin embargo, a veces ocurre que Jira se convierte en un seguimiento tradicional para controlar al Development Team. En ese caso el buen Scrum Master mago enseña la función del Jira como herramienta de coordinación y que no se puede saturar al equipo en actualizaciones que no aportan valor.

Impedimento 5: El Scrum Master dirige la Daily Scrum

La Daily Scrum es un evento diario que se utiliza como sistema de coordinación y planificación para el Equipo de Desarrollo. Es un punto clave en el día para poner foco en nuestro Sprint Backlog. Muchos Scrum Masters asisten y tiene sentido en equipos poco maduros porque hay que enseñarles a hacerla bien pero realmente es el propio Development Team quien se responsabiliza.

El Scrum Master héroe será quien convoque la reunión, dará los turnos de palabra, lo convertirá en un evento de reporte, hará preguntas, animará el evento si es aburrido y bailará reggaeton si con ello cree que se hace bien. El Scrum Master mago se encargará de fomentar la autoorganización. Faltará muchos días para observar si el equipo asume el reto de llevar el evento. Aprenderá técnicas que ayuden a que el evento sea efectivo y las pondrá en práctica con ellos. Mi compañera Cristina de la Bandera se inventó la técnica del retrovisor o del examen sorpresa, con esas técnicas trataba de ayudar a su Development Team a descubrir el estado de su Sprint Goal.

Impedimento 6: ¡No llegamos al Sprint Goal!

Si hablamos de la Daily Scrum hay un punto importante de la misma que es el Sprint Goal. El Sprint Goal fue fijado en la Sprint Planning tras negociarlo el Development Team y el Product Owner. El Development Team se encarga de acometerlo y de organizarse para alcanzarlo. A veces descubren que no son capaces de llegar y lo que deben hacer es renegociar con el Product Owner el alcance fijado para tratar de conseguirlo. ¿Quién hace esta negociación? Muchos equipos piensan que esto es tarea del Scrum Master porque es su representante.

El Scrum Master héroe luchará por los intereses de su Development Team y renegociará con el Product Owner. El Scrum Master mago enseñará al Equipo de Desarrollo que esa es su responsabilidad y les podrá dar consejos pero serán ellos los que se comuniquen con el Product Owner. Tiene sentido que sea así porque el Development Team siempre tiene más información y experiencia.  

Impedimento 7: El Scrum Master presenta la Sprint Review

Otro de los eventos relevantes es la Sprint Review que ocurre al finalizar el Sprint previo a la Retrospectiva. En este evento el Product Owner debe rendir cuentas del estado del producto que se está construyendo y es una oportunidad maravillosa para que el Scrum Team le muestre a los Stakeholders toda la información de la que disponen. Muchos Product Owners creen que esta reunión es un reporte para él y realmente es él quien debe dirigir el evento y ser quien presente. El Development Team estará para mostrar el incremento finalizado.

Un Scrum Master héroe asume el papel de presentador del evento convirtiéndolo en una demo al Product Owner y sus stakeholders. Un buen Scrum Master mago enseñará a su Product Owner que este evento es suyo, que es vital para conocer el producto y gestionar expectativas. Un Scrum Master mago ayuda a prepararlo previamente en los primeros Sprints para que tome experiencia. Un compañero nos comentaba que se pasó meses haciendo “pre-reviews” hasta que el Product Owner entendió su función y se atrevió a hacerlo sin ayuda. El Scrum Master mago actúa en este evento igual que en la Daily Scrum, debe enseñar a hacerla pero no es responsable de su éxito.

Impedimento 8: Conflictos entre compañeros

Recordemos que en software casi siempre todo se hace en equipo. Los equipos lo componen personas y las personas a veces tiene conflictos entre ellas. Estos conflictos en entornos maduros deben ser resueltos por los propios compañeros pero muchas veces el Scrum Master actúa con el fin de hacer de apaciguador.

El Scrum Master héroe asume que el bienestar de todo el equipo es suyo y que los conflictos son su responsabilidad. Normalmente arbitra entre conflictos y toma parte entre ellos para evitar discusiones. El Scrum Master mago enseña a los equipos a buscar soluciones entre ellos, puede mediar escuchando ambas partes pero tratará de que sean ellos los que resuelvan las diferentes. En el caso de que el Development Team determine que un compañero debe salir del equipo el Scrum Master mago podrá ayudarles pero no debería ser iniciativa suya esa actuación.

Hemos podido ver 8 impedimentos bastante comunes y cómo actuar. Nos queda saber que es un impedimento. Como bien nos comentaba Barry Overeem en la Conferencia Agile Spain un impedimento es todo aquello que impida llegar al Sprint Goal y que impida la autoorganización del Development Team. Los problemas suelen aparecer más fuera del Equipo Scrum que dentro; el contexto que envuelve el equipo es el que le impide funcionar. Por eso, muchos expertos opinan que un buen Scrum Master hace un giro de 180º y en vez de mirar hacia el equipo mira hacia la organización. Un buen Scrum Master ayudará a su organización a ser más ágil porque eso permitirá a su equipo ser mejor; nadie dijo que fuera una tarea fácil sin embargo cuando funciona es muy gratificante.

Sabemos que ser héroe no es fácil, requiere llevarte muchos golpes y enfrentarte al peligro tu sólo. Sin embargo, ser un Scrum Master mago conlleva un beneficio mayor porque los peligros los afrontamos juntos aunque perdamos “protagonismo”. Ser mago es difícil y yo admiro a mis compañeros y compañeras  de Paradigma que son capaces de hacerlo de manera asombrosa, consiguiendo que los Equipos Scrum funcionen, estando presentes pero siendo invisibles.

¡Se Gandalf y no Frodo!