Anti-patrones de la Sprint Review I

Como sabéis hace poco tuve la suerte de poder dar una charla sobre anti-patrones Scrum.

Una de las muchas cosas buenas que tiene preparar una charla de este tipo es que implica una labor de investigación e introspección y como en 45 minutos no se puede contar todo, he decidido escribir una serie de post dedicados a exponer más información relacionada con el meetup, en este caso hablaré de los anti-patrones de la Sprint Review.

Fuente: Harry Potter casts the Patronus curse

Anti-patrones de la Sprint Review

Review como sesión de aprobación

Uno de los anti-patrones que comenté en mi charla, es el que se da cuando el Product Owner utiliza la Review para revisar y aceptar los items «terminados» en el Sprint.

Esto debe ser desacoplado de la Review. El Product Owner debe aceptar los items en el momento en que cumplan con el DoD y los criterios de aceptación, promoviendo de esta manera el feedback temprano.

Inaccesibilidad del Product Owner

En este caso el PO no acepta comentarios de los stakeholders.

Esta forma de actuar incumple el propósito principal del evento cuyo objetivo entre otros es recibir el feedback de los stakeholders y promover una conversación con ellos.

Muerte por PowerPoint

Se produce cuando realizamos la Review basándonos y centrándonos en una presentación powerpoint que hace que los asistentes se aburran y pierdan el foco.

La base de una Review es «mostrar, no contar» o incluso mejor, dejar que los stakeholders sean quienes facilitan el evento invitándoles a interactuar con las funcionalidades.

Las mismas caras de siempre

Surge cuando siempre son los mismos representantes del Equipo de Desarrollo quienes participan.

A menos que la organización trabaje con varios Equipos Scrum (como pueda ser con LeSS o Nexus), esto no es una buena señal y habrá que fomentar que los participantes roten entre sí.

Conciertos paralelos

Se produce porque el Equipo de Desarrollo trabaja en tareas fuera del alcance y/o objetivo del Sprint, y el Product Owner sabe de ellos por primera vez durante la Review.

Esto rompe con uno de los 3 pilares de Scrum, el de la transparencia.

La trampa

Sucede cuando el Equipo de Desarrollo muestra elementos que todavía tienen errores, en este caso puedes ver más detalle revisando el post Mentiras arriesgadas: Incremento terminado.

Siguiendo un plan

Tiene lugar cuando el Equipo (Scrum) no usa la Review para discutir el estado actual del producto o proyecto con los stakeholders.

Como hemos comentado, obtener retroalimentación es el propósito del ejercicio. Una actitud de «sabemos lo que tenemos que construir«, implicará la rotura de otro de los pilares, el de la adaptación.

Leave a reply:

Your email address will not be published.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.