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

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

Enlace al primer post de esta serie.

«Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Pila del producto claros y concisos;»

Durante un día cualquiera, fuera de una reunión de Scrum, un Scrum master podría preparar una sesión con el equipo para explicar lo que es el Discovery Track y la importancia de reflejarlo en el panel para darle visibilidad

Fijarse en si se están refinando las historias de usuario que el Product Owner va a planificar para el siguiente Sprint, promover o convocar directamente reuniones de refinamiento, y que se junten los “tres amigos”, que estos refinamientos sean visibles en panel es muy importante. Estar detrás de que las tareas de discovery llegan al DoR esperado, y que son incluso enseñables a Stakeholders en la Review.

Preparar una formación de Gherkin para el equipo y Product Owner para que empiece a haber un lenguaje común, o una sesión de repaso sobre cómo hemos ido adoptando esa medida.

Revisar el Product Backlog en busca de elementos que no sean historias de usuario o Spikes, que no tengan un tamaño grande o muy pequeño.

Reunirse con los tres amigos (PO, QA, Developer), para pensar cómo fragmentar épicas en historias de usuario INVEST

Ayudar al PO a organizar en épicas el Backlog.

Preparar reuniones tipo Lean Inception que pueden ayudar a generar Backlog y hacerlo más entendible, no solo al equipo, sino a Stakeholders y en general al ecosistema del producto.

«Entender la planificación del producto en un entorno empírico;»

Sentarse con el PO para revisar la velocidad del equipo y si considera que es suficiente y si se está entregando el valor esperado al cliente.

Si intentas maximizar el valor entregado en el menor tiempo harás que se priorice cada vez más por valor y que el equipo intente eliminar desperdicios para cada vez entregar más rápido, creando así una cultura de Inspección y Adaptación, que son pilares fundamentales de Scrum. Este cambio de cultura debería hacer que cada vez se miren menos las fechas y las planificaciones.

«Asegurar que el Propietario del Producto (Product Owner) conozca cómo ordenar la Pila del Producto (Product Backlog) para maximizar el valor;»

Durante un día cualquiera, fuera de una reunión de Scrum, un Scrum Master podría investigar herramientas que ayuden al Product Owner a comprender la percepción de valor del usuario final (gestión comercial, analytics, recepción de comentarios, mapas de calor, fake doors, etc.). Y, en caso de existir, revisar el feedback de los usuarios finales, teniendo así información para aconsejar al Product Owner sobre la priorización.

Revisar el Product Backlog para ver si los ítems tienen un valor de negocio definido y ayudar al Product Owner a que defina un valor interpretando la información que ha recibido desde las diferentes fuentes de información. Ayudar al product owner a decidir un orden entre un PBI u otro cuando tienen el mismo valor de negocio.

Ayudar al PO a construir/mantener herramientas que ayuden al PO a ordenar un Backlog como pueden ser un mapa de historias de usuario, un user story flow o simplemente experimentar y hacer ejercicios tipo pintar y ordenar en la pizarra las ideas, dependencias y valor que podría aportar.

«Entender y practicar la agilidad; y,»

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

Dar una formación al Product Owner o al equipo sobre: pilares de la agilidad, como funcionan y qué se consigue en cada uno de los eventos de Scrum, qué son las historias de usuario, mapas de historias de usuario, Gherkin, etc.

Mandar artículos, vídeos, etc., que aclaren los conceptos peor entendidos al Product Owner y al equipo, pequeñas píldoras que hagan calar los valores ágiles.

