Mentiras arriesgadas: Incremento terminado.

Seguramente os estéis preguntando qué tendrá que ver una película de Schwarzenegger con el Incremento de Scrum.

Para poneros un poco en contexto, debo haceros un brevísimo resumen de la trama principal de esta película. Si no quieres un spoiler, podéis dejar de leer aquí.

En Mentiras Arriesgadas Helen (Jamie Lee Curtis) piensa que su marido Harry (Arnold Schwarzenegger) está siéndola infiel, y decide investigar qué es lo que está sucediendo y destapar el engaño de Harry. Cuando Helen se dispone a desenmascarar a su marido, descubre que este es un espía, y se ve envuelta en toda una aventura. Pues eso mismo es lo que nos pasa con el Incremento en Scrum en muchas ocasiones.

El Incremento “terminado”

BurnDown Chart increment
Fuente: view26.com

Hablemos de “Mentiras Arriesgadas”, y de cómo el Incremento “terminado” es en algunos casos, el cuento de “El traje nuevo del emperador“.

Si os fijáis en el BurnDown Chart de la imagen veréis que su quemado no es gradual con el paso de los días, sino que desciende abruptamente en los dos últimos días del Sprint, esto per se, ya es un indicativo de que algo no marcha bien.

Pero imaginemos que llegamos a la Sprint Review y en lugar de tener la situación de la imagen, nos encontramos con una mucho peor, y es que la gráfica de quemado dibuja el mismo trazado que en la imagen, pero deteniendo su quemado a falta de puntos en 20.

Los ítems que corresponden a esos 20 puntos pueden estar en progreso o incluso “finalizados” pero no se ha comprobado si cumplen el DoD, por lo tanto no están hechas (sería “desperdicio”). ¿Está entonces nuestro Incremento terminado?

Y es aquí donde entra en juego la mentira, comprometeremos en la Review que esos ítems estarán finalizados y disponibles antes de la siguiente Planning, ya que ahora mismo están a falta de pasar la revisión de calidad.

Pero… Volvamos al BurnDown Chart ¿Qué puede haber hecho que nos queden esos 20 puntos? Muy probablemente y sumado a que los ítems se validan al final del Sprint en 1 o 2 días, tengamos que añadir que esa labor la hace un número de miembros determinado del equipo (cuello de botella). ¿Y es ese el único origen del problema?

Cual es el origen del problema

Como en otras muchas situaciones anómalas, existen diferentes explicaciones que nos llevan a tener un falso Incremento terminado:

  • Una descomposición o slicing poco trabajado en los ítems del Product Backlog.
  • Acoplamiento entre los distintos ítems del Sprint Backlog, que implica que un ítem no está realmente terminado ya que completar un flujo implica finalizar n-ítems.
  • Dependencia entre los ítems del Sprint Backlog, suele darse cuando tenemos dependencias con otro equipo que trabaja sobre el mismo producto.
  • Existencia de nichos dentro del Development Team. Esto sucede mucho cuando se entiende la calidad como algo que deben asegurar únicamente los perfiles de QA (reduciendo su ámbito a testing) y no como una responsabilidad del equipo.
  • Establecer un “evento de testing” (muy ligado al punto anterior), y que se reduce a establecer un tiempo determinado del Sprint (al final) para realizar las pruebas que aseguren el Done de los ítems.
  • Falta de feedback temprano, que está estrechamente ligado al acoplamiento entre ítems y que impide hacer entregas que podamos validar durante el Sprint.
  • El Equipo de Desarrollo ha introducido ítems en la Planning hasta completar el 100% de su capacidad (maximización de recursos), en otro post analizaremos los posibles orígenes de esta situación.

Consiguiendo un Incremento terminado

Como habéis podido leer en el apartado anterior, la mayor parte de las cuestiones que originan este problema se podrían resumir en dos, carencias de o en el refinamiento, falta de un DoD responsabilidad de todo el equipo.

El Product Owner deberá:

  • Por un lado trabajar conjuntamente con el Equipo de Desarrollo en refinamientos para conseguir que los ítems sean realmente independientes (recordemos, INVEST).
  • Por otro lado trabajar con el Scrum Master para que le facilite las mejores técnicas que le permitan lograr ese grado de independencia y aporte de valor.

El Scrum Master deberá:

  • Ayudar al Product Owner a entender la necesidad y utilidad de la independencia entre ítems.
  • Trabajar con el equipo para que entiendan la importancia de la calidad y de un DoD de responsabilidad compartida.
  • Ayudar a entender al Product Owner la importancia de no forzar al equipo a comprometer más trabajo del que ellos se sienten seguros a completar.

El Equipo de Desarrollo deberá:

  • Realizar entregas tempranas que permitan el feedback y la reacción ante el mismo.
  • Tomar propiedad como equipo del DoD y de que la calidad es un requisito de equipo, no de una parte (esto no implica que no haya QAs).
  • Trabajar con el equipo para que hablen en la Sprint Planning sobre el forecast y la “presión” del Product Owner para añadir más funcionalidad.

Estas son solo algunas de las primeras aproximaciones que podríamos hacer, y deberíamos hacer que esto aflorase en la Retrospectiva.

Conclusión

El refinamiento aunque no es un evento formal de Scrum es necesario para ayudarnos a conseguir nuestro objetivo y por eso deberemos trabajar estrechamente en ello con todo el Equipo.

Por otro lado, la definición y entendimiento de un DoD responsabilidad de todo el Equipo es básico para crear un Incremento que esté, realmente terminado.

¿Qué opináis vosotros/as? ¿Os ha pasado esto alguna vez? ¿Es o no es una mentira arriesgada?

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.

Sliding Sidebar