noviembre 27, 2018

Scrum master a tiempo completo: 42 Tareas

Uno de los artículos que más referencio en mi formación en Scrum cuando hablo de las labores del Scrum Master es: 42-tasks-for-a-scrum-masters-job. Por alguna razón, todo el mundo parece entender que el Product Owner es un trabajo a tiempo completo, o ser miembro de un equipo también, pero que probablemente el rol del Scrum Master puede ser realizado a media jornada o incluso menos.
El scrum master también tiene mucho trabajo en equipos medianos o grandes, o nuevos. Y es preferible que se centre en sus tares como scrum master, compartiendo su trabajo entre dos equipos por ejemplo, que trabajar también con la gorra compartida de miembro del equipo. ¿Por qué? Por que las labores que tenderá hacer son las de desarrollador antes que las de scrum master.

He querido traducir este artículo, para que quede en castellano, con permiso de Bernd Schiffer, para que quede constancia, y pueda referenciarlo en nuestro idioma :)

Artículo original: 42 Tasks for a Scrum Master’s Job

Las siguientes preguntas aparecen a menudo cuando realizo formaciones o consultorías en Scrum:

¿Por qué los roles de Scrum Master y Project Manager deberían ser llevados por personas diferentes? (Quora)
¿Será el Scrum Master una ocupación al 100% o puede un programador ocuparse de ello si tiene mucha experiencia en planificación ágil? (Quora) 

Tras estas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Quien hace esas preguntas conjeturan con la posibilidad de ahorrar dinero juntando dos roles en una sola persona.

Las preguntas son realizadas por novatos como Scrum Masters, por product owners, por miembros del equipo, por managers, por stakeholders de cualquier tipo. De los tres roles en Scrum, todos parecen inferir inmediatamente que ser miembro del equipo es un trabajo a tiempo completo -por que desarrollan software el día completo - y que ser un product owner es también a tiempo completo - por que desarrolla el producto todo el día-, pero parece difícil de imaginar cual es el trabajo de un Scrum Master pueda ser y el por qué diablos sería un trabajo a tiempo completo, también.

¿Quizás esos que preguntan no sepan que es lo que un scrum master hace todo el día?

Aquí presento una lista de 42 cosas que diría que son parte del trabajo de un scrum master:

Reuniones
- Facilitar reuniones para el equipo. Esto incluye:
   - Preparar
   - Moderar
   - Postprocesar
 - Realizar retrospectivas, que son especiales, por consiguiente las cuento separádamente.

Dinámicas de equipo
 - Realizar coaching a los miembros del equipo (p. ej. coaching 1a1)
 - Mediar en los conflictos
 - Ayudar al equipo en la toma de decisiones
 - Fomentar la auto-organización del equipo
 - Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el product owner (más funcionalidad)

Aprendizaje
 - Continuar aprendiendo todo lo relativo a Agile (p. ej. visitar grupos de comunidades, atender a conferencias, leer libros, escribir blogs,…)
 - Asesorar a los miembros del equipo en todo lo relacionado con Agile.
 - Ayudar al equipo a crear radiadores de información.
 - Dar feedback al equipo.
 - Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme trabajo para invertir el tiempo de un Scrum Master, incluyendo por ejemplo, publicación/releases automáticas, entrega continua, TDD, y muchos más).
 - Desafiar al equipo con nuevas ideas sobre Agile Management (p. ej. FedEx -Days).
 - Colaborar constantemente con otros Scrum Master en la organización (p. ej. a través de la comunidad de práctica).
 - Bajar al Gemba.

Producto
 - Ayudar a escribir o dividir historias de usuario.
 - Ayudar a escribir o adaptar la visión del producto.
 - Ayudar a ordenar los elementos de la pila de producto.
 - Ayudar con la planificación del sprint.
 - Estar familiarizado con el trabajo del equipo (p. ej. el producto)

Visión general
 - Juntar a la gente que debería hablarse entre ellos.
 - Estar en contacto con los stakeholders regularmente.
 - Ayudar al equipo a informar a management.
 - Ayudar a fortalecer la comunidad ágil dentro de la organización
 - Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, stakeholders y el resto de la organización
 - Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas,…)
 - Ser la persona de contacto para todos en el equipo y los stakeholders en todo lo concerniente a Agile. 
 - Dar oportunidades de aprendizaje a la gente en la organización (p.ej. charlas o talleres) y permitirles aprender conceptos Agile importantes como p.ej. la deuda técnica.

Cambio
 - Ayudar al equipo a eliminar impedimentos.
 - Sugerir nuevas métricas para el equipo como catalizadores del cambio

Espejo
 - Reflejar los valores ágiles y de scrum al equipo.
 - Recordar al equipo sus acuerdos (p.ej. políticas)
 - Ayudar al equipo a mejorar constantemente sus procesos.
 - Reflejar los problemas al equipo a través de la observación desde fuera.
 - Hacer preguntas abiertas.
 - Comprobar los modelos que usa el equipo (p.ej. sprint backlogs, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.

Varios
 - Ayudar al equipo a mantener el foco (p.ej. actuando como un buffer entre las distracciones externas y el equipo)
 - Ayudar al equipo a mantener sus herramientas scrum (paneles, pilas de acciones, gráficas, backlogs,…)
 - Ayudar al equip y el product owner para encontrar los adecuados:
    - Definición de terminado (DoD).
    - Definición de preparado (DoR).

¿Has hecho o considerado todo lo mencionado anteriormente? Tomate un respiro, ¡debes estar agotado!

     Creemos que el scrum master es un rol a tiempo completo para una persona en un equipo Scrum. Scrum Master Manifesto.


2 comentarios:

  1. Gracias Joserra! Sí, las dudas son recurrentes :-)

    Las dinámicas de trabajo que cuida y desarrolla un buen Scrum Master son a menudo "sutiles". Pasan como desapercibidas para la mayoría de personas; otras sí se enteran, pero no saben cómo intervenir positivamente.
    Cómo estos asuntos ni se enseñan ni se ven, es normal chocarnos con resistencias de todo tipo y planteamientos como: << el Scrum Master a picar código ya!! Hombre... >>.

    Creo que el post ayuda a que abramos los ojos sobre unas tareas muy muy necesarias, que de cuidarse bien marcarán una diferencia brutal en toda organización.

    ResponderEliminar
  2. Este comentario ha sido eliminado por un administrador del blog.

    ResponderEliminar