Acostumbrar a lo bueno a la organización. Algún ejemplo:

    • Dentro de una review, una buena demo en donde quede claro el estado del producto en vez de un Gant o un burndown chart,  es algo que suele gustar, puede que al principio la dirección solo lo tomen como un elemento de seguimiento y no le saque más rendimiento que ese, pero ya empiezan a acostumbrarse y será un primer paso ganado para llegar a metas mayores como la obtención de su feedback, o aprovechar esa review para que cada vez venga más y más gente que pueda ayudar a validar si lo que se está haciendo o lo que se hará en el próximo sprint ayuda a maximizar el valor.
    • Aprovechar el panel para que no solo sea entendible por el equipo, sino que además actúe de radiador de información para Product Owners y stakeholders y pueda ayudarles a, simplemente echando un vistazo rápido, saber el estado en tiempo real del estado del equipo. No quiere decir que gente externa al equipo entiendan las tareas en las que se divide una historia de usuario, pero sí que puedan saber el estado de los PBI’s, si están en Todo/In Progress/Done, o si hay algo con algún bloqueo externo al equipo, etc. Recordemos que en agilidad no hacemos reportes diarios de progreso, el panel puede y debe radiar información suficiente para que cualquiera lo entienda. Además, si un panel cumple su tarea primordial, que es ayudar a la auto-organización, éste debería ser sencillo, y si es sencillo, todo el mundo debería entenderlo sin problemas.

«Facilitar los eventos de Scrum según se requiera o necesite.»

Aquí entramos ya en las propias reuniones o eventos de scrum donde en este artículo no queremos entrar mucho, simplemente unas pinceladas de la preparación de las reuniones:

  1. Ayudar al equipo o P.O a convocar las reuniones de scrum, buscando sala o lugar adecuado, etc.: (Mucho ojo con los Scrum Master secretario que hacen esto en exclusiva…) 
  2. Preparar el Planning Meeting pensando en maneras que ayuden a que la segunda parte donde se habla del “cómo” implementaremos se haga de la manera más colaborativa posible, facilitando la participación entre la mayoría de los componentes del equipo.
  3. Ayudar al Product Owner a preparar el planning meeting
  4. Ayudar al equipo y al Product Owner a preparar y hacer la review para conseguir de stakeholders el mayor feedback posible, explicando que es un punto de chequeo en donde ver si hemos generado valor, si hemos ayudado al negocio en el anterior sprint. Un Scrum Master debería hacer consciente primero al PO, y posteriormente a stakeholders del valor de una review. Hacer que sea para ellos una reunión de trabajo en la que deben estar totalmente implicados, y no en una actitud de «a ver qué han hecho estos chicos de desarrollo». Ayudar y proponer herramientas o técnicas que permitan una mejor comunicación y aporte de feedback por ambos sentidos: desde el equipo hacia los stakeholders como de éstos últimos hacia el equipo.
  5. Preparar la retrospectiva: haciendo inventario de cosas que como Scrum master has visto que se han hecho bien y no, buscando la técnica más adecuada para ese momento, preparar materiales, sala, etc., si hace falta algo especial. Imaginaros al Scrum master como un entrenador que ha ido apuntando aquello que se ha hecho mal durante el partido y que no hemos conseguido corregir en ese momento y que se lo lleva a una retrospectiva después del partido para ayudar al equipo a que no se le olvide nada de lo que ocurrió y pueda reflexionar sobre ello. No se trata de solo preguntar al equipo ¿qué no ha salido bien en este sprint? sino de llevar tu lista que como «entrenador» has visto «desde la banda» durante el sprint. 
  6. Preparar el Daily Meeting antes sacando las preguntas adecuadas para que cuando tenga lugar ayudar al equipo de la manera más efectiva: asegurando que el equipo queda sincronizado (todos enterados de los bloqueos o necesidades de ayuda externa o interna), que sepan trazar un plan para las 24h próximas horas antes del siguiente Daily de forma que optimicen las opciones de acercarse al objetivo del sprint, que el panel quede actualizado y sea sencillo de comprender para fomentar la auto-organización, y que se ponen en marcha medidas para desbloquear lo necesario. 

Como vemos, ya simplemente el servicio al Product Owner de un Scrum Master da para mucho y da que pensar el no tener a alguien dedicado al 100% a ser Scrum Master si nos planteamos hacer muchos de estas prácticas.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

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

Dejar un comentario

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