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

— Post escrito por Sergio Tiscar y Rubén Ortiz de Wolters Kluwer, tercero de una serie de 3

Enlace al primer post de esta serie.

Enlace al segundo post de esta serie.

Siguiendo con la serie de artículos en donde vemos en detalle tareas que puede hacer un Scrum Master, hoy nos vamos a centrar en el servicio que presta al equipo de desarrollo. Seguiremos el mismo formato de la otra vez, en donde dejaremos en cursiva lo que dice la guía y añadiremos debajo una serie de prácticas que ayudan a conseguir lo que dice la guía.

El servicio del Scrum Master al Equipo de Desarrollo (Development Team)

Sobre este punto esto es lo que pone en la guía…

«Guiar al Equipo de Desarrollo (Development Team) en ser auto-organizado y multifuncional»

Sobre este punto, durante un día cualquiera, fuera de una reunión de scrum, un scrum master podría…

Revisar el panel para ver si hay suficiente “swarming” o trabajo colaborativo para llevar al Done las historias de usuario/spikes que hay en curso y plantear al equipo la situación en caso de parezca que hay solo una o dos personas trabajando en las historias de usuario en curso. Ej: “equipo, veo que en la User Story 1 solo está trabajando Juan, ¿no podría ayudarle alguien para llevarla al Done antes y que no solo se quede él con el conocimiento de cómo se ha implementado?”. Sobre esto no hace falta esperar a un daily meeting para comentarlo con el equipo. 

Revisar si en el panel hay personas que estén trabajando en paralelo en varias tareas en curso y en caso afirmativo recordar a la persona que se intente centrar. En general trabajar en varias cosas a la vez genera un desperdicio por el cambio de foco.

Hacer consciente al equipo que un componente ha pedido ayuda hace rato de un tema y nadie le ha hecho mucho caso. 

Revisar si hay personas que en ese momento no están trabajando en nada del panel. Esto puede ser un síntoma de que: 1) hay stakeholders que están pidiendo cosas sin pasar por el product owner, 2) que hay gente que no sabe qué tarea coger del panel porque no tiene desarrolladas sus habilidades en T o no habla lo suficiente con el equipo, 3) que está a «sus cosas» . 

Revisar si hay tareas que tienen bloqueos o están atascadas y promover que alguien ayude a quién está con ello en caso de que se pueda. Esto es algo que se puede hacer en un daily pero no hace falta esperar a este momento.

Fijarse en cómo está trabajando el equipo en la implementación de las user stories o spikes. Este es un punto muy importante ya que viene a ser fijarse en cómo están «jugando los jugadores en el campo», por ejemplo:

  • ¿se están comunicando bien?
  • ¿se reparten bien las tareas?
  • ¿están utilizando los medios para coordinarse? (salas, pizarras, proponer una reunión, etc.)

En caso de detectar descoordinación proponer soluciones como: 

  • Pair programming
  • Sesión de pizarra
  • Reunión con los implicados para que aclaren y repartan bien el trabajo

Revisar el panel y avisar al equipo en caso de que no se esté atendiendo a alguna incidencia que haya llegado de forma urgente (en caso de entrada de incidencias no planificadas)

Revisar la matriz de competencias del equipo para ver cuáles deberían ser los siguientes pasos en la evolución de los componentes del equipo, comentando con los managers en caso de necesidades formativas particulares fuera del equipo.

Revisar si hay personas del equipo que estén trabajando de forma aislada de forma recurrente y hablar con ellos con el objetivo de ver de qué forma se pueden integrar mejor en el equipo.

Revisar si en el panel hay PBI’s que no se pueden abordar bien porque no todo el mundo tiene skills para ello, el resultado se puede llevar a una retrospectiva.

Investigar qué prácticas ágiles se podrían plantear al equipo para mejorar la entrega continua de valor en cuanto a:

  • QA Ágil
  • Mayor colaboración entre los miembros del equipo
  • Despliegue continuo
  • Etc…

Montar/revisar el delegation board del equipo para ver si hay algún aspecto en el que el equipo pueda mejorar en nivel de delegación, por ejemplo: cómo se gestionan las versiones, la concesión de días de vacaciones, etc. 

Preparar una formación sobre “comunicación no violenta” para ayudar a que el equipo mejore en su comunicación. También podría ser recordar buenos ejemplos de comunicación o poner malos ejemplos de comunicación no violenta.

Ayudar al equipo a trabajar concentrado:

  • Avisándoles si se eleva el nivel de ruido en su zona por los miembros del equipo emplazándoles a utilizar las salas para reuniones
  • Preparando una sesión para enseñarles la técnica de Pomodoro, recordarles si la están utilizando.
  • Plantear medidas para controlar los momentos de interrupción
  • Si no hay más remedio plantear el uso de auriculares con ruido blanco

Proteger al equipo ante interrupciones internas o externas

  • Hablando con la persona a la que están interrumpiendo varias veces para ver qué se puede hacer, o con el que interrumpe a menudo. 

Revisar si las medidas de mejora acordadas en la retrospectiva se están llevando a cabo, para ésto lo mejor y recomendado es llevarlas al panel y priorizar su ejecución como si fuese cualquier otro PBI más,  y en caso contrario comentarlo al equipo (por correo, en directo, etc.), sin tener que esperar a un daily meeting. Por ejemplo: si el equipo ha acordado avisar de forma gráfica en el panel cuando hay algún bloqueo y no se está haciendo recordarlo. Este punto es muy importante, muchas veces se plantean acciones en la retrospectiva pero luego no se llevan a cabo porque a los componentes del equipo se les olvida. Lo mejor para esto es llevarlo al panel y ver su progreso dentro del sprint.

Preguntando al equipo por quienes son los más idóneos para asistir a un refinamiento o cualquier otro evento que pueda surgir, así estás forzando a que se organicen. 

Promover y guiar en la utilización de prácticas de Extreme Programming que ayuden a entregar cada poco tiempo, a incrementar la calidad, a rebajar la deuda técnica,…

«Ayudar al Equipo de Desarrollo (Development Team) a crear productos de alto valor; «

 Sobre este punto, durante un día cualquiera, fuera de una reunión de scrum, un scrum master podría…

Preparar y recordar al equipo por correo o presencial cual es el objetivo del sprint y la misión del equipo, y los compromisos que podamos tener, animando para que el equipo sea capaz de cumplirlo

Revisar el panel y asegurar que se está cumpliendo el DoD acordado, y en caso de que haya alguna tarea del DoD que no se esté haciendo recordarlo al equipo. Lo normal es que si se ha hecho un buen planning todas las tareas el DoD deberían estar ya en el panel, pero el scrum master debería asegurarse de eso.

Juntarse con el equipo para ayudarles a hacer inventario de la deuda técnica de cara a proponer mejoras al product owner en siguientes sprints.

Revisar los OKR’s (objetivos corporativos) que tiene el equipo para dar feedback al PO y al equipo de si se están cumpliendo de cara a priorizar siguientes sprints. 

Investigar y reflexionar sobre cuáles podrían ser los próximos pasos a dar para hacer el DoD un poco más exigente sin que afecte de manera significativa al ritmo del equipo. Dejarlo suficientemente preparado para comentarlo con el PO y con el equipo dentro o fuera de una retrospectiva. En este aspecto se nota mucho si el Scrum Master ayuda a ser mejores al equipo o no.

«Eliminar impedimentos para el progreso del Equipo de Desarrollo (Development Team)»

Ayudar al equipo en caso de que haya impedimentos externos que resolver, esto no significa que sea el SM el que se encarga de hablar con agentes externos, el SM debe ayudar en la comunicación, escalado, etc, pero el equipo debe ir mejorando para aprender a resolver esos bloqueos por si solos.

Promover que se junten componentes del equipo en caso de que exista algún bloqueo interno y nos que están involucrados en ello son incapaces de resolverlo. Ejemplo: entre tres están desarrollando una historia de usuario pero están atascados y son incapaces por si solos de apoyarse en otro miembro del equipo.

Revisar el panel y asegurar que queda de manera que cualquier miembro del equipo lo entiende bien, tanto los PBI’s como las tareas que hay pendientes para llevar a Done los PBI’s. El Scrum Master debe ser el que recuerde al equipo que hay que ser «buen ciudadano» y actualizar el panel pensando en los demás:

«Facilitar los eventos de Scrum según se requiera o necesite; y, «

De esto ya hemos hablado en la sección anterior con referencia al servicio al product owner.

«Guiar al Equipo de Desarrollo (Development Team) en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.»

En este sentido un Scrum Master podría estar preparando:

  • Una sesión periódica (agile corner público) donde se van explicando conceptos de agilidad con la idea de que vaya calando en la organización completa.
  • Alguna pequeña píldora para comentar en una review/refinamiento donde hay stakeholders

Además de estas competencias, entendemos que un scrum master debe tener también estas otras:

«Servir de termostato para el equipo para mantener el nivel de motivación durante el sprint»

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

Estar preparando un mensaje de ánimo al equipo para la consecución del objetivo del sprint (por correo, slack, en el daily, etc.). Tomando el símil deportivo, podría ser animar desde la banda a todos en general.

Acercarse a dar “palmadas en la espalda” o “palabras de ánimo” a aquel o aquellos que están haciendo algo complejo/duro durante este sprint, tanteando si ves la necesidad de que alguien le apoye. Por ejemplo: “¿Qué tal lo llevas? ¿Se está complicando la cosa? Bueno, seguro que lo sacas. Si hace falta ayuda pídela al equipo. Bueno, ya queda poco y te pones con algo mejor.”

Preparar un mensaje conciliador para personas que están teniendo cierto enfrentamiento dentro del sprint y dárselo para “bajar los humos”. Se podría dar de forma presencial juntando a las partes, por correo, etc.

Generar tensión/recordatorio al equipo para que no se despisten si hay compromisos de entrega para una fecha concreta que no se pueden demorar.

Revisar el panel niko niko diariamente y preguntar a los que no estén muy animados por si puede hacer algo para solucionarlo, no esperar al final de sprint a una retrospectiva.

«Ayudar en el desarrollo de las personas» 

Un día cualquiera, un scrum master podría estar dedicado a:

Preparar y dar feedback a un manager sobre una o varias personas del equipo, sobre cómo le ve trabajando, su motivación, el desarrollo de su T y las competencias que necesita para este equipo, etc., de cara a plantear sus necesidades formativas, la posibilidad de cambio de equipo, una posible promoción a otro puesto, etc.

Preparar y hablar con algún componente del equipo la posibilidad de utilizar alguna práctica que le pueda ayudar en su desarrollo y al final en la velocidad del propio equipo, por ejemplo: code reviews, pair programming, sesiones de transmisión de conocimiento dentro del propio equipo para mejorar en la matriz de habilidades del equipo, etc. 

Ya hemos hablado de ello, pero un Scrum master que promulga y enseña los beneficio de que un equipo aplique técnicas como pueden ser el pair programming o code review, ya está ayudando al desarrollo de las personas. Cualquier programador al que le hacen code review va a aprender mucho más que si no se lo hacen,. Si se hacen bien y al que se lo hacen aprovecha el conocimiento que puede sacarse de ellos, crecerá muchísimo más profesionalmente.

¿En serio que todavía no sabes qué puede hacer un Scrum Master cuando no está en una reunión/evento de Scrum?

Deja un comentario

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

Share This
Ir arriba