La figura del Scrum Master es una pieza importante de la transformación de muchas organizaciones. En algunas de ellas, es clave porque le piden las labores de un Jefe de Proyectos y esas funciones son esenciales en cada equipo. En otras organizaciones, es la figura menor de Scrum porque el protagonismo se lo llevan los Agile Coach o, mejor aún, los Enterprise Agile Coach.
¿Qué hace un Scrum Master? Su responsabilidad principal es que se haga Scrum ajustándose a sus reglas, valores y principios. Así dicho, parece fácil si no fuera porque Scrum es muy difícil de dominar tal y como explican Ken y Jeff en la Scrum Guide.
Esto que es tan bonito, la propia Scrum Guide lo ejemplifica en tres partes diferenciadas: cómo ayudar al Development Team, cómo ayudar al Product Owner y cómo ayudar a la Organización. ¡Analizamos cada uno de ellos!
Acompañando al Development Team
Acompañar al Development Team es una labor bastante importante. La cultura de desarrollo ágil promueve que sean los equipos los que se organicen mediante inteligencia colectiva. Esto es difícil porque venimos de un mundo donde nos han enseñado a responder ante el “jefe”. A la mayoría de nosotros en el colegio nos mandaban deberes y debíamos dar respuesta, pocas veces trabajábamos en equipo. Los exámenes son individuales y en las organizaciones tradicionales venimos de trabajar esperando a que el jefe nos diga algo.
El reto más importante es enseñar al Development Team a ser autoorganizado y multidisciplinar. La autoorganización y la multidisciplinaridad requieren: trabajar en equipo, compartir opiniones, no tener etiquetas y a compartir la responsabilidad. Todo esto supone que si una persona se equivoca, nos equivocamos todos, por tanto debemos de mirar más allá de nuestro trabajo en el día a día. Un ejemplo es la Daily Scrum, desde mi punto de vista, los miembros de equipos menos maduros asisten a la Daily Scrum a contar lo que han hecho. Sin embargo, cuando están en un equipo con más experiencia, la Daily es un ejercicio de escucha activa para poder coordinarnos y hacerlo mejor.
Hay muchas técnicas que podemos probar: dejar a un equipo en algún evento “solos” para que actúen, dejar que se equivoquen y tener métricas que permitan entender el fallo (para que no se convierta en algo subjetivo) o hacer preguntas que les inviten a reflexionar sobre cómo trabajan. Recordemos, que los protagonistas son ellos, ya que son los que entregan el valor que genera el equipo.
Acompañando al Product Owner
El Product Owner es un rol imprescindible en Scrum ya que gestiona la demanda y expectativas de nuestro producto. Recordemos que la definición formal es “maximizar valor”. Por tanto, hay que definir qué es valor. Además, tenemos que tener contacto con los receptores de ese valor para contrastar que lo que hacemos les aporta. Por supuesto, deberemos medir la rentabilidad del producto y que nos alineamos con la estrategia de la organización. Estas son algunas labores que podemos comentar.
Esta figura no existía en las organizaciones tradicionales, y al introducir Scrum tenemos que enseñar al Product Owner a saber hacer su papel (sin sustituirlo). Cómo Scrum Master, a veces nos cuesta trabajar con el Product Owner por diferentes motivos: es una persona de negocio que suele estar en otra planta, que gana más dinero, que es más importante o que desde la organización se la considera más importante, o bien es un cliente, o porque directamente no tiene intención de mejorar con tu trabajo. Por un motivo u otro, a veces nos suele costar tratar con el Product Owner.
Sin embargo, ayudar al Product Owner a ser un Professional Product Owner que sepa gestionar producto es clave si queremos que el equipo funcione. Para ello, un Scrum Master enseña técnicas: cómo priorizar, cómo tratar con los stakeholders, cómo medir, etc. El Scrum Master ayudará al Product Owner a empatizar con el Development Team y a que sean un Scrum Team de verdad. Este nivel es difícil, el Product Owner tendrá jefes y estos le exigirán fechas y luchar contra esto es una labor muy complicada.
Transformando la Organización
La tercera labor y posiblemente la más desconocida es la Transformación de la Organización en la que estamos. Scrum asume que las organizaciones no han interiorizado Scrum, y esto afecta a los Equipos en la entrega de valor. Un Scrum Master no solo busca el beneficio del equipo, buscamos la Transformación de la Organización para el beneficio de todos (incluído nuestro equipo).
Hoy en día, en las organizaciones se delega este papel transformacional a los Agile Coach. Las organizaciones están promoviendo una jerarquía donde el Agile Coach es más importante que el Scrum Master (y no hablemos del Enterprise Agile Coach que es todavía más importante). Sin embargo, creo firmemente que el Scrum Master debería abordar esa transformación. Está en el barro, ve los problemas y puede demostrar como un cambio en la organización impacta en la entrega de valor de su equipo: ¡puede demostrar las cosas!
Algunas organizaciones han tendido a que los Scrum Master acaben haciendo labores que tradicionalmente han desempeñado Jefes de Proyectos, labores que les consumen mucho tiempo y les impide desempeñar su función principal, transformar la empresa. Además, las organizaciones no esperan de un Scrum Master que realice transformación. Esto hace que muchas veces no se les escucha. Desde mi punto de vista, los Agile Coach desde el trono de hierro hablando con la dirección tienen menos opciones de transformar que un Scrum Master entregando valor con un equipo de Desarrollo donde podemos experimentar.
La evolución del Scrum Master
Hay Scrum Master que primero atacan a la organización porque descubren por ejemplo que su equipo no tiene alguna habilidad incorporada, ¿calidad?, y necesitan un cambio estructural. Otros empiezan con el Product Owner porque se han encontrado sin una buena definición de producto que evita que el Development Team pueda autoorganizarse. Otros Scrum Master entrenan primero al Development Team para entregar valor rápido y con ello transformar la organización y con ello ganarse la confianza de la capa de gestión. Ninguna aproximación es mejor o peor que la anterior, todo depende del contexto. Lo verdaderamente importante es no quedarse en un sólo ámbito y ayudar a mejorar en todos los frentes.
Por tanto, ¿cómo es la evolución de un Scrum Master? Quizás la respuesta sea compleja, digamos que dependerá del contexto en el que trabajemos y de nuestra intuición. Hay Scrum Master que han aprendido mucho de negocio por su contexto y otros de técnicas de desarrollo, ¡todo nos hace evolucionar!
¿Qué camino has seguido tú como Scrum Master?.
