Un Product Owner que ejercía por primera vez y para complicar más las cosas tres Scrum Master en dos meses no hacían presagiar nada bueno. Pero si hecho la vista atrás puedo afirmar que las cosas terminaron saliendo bien. Por el camino todos aprendimos cosas, obviamente no todo fue perfecto aun así puedo considerar que fue un verdadero caso de éxito. ¿Qué es lo que en mi opinión hizo que esto fuera posible?
Indice de contenidos
Entrega de valor desde el primer Sprint
En muchas ocasiones he visto que el primer Sprint se usa para poner los cimientos de la arquitectura de la solución. En otras ocasiones el esfuerzo se centra en el primer paso de un proceso, que suele ser el loguin, que aporta poco valor. Esto hace que el primer Sprint no tenga un valor real, lo que se suele traducir en excusas para no hacer un Sprint Review. Al fin y al cabo no hay nada que enseñar.
En este caso, con un Development Team de tres personas, conseguiremos crear una primera pantalla que mostraba algo que daba valor a nuestros Stakeholders. El Development Team se esforzó en construir lo mínimo necesario para poder mostrar algo funcionando. Es cierto que parte del trabajo hubo que rehacerlo, pero a cambio desde el minuto cero tanto el Product Owner como los Stakeholder pudieron dar feedback que ayudo a mejorar la solución planteada.
Ordenación real del Product Backlog
En muchas ocasiones los Product Owneres suelen ver el producto como un total y no ven valor de ir ordenando el Product Backlog. Esto suelo pasar por que tienen una visión completa del producto y no conciben poner partes en producción. Para ayudarles a reflexionar esto suelo hacerles la pregunta. Si mañana tuvieras que presentar el avance en una feria o al director de la compañía ¿Qué te gustaría enseñarle?. Aunque no lo creáis estas cosas pasan, en este caso el Product Owner entendió perfectamente su labor y prácticamente desde el primer minuto hizo suyo el Product Backlog y entendió que había cosas que tal vez no se iban a realizar. Por ese motivo siempre priorizó lo que a él le daba más valor.
Por otro lado el Product Owner se esforzó por escuchar a todos los Stakeholders lo que hizo que el producto fuera ganando funcionalidad valiosa para los mismos.
Fe en el marco de trabajo
Ciertamente hubo momentos de crisis. En muchos de ellos el equipo recibió presiones por parte de la organización para hacer cosas que no encajaban dentro de la folosofía Scrum. En todas esas ocasiones el equipo se mantuvo firme y reafirmó que Scrum les estaba ayudando a realizar mejor su trabajo.
Obviamente esto no era cuestión de fe. Todos se estaban dando cuenta que esta forma de trabajar era mejor que la forma tradicional que tenían y que gracias a ella su proyecto iba a ser un verdadero caso de éxito dentro de la organización.
Verdaderas Sprint Reviews
No puedo decir más que las Sprint Reviews eran de libro. El Product Owner tenía claro a quién invitar en cada Sprint Review para que le aportase valor. El Development Team mostraba de una forma fluida el incremento con casos prácticos que ilustran el funcionamiento de la aplicación. Además los stakeholders desde el primer minuto empezaron a dar sugerencias sobre mejoras que les aportarían más valor, esto tiene mucho que ver con tener algo que mostrar desde el primer Sprint.
Esto no se consiguió de casualidad, detrás de estas Sprint Reviews había un trabajo previo en donde todo el equipo se alineaba con el mensaje y donde se limaban posibles discrepancias sobre alguno de los puntos. De esta forma el Product Owner contaba lo que el Development Team luego mostraba y todos hacían hincapié en las mismas dificultades que se estaban encontrando.
Todos entendían el valor de este evento y en muchas ocasiones el Development Team tuvo que hacer verdaderos esfuerzos por poder enseñar el incremento en la Sprint Review. Cuando las infraestructuras fallaban fueron capaces de buscar soluciones que permitieran mostrar los conseguido.
Un de las cosas que nos funcionó muy bien fue reunirnos media hora antes de la Sprint Review. Al ser un equipo deslocalizado todo se hacía en remoto, y esta media hora nos permite asegurarnos de que todas las comunicaciones iban a funcionar perfectamente. De esta forma conseguimos mantener la atención de los Stakeholders en todo momento.
Conclusión
Muchas veces detallamos las cosas que se han hecho mal durante un proyecto. En esta ocasión quería resaltar un caso de éxito. Obviamente hubo momentos mejores y peores pero cuando echo la vista atrás y veo el resultado obtenido no puedo más que estar orgulloso de todo el equipo y el resultado obtenido.
Creado por mi amigo Jose Manuel Gomez Fraile
