¿Qué hace un Scrum Master? (más allá de organizar reuniones) (1/3)

— Post escrito por Sergio Tiscar y Rubén Ortiz de Wolters Kluwer, primero de una serie de 3 que saldrá los martes

Scrum es con mucho el marco de trabajo ágil más adoptado por la comunidad, sus artefactos, eventos y roles ha ayudado muchísimo a que las organizaciones vayan incorporando los valores y principios ágiles a la forma de desarrollar sus productos y crear equipos de alto rendimiento.

La base de Scrum viene descrita en la guía (la oficial, que luego hay otras tantas adaptaciones), sin embargo, en nuestra opinión, deja muy abierta la interpretación de cómo llevar a la práctica los eventos y el significado de cada rol, lo que está llevando a muchas organizaciones, accidental o premeditadamente, a la llamada agilidad “cosmética” o “flácida”.

En el caso concreto del Scrum Master, muchas veces directamente se le cambia el nombre al clásico Jefe de Proyecto por el de Scrum Master, pensando que es simplemente un cambio de nombres, lo que lleva directamente a malas prácticas.

En una serie de tres artículos, uno por cada servicio descrito en la guía Scrum que debe prestar un Scrum Master, intentaremos concretar aquellos puntos mencionados en la guía a los que, típicamente, se dedicaría un Scrum Master, hablaremos de prácticas concretas, centrándonos sobre todo en aquella famosa pregunta de… ¿qué puede hacer un Scrum Master cuando no está llevando un evento (reunión de Scrum)?

Dejaremos en cursiva lo que dice la guía y veremos qué puede estar haciendo un scrum master en un día cualquiera.

Ver este vídeo en YouTube.

Veremos la amplitud de competencias a las que se puede dedicar un Scrum master si está a jornada completa. Tras verlo, quizás tendremos más claro si es conveniente que el rol del Scrum Master pueda ser un trabajo rotatorio, a tiempo parcial, o no.

Entrando ya en faena, si vamos a la guía Scrum, veremos que nos dice que el Scrum Master debe realizar tres servicios:

  • El servicio del Scrum Master al Propietario del Product (Product Owner)
  • El servicio del Scrum Master al Equipo de Desarrollo (Development Team)
  • El servicio del Scrum Master a la Organización

Hoy empezamos con el primero de ellos…

El servicio del Scrum Master al Propietario del Product (Product Owner)

“Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum (Scrum Team) de la mejor manera posible;”

Durante un día cualquiera, fuera de una reunión de Scrum, un Scrum Master podría…

Ponerse a revisar historias de usuario que se están refinando por si hay cosas que no le cuadran.  Las historias de usuario nos ayudan a cumplir algunos de los grandes objetivos de la agilidad: aportar valor cuanto antes, aprender de las necesidades del cliente, aprender de nuestros errores, saber realmente dónde estamos, mejorar nuestras integraciones… en fin, parecen un elemento de gran ayuda, por lo que si realmente queremos ser ágiles, un Scrum Master debería dedicar parte de su tiempo a ver si realmente las historias son historias, y poco a poco enseñar a que se comprenda… ¿Qué es una historia? ¿Por qué nos pueden ayudar? ¿Cómo hacerlas?

Promover (empujar) a que se junten los “tres amigos” a refinar historias de usuario o facilitar una reunión de refinamiento (ojo con el Scrum Master secretario). Digamos, que el Scrum Master debería estar detrás del Dev Team y del Product Owner para que los refinamientos se vayan haciendo.

Fijarse en el panel y en caso de que nos estemos desviando con respecto al objetivo del Sprint, o que se estén implementando primero las historias menos prioritarias, o muchas historias en paralelo, recordárselo al equipo. El sprint backlog tiene una priorización y está para algo.

Un resumen de tareas del Scrum Master:

  • Revisar el panel para ver si se está siguiendo la prioridad adecuada
  • Recordar si alguien está haciendo algo que no está en panel y que no haya priorizado un Product Owner.
  • Recordar al equipo si se están haciendo muchas cosas en paralelo (como consecuencia de que no haya swarming)
  • Revisar si el equipo no está atendiendo algo importante que haya llegado de forma urgente (para casos en los que en el panel aparezcan incidencias no planificadas)
  • Si hay alguna historia de usuario que entró en un Sprint Planning que tiene cierto compromiso de entrega y va alineada con los objetivos del Sprint desde el punto de vista de negocio, recordad al equipo su importancia y asegurar que están organizados para que se cumpla el compromiso de entrega.
  • Revisar el Sprint Backlog que tiene pensado el Product Owner para el siguiente Sprint y juntarse con él para ayudarle a reflexionar si de verdad es la priorización que el usuario final y la organización espera, aconsejándole en caso de ver cambios de objetivos con respecto al sprint anterior y en general cualquier cosa que le llame la atención. Priorizar un sprint es de las cosas más complicadas que hay y la ayuda de cualquier persona al Product Owner es muy importante.
  • Revisar el DoR para ver si se puede ir eliminando algo que «huela a cascada», como ocurre a veces con requerir que esté especificado todo hasta el último detalle, recordemos que la N de INVEST es «negociable», en una historia de usuario no tiene por qué estar el 100% definido antes de comenzar a implementarla.

«Encontrar técnicas para gestionar la Pila del Producto (Product Backlog) de manera efectiva;»

Durante un día cualquiera, fuera de una reunión de Scrum, un Scrum master podría investigar si hay la herramienta actual de gestión del backlog está sirviendo al Product Owner para su priorización y mantenimiento y en caso contrario buscar alternativas. Y revisar el Product Backlog buscando:

  • Que solo haya historias, no tareas sueltas sin un valor de negocio claro
  • Que el backlog tenga un tamaño adecuado
  • Que no se produzca desperdicio y tengamos un backlog en formato DEEP, con más detalle cuanto más arriba estén los PBI’s y menos detalle según bajas.
  • Hacer limpieza continua del backlog eliminando aquellos elementos que no aporten tanto valor 
  • Hacer que el propio backlog pueda estar en un formato tan comprensible que permita saber de forma rápida lo que, actualmente, nos falta por hacer.

Con los problemas que se encuentre, proponer al Product Owner su modificación, eliminación, o moverlo a otro sitio “que no moleste”.

Recordemos que a la hora de hacer un sprint backlog tenemos que seleccionar, y no es lo mismo para un Product Owner revisar un product backlog con 50 pbi’s que con 800

  • Ayudar al Product Owner a crear/mantener un mapa de historias de usuario que le ayude a tener una visión que le ayude a la hora de priorizar
  • Explicar y ayudar a aplicar técnicas como puede ser un mapa visual para que el backlog sea mucho más entendible y que por ejemplo pueda utilizarse en una review de forma que el PO pueda informar a stakeholders de:
    • Por dónde vamos,
    • Qué hemos hecho,
    • Qué queda por hacer,
    • Qué pensamos hacer en el próximo sprint,

Gracias a ésto podemos implicar mucho más a stakeholders y hacer, por ejemplo, la review mucho más colaborativa, lo que ayudará al PO a tener más información que le permita afinar más la priorización.

4 comentarios en “¿Qué hace un Scrum Master? (más allá de organizar reuniones) (1/3)”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba