¿Qué hacen los Scrum Masters todo el día?

Personalmente, he asumido responsabilidades adicionales que no necesariamente corresponden a un equipo, por ejemplo, como administrar las licencias de software de las empresas.

Generalmente ayudando en el buen funcionamiento de la oficina, ayudando a la gerencia con tareas no relacionadas con el desarrollo. Investigando nuevos temas ágiles.

Además, vincularse con otros maestros de scrum para garantizar que la experiencia de scrum esté lo más alineada posible en toda la empresa.

Pero bueno... así soy yo

He trabajado como gerente de proyectos durante 15 años y he estado trabajando como scrum master a tiempo parcial (de los 15 años de trabajo de PM) durante 3 años y a tiempo completo como scrum master durante 3 años. Esto es lo que suelo hacer, pero al final mi trabajo es ayudar a los equipos a ser lo más productivos, efectivos y eficientes posible para ofrecer el mayor valor comercial posible en cada versión:

1. Facilite sesiones de planificación de retrospectivas, sprints y lanzamientos. Esto implica toda la planificación inicial necesaria para que las reuniones sean efectivas. Para retros, veré cómo le ha ido al equipo y elegiré un plan retro que se ajuste bien a las necesidades del equipo en ese momento. Para la planificación, revisaré todas las métricas que he estado capturando para el sprint o el lanzamiento (velocidades de sprint y lanzamiento, rendimiento, tiempos de ciclo de historia y finalización de funciones, y WIP). Intento no hacer standups diarios (también conocidos como scrums diarios). Dejo que el equipo haga eso, ya que es su reunión. Intervendré sólo cuando sea necesario.

2. Seguimiento de métricas de historias y características. Lo uso para seguir el rendimiento del equipo. Utilizo diagramas de velocidad, tiempo de ciclo, WIP, rendimiento y flujo acumulativo. Usaré esta información para brindársela al equipo antes de todos los retros para que tengamos hechos para respaldar nuestra conversación en lugar de conjeturas.

3. Soy un maestro de scrum para dos equipos, por lo que mi tiempo se divide entre los dos. Aún así, tengo algún tiempo de inactividad en el medio. Entonces, ¿qué más hago?

4. Tengo reuniones 1 a 1 con los miembros del equipo (generalmente algunas veces durante el sprint) para ver cómo les va y qué puedo hacer para ayudarlos como miembro del equipo y en su crecimiento profesional. Trabajaré con su gerente funcional para ayudar a los miembros del equipo a lograr sus objetivos tratando de exponerlos a nuevos módulos de la aplicación o administrar la capacidad del equipo para que se capaciten donde sea necesario.

5. Trabajo en proyectos paralelos como iniciativas de mejora de procesos. He trabajado con grupos de control de calidad para ayudar a construir una comunidad de práctica de control de calidad, por ejemplo. He asesorado y entrenado a otros Scrum Masters y Product Owners. También suelo facilitar retrospectivas de lanzamientos, lo que requiere semanas de preparación y colaboración con otros scrum masters y la gerencia para asegurarme de que sea un buen uso del tiempo de todos. Luego haré un seguimiento con cualquier elemento de acción que surja de él.

6. Trabajo con maestros de scrum de otros productos para compartir ideas y colaborar en nuevas herramientas, técnicas y demás.

7. Hago sesiones de capacitación con equipos sobre cómo realizar presentaciones (internas / externas) y les enseño sobre diferentes temas ágiles (scrum, lean, kanban, navegación de conflictos, etc.).

Aprender. Lee blogs, libros, artículos científicos o lo que te guste hacer para aprender. O código en nuevos idiomas. Cualquier cosa que se te ocurra que el equipo podría beneficiarse más adelante. Una de las cosas más importantes que hace el SM es aprender. Sobre el equipo, sobre la organización y estar siempre al acecho de cosas nuevas para probar. Si está realmente aburrido, siempre puede encontrar otros Scrum Masters aburridos y probar un taller o simplemente hablar mientras toman un café si tienen algunas ideas sobre qué hacer.

En mi experiencia... depende. Depende de la etapa en la que se encuentre el equipo, por lo general, los equipos nuevos necesitan mucho entrenamiento porque generalmente tienen muy poco conocimiento o no saben por qué suceden algunas cosas. (A un desarrollador le resultó tedioso tener "sesiones de actualización de estado" de 15 minutos en sus proyectos anteriores).

Muchas de mis tareas pendientes suelen ser artículos retro que propone el equipo. Esto se debe a que he tenido que trabajar con grandes organizaciones donde hay dependencias de varios equipos.

Además, no está relacionado con ágil en absoluto, pero ha sido una experiencia común que he sido el punto de contacto con una parte interesada o un cliente cuando quieren informes detallados o quieren un representante del equipo en una reunión. Con mucho gusto asistiría siempre y cuando no saquen a nadie del equipo porque existe el riesgo de ser arrastrado a demasiadas reuniones que evito para cualquier miembro del equipo.