Algo curioso que ocurre en muchos de mis clientes es que me preguntan: ¿Por qué no funciona Scrum? o ¿Cómo podemos mejorar la calidad con Scrum? y cosas similares. Mi respuesta es comúnmente la misma: ¿Cómo haces Scrum?
El Sprint Review es un caso paradigmático. En Scrum, es la reunión de negocio por excelencia. La mecánica es muy sencilla: El Equipo Scrum muestra el incremento para ser inspeccionado y adaptado, explican cuales han sido los problemas que han tenido y cómo los han resuelto; después los stakeholders discuten con el PO y el Equipo de desarrollo cuales son las condiciones actuales de negocio y actualizan el Product Backlog. Está todo mucho mejor explicado en esta receta para conseguir un buen Sprint Review.
Y entonces empiezan los problemas. El Product Owner no puede estar en el Review. ¿Stakeholders? No me hagas reír. Nadie sabe las condiciones actuales del negocio. El equipo de desarrollo no ha completado un incremento de Software. No hay Product Backlog. Pero la culpa la tiene Scrum.
Es muy curioso que con todas esas vías abiertas en la capacidad competitiva de la empresa y de dar servicio a sus clientes, le echen la culpa a Scrum. Como si el capitán del Costa Concordia hubiera dicho que la culpa es del mar. No hay nada que pudiéramos haber hecho.
Si quieres hacer un buen Sprint Review, ya sabes:
- Al principio del Sprint había un Sprint Goal contra el que trabajar.
- Asegurate de que el equipo Scrum ha trabajado en tener un incremento terminado
- Los stakeholders están invitados y asisten al Sprint Review
- Hay una conversación acerca de qué ha ido bien y mal durante el Sprint.
- Se actualiza el Product Backlog y se explican las siguientes prioridades acorde con las condiciones de negocio
Por supuesto, si eres Scrum Master y te enfrentas a una de las situaciones descritas arriba, puede que pienses: “Pero esto es imposible, yo no puedo cambiar la organización”. Entonces ve buscando otro trabajo porque no vas a durar mucho en la industria. Cuando hablamos de eliminar impedimentos, hablamos de ayudar a mejorar y cambiar a la organización, no de arreglar teclados y organizar reuniones.
La diferencia entre un Scrum Master experimentado y uno que no tenga experiencia es la capacidad de influenciar a la organización sin el poder para ello. Esa es la característica que hace a un Scrum Master ser excelente.
