Scrum Master II

El rol de Scrum Master requiere de amplias habilidades sociales, ya que su foco está puesto en las personas del equipo y sus relaciones. Es muy común que tengan conocimientos y experiencia en coaching y/o psicología. También es común que se trate de perfiles con conocimientos técnicos, aunque esto último no es un requerimiento per se. Además, también ejerce de evangelizador de las metodologías ágiles dentro de la organización.

¿Cuáles son sus responsabilidades?

Es el responsable de que el Scrum sea entendido y bien aplicado dentro de la organización. Trabaja junto con el Product Owner y el equipo de desarrollo en la creación de valor en cada sprint.

Elimina impedimentos y ayuda a ser más productivo al Equipo de desarrollo.

¿Cuáles son sus funciones?

Entre otras, un Scrum Master debe:

• Planificar la implantación de Scrum junto con la organización.

• Ayudar a la organización a entender que interacciones con el equipo aportan valor y cuales no.

• Asistir al Product Owner a saber cómo organizar el product backlog y maximizar el valor.

• Asegurarse de que haya una definición de done.

• Comprender y practicar la agilidad.

• Ayudar al equipo a crear productos de valor.

• Eliminar cualquier impedimento del equipo.

• Facilitar los eventos Scrum.

• Trabajar con otros Scrum Masters para aumentar la efectividad de Scrum en la organización.

• Junto con el equipo Scrum, actualizar el burndown chart.

¿Es el Scrum Master un Project Manager?

El Scrum Master es un líder al servicio del equipo Scrum. En Scrum no existen los project managers, sin embargo ejerce como el manager de Scrum, por la razón de que enseña y evangeliza Scrum dentro de la organización.

Claves para ser un buen Scrum Master

• Liderar con el ejemplo.

• Promover el debate y apoyarlo.

• Ser paciente y tolerante.

• Dejar que el equipo actúe.

Los errores más comunes del Scrum Master

En ocasiones se cometen fallos en el momento de empezar como Scrum Masters, es por ello, que revisaremos algunos puntos que consideramos incorrectos para que los Scrum Masters puedan desarrollar un mejor trabajo en su día a día.

1. No debe organizar el trabajo del Equipo de Desarrollo, existen muchos Scrum Masters que, según su experiencia pasada, le dicen al Product Owner y al Equipo de Desarrollo las historias de usuario que pueden realizar en un Sprint, calculando su capacidad, y creando un mal clima de trabajo.

2. Nunca debe organizar los eventos de un Sprint. En muchas casos, en los Daily meetings, el Scrum Master se encarga de hacer las tres preguntas. Además de controlar el trabajo de un desarrollador, que se había comprometido con una historia de usuario el día anterior. El Scrum Master debe asegurarse que los eventos se realizan, y que se realizan dentro de los tiempos establecidos.

3. No debe categorizar a los miembros del equipo de desarrollo en roles, no debe asignar “Programadores” o “Testers”, esto es trabajo interno del mismo equipo, que debe ser multidisciplinar.

4. No debe proteger al equipo, aislandolo de reuniones importantes como el refinamiento del Product Backlog, por estar con mucha carga de trabajo. Esto suele terminar en un refinamiento hecho solo por el Product Owner y el Scrum Master. El objetivo de estos eventos es que participen todos los miembros del equipo Scrum.

5. No debe obligar a esperar al Sprint Review para la inspección del incremento de producto. Ni tampoco obligar al equipo de desarrollo a no mostrar nada de lo desarrollado en medio de un Sprint. Su trabajo es encargarse de que esta labor de inspección no se convierta en un día a día.

6. No divide los Sprints en “Sprints de incremento” y “Sprints de testing”. Tampoco trabaja con “Sprints cero” para la creación de la infraestructura de código.

7. No debe cambiar por si mismo Scrum por “Agilidad”, tampoco eliminar eventos que considere innecesarios por falta de tiempo.

8. No debe obligar a que el Product Owner sea el exclusivo responsable de crear las historias de usuario del Product Backlog, así como de que sea el Product Owner el único que de los detalles de cada historia de usuario. El Product Backlog es responsabilidad del Product Owner pero su organización puede ser realizada de manera colaborativa si así se considera necesario. Este tipo de acciones aísla la presión a una sola persona, creando un mal clima de trabajo.