De acuerdo a la visión general de Scrum descrita en la Guía, Scrum es simple, pero a la vez difícil de dominar y comprender, esto lleva a que a veces surjan malas interpretaciones o distorsiones del Framework, y aunque generalmente sean distorsiones involuntarias, nuestra labor como Scrum Master es justamente estar atentos ante estas situaciones, y tratar de enseñar y corregir, ya que lo único que fomentarían es desarrollar un “Scrum Flácido”, obstaculizando la entrega continua de valor basada en el empirismo sobre la inspección y adaptación que busca Scrum. Dicho esto, y sólo por poner un ejemplo, quisiera compartir con ustedes lo que personalmente he presenciado en algunas reuniones de Sprint Review, identificando algunos antipatrones como las que detallo a continuación:
El Scrum Master lidera la reunión.
A veces he notado esto, y personalmente no sé si es por algún mal entendido, o quizás por un tema de ego. Sea cual fuere, está claro que este Scrum Master no entiende cual es su rol, y como consecuencia, se podría decir que tampoco entiende Scrum. De hecho yo siempre digo que para temas propios del producto:
Un Scrum Master no dice qué hacer (respecto al producto), ni tampoco lo va a hacer.
Respecto al producto, el “qué” es del Product Owner y el “cómo” es del Equipo de Desarrollo, por lo tanto, el rol del Scrum Master respecto al Sprint Review, es haber previamente enseñado a los demás miembros del Equipo Scrum, a que entiendan el propósito de la reunión, y evidentemente asegurarse que se lleve a cabo en el timebox adecuado, y hacer de esta, una reunión de colaboración y feedback donde el Product Owner junto con el Equipo de Desarrollo, tengan el protagonismo promoviendo la inspección del producto terminado hacia los Stakeholders, para eventualmente adaptar el Product Backlog de ser necesario.
Un miembro del Equipo de Desarrollo (usualmente alguien que realiza actividades de QA) es quien realiza y lidera la reunión.
Cuando he preguntado del por qué de esta situación, generalmente he recibido respuestas como: “…es que es la persona que conoce todos los flujos de pruebas”, “… es la persona que ha probado y ha validado todos los cambios”. Entonces yo me pregunto: ¿los demás miembros del equipo de desarrollo no conocen los flujos?, ¿no han realizado como equipo pruebas de forma integral?, ¿el Product Owner no sabe nada?. Para empezar, en el Equipo de Desarrollo no debe de haber “etiquetas” como “QA”, ya que todos son parte de un equipo multidisciplinario orientado a construir incrementos de producto hacia el objetivo de cada Sprint, asimismo, en esta situación se puede decir que no hay una comprensión adecuada de los roles (incluyendo al mismo Scrum Master), ya que prácticas como esta, lo único que fomentan es alejar a todos de los Valores de Scrum. Por lo tanto, si bien podría entenderse esta situación en un equipo en formación y en circunstancias muy particulares, y aunque es válido que un miembro del Equipo de Desarrollo conozca mucho de los flujos de pruebas, es compromiso de los demás también conocerlos, esta persona debería tener el coraje de enseñar gradualmente a los demás, para ayudar a todos a mantener el foco y compromiso. El Product Owner debe tener el coraje de idealmente conducir la reunión sobre lo que el equipo logró o no, y tener la apertura de verse ayudado por los miembros del equipo. El Scrum Master justamente es el indicado en promover esta comprensión y colaboración fomentando el accountability en los roles sobre un entorno de apertura y respeto en cada Sprint de forma gradual.
El Equipo de Desarrollo junto con el Scrum Master realizan la presentación del incremento de Producto hacia el Product Owner.
Definitivamente esto no es Scrum, ya que aquí se nota además de una falta de comprensión de los roles de Scrum y del propósito del Sprint Review, que hay cero involucramiento del Product Owner. El Sprint Review es una reunión donde se espera la colaboración entre el Equipo Scrum y los Stakeholders, para esto, el Scrum Master debe explicar tanto a los otros miembros del Equipo Scrum como a los Stakeholders, cual es el propósito de la reunión, el Product Owner tiene que explicar a los stakeholders qué Product Backlog Items se lograron hacia su objetivo de Sprint, y el Equipo de Desarrollo debe presentar a los Stakeholders el trabajo terminado y estar atento ante cualquier consulta. El propósito de esta colaboración es que los Stakeholders provean feedback al Equipo Scrum sobre el trabajo terminado, y se discuta en conjunto y de forma transparente, los próximos pasos que potencialmente se realizarían en el siguiente Sprint.
Sólo se muestran diapositivas e imágenes de cómo será el producto.
El primer principio ágil nos dice:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor
Dicho esto, si un equipo “ágil” en un Sprint Review no hacen que los stakeholders inspeccionen el Incremento de Producto terminado, no estarían siendo ágiles. Con un slide o imagen no puedes hacer inspección de producto porque evidentemente no tienes ningún producto, se tiene que mostrar software funcionando, y por ejemplo, entregarle a los stakeholders celulares para que revisen la App, indicarles la URL si tiene que revisar una web, acercarlos a un ATM para que vean la nueva funcionalidad, etc., por lo tanto, si el equipo sólo muestra diapositivas, se debería quitar esta práctica idealmente de forma inmediata, y si por algún motivo el Equipo de Desarrollo no llegó a alcanzar el objetivo del Sprint, ellos deberían simplemente decirlo (rescatando el pilar de Transparencia), y en la Retrospectiva evaluar las razones y tomar acciones correctivas para evitar la misma situación en el siguiente Sprint.
El Product Owner recién ve el resultado del Sprint en el Sprint Review
Los pilares de Scrum son la Inspección, Adaptación y Transparencia, por lo que hacer que el Product Owner recién vea el incremento de producto terminado recién al final del Sprint, es un síntoma de además de ausencia de colaboración, de que se está haciendo “mini cascada” y no Scrum. El equipo de desarrollo requiere feedback de su trabajo, y para eso necesita colaborar continuamente con el Product Owner, una forma de hacerlo es a través de la entrega continua de Product Backlog Items al Product Owner que cumplan la Definición de “Terminado”, para que este pueda validar que sus criterios de aceptación han sido satisfechos, de esta manera, el Equipo de Desarrollo obtiene feedback valioso para adaptar su trabajo de ser necesario.
En mi experiencia como Scrum Master, algunas veces me he visto principalmente con lo que acabo de comentar, pero como conclusión final diría que no hay recetas de cómo hacer el Sprint Review, no obstante, el Equipo Scrum debe ponerse de acuerdo de cómo realizar ésta y otras reuniones, realizando sus propios “working agreements” siempre con el accountability de cada rol, considerando las “reglas del juego” de Scrum y sobre la base de los Valores de Scrum. Y tú, ¿qué otros antipatrones has visto?, ¿estas de acuerdo con las que he comentado?. Si puedes, comparte tu opinión, todo comentario o feedback es bienvenido y de beneficio para todos.
Jaime Julio Avalos Ocaña
MBA Candidate | Scrum Master | Founder AGILITYLAB | PSM II, PSPO II, PAL-EBM, SPS, PSK, PAL, PSD, PSU, PSFS
