¿Qué hace un ScrumMaster durante el día?

Para ver que hace un ScrumMaster durante un día de trabajo, citemos una definición de ScrumMaster:

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules.

Muy concisa… pero ¿Qué hace realmente un ScrumMaster durante el día? Déjenme enumerar específicamente las (principales) tareas que realiza durante la jornada laboral:

1. Asegurar que los valores y las prácticas de Scrum se respeten y se cumplan.
2. Quitar impedimentos al equipo. Conseguir o perseguir a quien sea para que cualquier problema sea resuelto cuanto antes y el equipo pueda trabajar sin nada que los frene. Lograr que el equipo sea híper productivo. Lograr el éxito en el proyecto.
3. Asegurarse de que las reuniones diarias ocurran, que haya una sala reservada (física o virtual para tele o video conferencias), y que todos los miembros del equipo vayan, como un pastor que guía a sus ovejas (Estimo que mi analogía pueda herir la susceptibilidad de cierta gente, pero es cierta).
4. Prestar atención en las reuniones diarias. Seguir los temas abiertos en ellas. Asegurarse que las conversaciones sigan fuera de esta reunión.
5. Moderar las reuniones diarias para que no sean innecesariamente largas.
6. Asegurarse que el product backlog este priorizado (Push al product owner)  y estimado (asegurando que los poker plannings se hagan).
7. Asegurarse que el sprint backlog este actualizado, que el remaining time de las tareas se cargue diariamente y estos cambios se puedan observar en el burndown
8. Asegurarse que el Sprint planning se haga, que las user stories sean separadas en tareas estimadas por las personas que las vayan a hacer, y que queden asignadas a ellos.
9. Proteger al equipo cuando se pide mucho de ellos, que no se comprometan a más de lo que puedan hacer, y también que no se vuelvan complacientes. Esto es más difícil, ya que si el equipo no quiere dar lo mejor y apunta a menos, hay problemas graves de motivación que tienen que solucionarse.
10. Asegurarse que los analistas funcionales trabajen en el acceptance criteria de las historias del product backlog de mayor prioridad junto al product owner (Grooming)
11. Asegurarse que se hagan las Demos, que el equipo se prepare para ellas y que alguien (no siempre la misma persona) muestre las nuevas funcionalidades de la aplicación.
12. Preparar la presentación con las métricas del sprint para presentar en el sprint review, antes o después de la demo.
13. Asegurarse de que se hagan las retrospectives, y que los tres puntos más importantes levantados por el equipo se resuelvan o se intenten resolver durante el siguiente sprint. Detectar otras oportunidades de mejora.
14. Asegurarse de que se hagan las release planning meetings, para organizar el product backlog en releases. Con la métrica de la velocidad se debe saber cuándo se va a terminar todo el product backlog que uno tiene estimado. Trabajar junto a los stakeholders del cliente para seguir de cerca el plan a largo plazo del proyecto.
15. Asegurarse que el equipo complete el done criteria. No dejar que se cierren tareas (Se sumen story points) hasta que algo no este desarrollado, testeado, aprobado por el cliente, o lo que diga el done criteria que se haya especificado.
16. Facilitar la comunicación del equipo con el product owner.
17. En algunos casos, liderar sin autoridad formal, sin títulos. El ScrumMaster es un servidor y líder a la vez.
18. Tener reuniones 1:1 con todos los miembros del equipo. Hacer seguimiento de cada miembro del equipo. Escuchar a la gente. Asegurarse de que el equipo este bien.
19. Asegurarse que todos sepan usar la herramienta de administración del proyecto que se use, entrenar al equipo.
20. Proteger al equipo de influencias externas. Ser el punto de contacto principal para cualquier persona externa  al equipo. Encargarse de las tareas burocráticas.
21. Comunicarse e informar el estado del proyecto y del equipo a sus superiores dentro de la empresa.
22. Organizar eventos cuando se llega a hitos importantes.
23. Comprar comida al equipo cuando se trabaja hasta tarde. Asegurarse de que tengan café.

Seguro que hay más que no tuve en cuenta, pero espero que este artículo les dé un pantallazo general de las tareas de un ScrumMaster.

Planificando en Scrum

Uno de los temas que muchos comentan pero del que realmente pocos se ocupan es de planificar en Scrum. En vez de hablar de ese tema hay que ponerse a trabajar y armar un plan, lo suficientemente bueno como para poder llegar a satisfacer al cliente. Sin embargo el objetivo de Scrum no es tener un plan, es entregar features completos de un producto. Un plan nos ayuda a manejarnos en el corto y largo plazo.

En Scrum hay muchas oportunidades para planificar, ejecutar y entregar software. La razón para usar Scrum es simple: la necesidad de entregar algo de valor para el cliente, reduciendo riesgo, entregando periódicamente, inspeccionando y adaptándonos a las necesidades.

Se puede hacer planificación a largo plazo en el Product backlog mediante Release planning. Se puede hacer planificación a corto plazo a nivel de Sprint backlog mediante Sprint planning. Finalmente se puede hacer planificación diaria y ajustes mínimos en el Daily Scrum. Y el progreso de todo esto se puede seguir en diferentes Burndown charts.

¿Que quiere el cliente realmente? Quiere que le entreguemos software que funcione, que haya cumplido con el criterio establecido para determinar que lo que entregamos este realmente completo. Pero también es necesario planificar en Scrum. 

¿Le importa al cliente el plan? No si uno falla con los compromisos de fechas que se asumen. En ese momento el plan se convierte en un problema que atenta contra la confianza entre el equipo, el cliente y todos los interesados. Project Managers tradicionales luego utilizan el plan para atacar a miembros del equipo por no cumplir con las fechas.

Hay que detener ese ciclo, hay que planificar lo suficiente. Esta es una de las conversaciones difíciles que hay que tener con el cliente y tus superiores. No es fácil.

¿Quien es responsable de entregar software que funcione en un equipo Scrum? El equipo. Como ScrumMaster uno es responsable de facilitar el framework de Scrum, asegurar que el equipo comprenda los roles, que se hagan las ceremonias establecidas, trabajar con el product owner y el resto de los interesados, entre otras cosas. Pero en la realidad, en las empresas, un ScrumMaster es el Project Manager y es el máximo responsable.

¿Cómo podemos asegurarnos el éxito? Entregando software y cumpliendo con    los compromisos. Las conversaciones con el cliente y todos los interesados se convierten en algo increíble cuando esto pasa, créanme.

Al principio va a ser difícil. Scrum no es una bala de plata, entregando software se construye y fortalece la confianza entre las partes. Hay una estadística que nos dice que hay que un equipo tiene que trabajar junto varios Sprints para que sus estimaciones sean productivos. El primer plan del Sprint no se va a cumplir. El primer Release plan que se prepare va a estar muy lejos de la realidad. Hay que aclarar esto al principio, manejar las expectativas correctamente. También hay que revisar nuestras estimaciones iniciales al hacer el segundo Release plan, y el tercero, hasta lograr un plan a largo plazo que nos sirva a todos.

Se puede. Inténtenlo.