¿Quieres saber si haces Scrum? ¡mira tu Review!

Hace unos semanas terminé el libro “Por un Scrum Popular” de Tobias Mayer. El libro, para quien no lo haya leído, nos narra reflexiones del autor sobre diferentes partes de Scrum. En uno de los capítulos comentaba Tobias que para él lo más importante era el tablero físico, por otro lado el co-autor le daba más importancia a la retrospectiva, porque para él es donde reside la mejora continua. Los que me conocen sabrán que me emocioné al leer la afirmación de Tobías en cuanto al tablero físico.

Esto me hizo plantearme una pregunta ¿Qué parte de Scrum es la más relevante? ¿Qué elemento de Scrum nos dice si un equipo realmente sabe hacerlo? Durante mi experiencia como Agile Coach tuve la oportunidad de acompañar a muchos equipos y ver cómo maduraban en Scrum y Agile.

Cómo espectador que era, iba viendo cómo cada equipo implantaba Scrum en diferentes clientes y cómo iban madurando. Dentro del framework tenemos roles, artefactos y eventos. En total 11 elementos, a los que podríamos sumar otros como el Definition of Done, el tablero físico o el planning poker. ¿Cuál de ellos nos dice la madurez de un equipo?

La evolución de los eventos

Después de mucho pensarlo he visto más o menos la siguiente evolución:

• La Sprint Planning es un gran ejercicio de madurez, desde equipos que solo estiman con un Scrum Master que fuerza a ello, hasta equipos que se autoorganizan de verdad y a veces ni necesitan estimar.
• La Daily Scrum evoluciona desde el puro reporte hasta un ejercicio de coordinación real y focalizando los impedimentos y como afectan al Sprint Goal. 
• La Retrospectiva cambia cuando solo sacamos problemas hasta cuando realmente nos responsabilizamos de los mismos y la mejora contínua no para de aparecer.
• ¿Y la Sprint Review? Para muchos equipos es la “demo” que el Development Team realiza al Product Owner para que vea cómo está su producto.

En este post me gustaría que nos centráramos sobre el evento de la Sprint Review.  Os pongo un ejemplo: imaginad que el presidente de McLaren va a buscar al Product Owner del coche de Fernando Alonso y le pregunta ¿Qué evoluciones vamos a tener para el próximo gran premio?, la respuesta en un equipo Scrum poco maduro sería “Uff no lo se, en 2 semanas me hacen una demo y me enseñan lo que les ha dado tiempo”.

¿Cómo? Tengo una persona responsable de un coche que no sabe cómo está su coche ¿Qué responsable es este? ¿De qué me sirve que sepa mucho de coches si no sabe del coche para el que es responsable? 

Aquí reside la gracia de la Sprint Review, el primer cambio que un equipo debe entender es que, es un evento donde el Product Owner junto con el resto del equipo le cuentan al mundo cómo está el producto.

Subiendo de nivel

Perfecto, ya hemos pasado de nivel. El problema viene porque hemos cambiado el foco pero no el motivo del evento. En el siguiente nivel no reporta el Dev Team pero reporta el Product Owner, ¡Pero la Sprint Review no es de reporte!

Si superamos este nivel, nos encontraremos en el nivel donde, además de ver el estado del producto, analizamos el futuro del mismo. En este caso, una idea es ver el Product Backlog o, mejor aún, utilizar alguna técnica como el Plan de Releases. Lo malo de este nivel es que se interpreten como fechas de entregas cerradas, en ese caso no estaremos ante algo muy divertido.

El siguiente nivel ya requiere mucha más madurez. En este estado hablamos además de los números del producto, fechas posibles de entrega, coste acumulado entre otros. Esto requiere mucha transparencia y coraje, las bases de un equipo Scrum maduro. 

La Sprint Review ideal

Por último, y aquí está la clave, el nivel más alto que pocas veces se ve. En el estado de mayor madurez un equipo Scrum lo que hace es analizar el mercado para saber cómo está funcionando su producto. ¿Un estudio de mercado? Exacto. Jeff Sutherland lo explicaba muy bien, el motivo de la Sprint Review es hacerse estas preguntas:

• ¿Alguien quiere nuestro producto?
• ¿Pagarían por él?
• ¿Resuelve este incremento parte del problema que queríamos resolver?

Estas preguntas son esenciales porque nos aportan información para tomar decisiones y llevar nuestro software al éxito.  

Nivel de evolución	Hecho relevante.
Nivel 0	No hay Sprint Review
Nivel 1	Presenta el Development Team al Product Owner
Nivel 2	Presenta el PO pero sigue siendo un reporte al Sponsor u otros.
Nivel 3	Vemos el futuro del Product Backlog
Nivel 4	Hablamos de números, somos transparentes.
Nivel 5	Analizamos el mercado y tomamos decisiones.

Hasta este punto quería llegar, los equipos más maduros en Scrum son aquellos que la Sprint Review es un ejercicio real que busca contrastar el incremento que hemos generado contra el mercado. Así podremos inspeccionar y adaptar nuestro producto para tener opciones de éxito. 

¿Cómo hacemos esto?

Para empezar, teniendo claro varias cosas que no solemos trabajar en muchos equipos. ¿Para qué estamos aquí? La respuesta a esta pregunta nos la debería de dar el Product Owner a través de la visión del producto.

Una vez definida nuestra visión, lo siguiente es tener KPIs, métricas… de valor que aterricen esa visión en algo tangible. ¿Quiero más usuarios? ¿Aumentar mi tasa de conversión? ¿Más ingresos? ¿Número de visitas?… Lo que estés buscando debes medirlo para saber si realmente estás generando valor.

La Sprint Review será el momento para analizar esos indicadores, y que el Product Owner explique su estrategia. No estará solo, tanto el Dev Team, el Scrum Master como los Stakeholders le podrán ayudar a tomar decisiones. Recordemos que la Transparencia es un pilar de Scrum y analizar esta información con más opiniones es la clave del éxito.

Muchas personas con las que hablo estos temas siempre me dicen lo mismo “nunca he visto un equipo analizar el mercado”. Bueno, debo decir que yo los he visto, son pocos, pero existen. Y, será casualidad, son los que más éxito tienen. Llegar a ese grado de madurez te da una ventaja competitiva con respecto a los demás.

Como conclusión, si quieres saber si un equipo realmente hace Scrum, mira la Sprint Review. Mira que es lo que hacen, quizás no analizan mercado porque la organización que está detrás no le interesa.

¿Qué futuro le espera a esa organización que prefiere medir productividad de sus empleados a medir el éxito de los productos que realizan sus empleados?