La importancia de la última restrospectiva.

batman vs superman
Fuente: filmschoolrejects.com

Como desarrolladores, antes o después nos encontramos con un momento de finalización o termino del desarrollo de nuestro producto/proyecto, ya sea porque el cliente decide internalizar el desarrollo, porque decide que el nivel de madurez del producto no requiere de más desarrollo, porque el producto no está cumpliendo las expectativas, porque se va a traspasar el desarrollo del mismo a otro proveedor… Esto supone como consecuencia la ejecución de la última iteración, el último Sprint.

Tal como la propia definición del framework indica, al final de cada Sprint, se llevan a cabo dos eventos que son (como el resto en Scrum) de carácter fundamental para la correcta ejecución de Scrum: el Sprint Review al que nadie le plantea dudas y el Sprint Retrospective, y es en este punto donde algunos comienzan a no ver la utilidad y la importancia de llevar a cabo este último evento en el último Sprint, o peor aún si cabe, plantearlo como un post-mortem.

El post-mortem como la propia palabra indica es algo que se realiza cuando el producto o proyecto (quizás sea más coherente en este segundo ámbito) ya se ha finalizado, no se está haciendo nada con él, está “muerto”.

Y lo que es más importante aún, un “post-mortem” conlleva una connotación negativa asociada (además del propio nombre) y es que es sobre todo una práctica asociada a proyectos fallidos.

Muchas de las diferencias entre las retrospectivas y los post-mortem se reducen a una cuestión de mentalidad. Las retrospectivas consisten en realizar cambios en la forma de trabajar, es por ello que el equipo no necesita permiso para realizar los cambios exigidos por una retrospectiva, se llevan a cabo en puntos de utilidad para el desarrollo, no al final del mismo.

Teniendo en cuenta que el post-mortem es un listado de “lecciones aprendidas” cabe destacar una aportación muy brillante en este aspecto realizada por Tim Lister que comentó en una ocasión algo parecido a “Si las lecciones aprendidas al final del proyecto fueran realmente importantes, comenzaríamos cada proyecto con una lectura obligatoria de las lecciones aprendidas.” Creo que todos estaremos de acuerdo en que no es una práctica muy habitual.

the walking dead Negan
Fuente: eluniverso.com

Post-mortem de un desarrollo software

La definición más breve y concisa que se nos viene a la cabeza es que un post-mortem es: “La clave para aprender de los errores” ¿Cómo? Documentándolos. Y es innegable que esto está directamente ligado a la mejora continua.

Es por ello que cuando el desarrollo de un producto/proyecto acaba siendo parcial o totalmente fallido se ve útil y necesario reflejar qué hemos aprendido durante el proceso y qué podríamos cambiar para mejorarlo. De esta forma cualquiera tiene acceso a esa experiencia y puede acceder a ese documento y consultarlo ante situaciones que puedan resultar similares o que se estén dando dentro del mismo cliente o el desarrollo de un producto de características similares.

Cuando se elabora un post-mortem no intentamos buscar o señalar culpables, se trata de hacer un ejercicio de honestidad analizando todos los aspectos o causas que han podido llevar al desarrollo del producto/proyecto a una situación de finalización “anormal”. De esta manera debemos encontrar los puntos concretos que ocasionaron esos fallos y plasmarlos con el mayor detalle posible en el documento. Nuestro documento debiera incorporar un registro de todos los aspectos/causas en el siguiente formato (se trata de algo orientativo):

  • Breve introducción del proyecto: servirá de contexto para el lector.
  • Descripción del problema: explicación detallada del problema.
  • Línea temporal: descripción de la evolución del problema desde que se detectó.
  • Impacto y daños: análisis detallado de las consecuencias que ha tenido.
  • Acciones realizadas: descripción de las acciones que se llevaron a cabo una vez detectado el problema.
  • Plan de acción: este es el punto crítico del documento y es donde debemos analizar más en profundidad ya que debemos plantear las distintas opciones de solución que evitarían el problema o lo solventarían si volviera a presentarse.
  • Lecciones aprendidas: refleja todo lo aprendido ante la situación, las conclusiones.

La salida del post-mortem

La salida o el documento resultante de este ejercicio está orientado a la organización.

“Cada fracaso nos enseña algo que necesitábamos aprender.” Charles Dickens

El último samurai
Fuente:  businessinsider.com

Retrospectiva del último Sprint

Como comentábamos al principio del post, la palabra post-mortem tiene una connotación negativa asociada, esto no tiene que pasar necesariamente en la Retrospectiva del “último Sprint”.

Puede darse el caso de que estemos llevando a cabo nuestro último Sprint porque el desarrollo del producto haya fracasado y hayamos perdido la confianza de nuestro cliente, pero esta no suele ser la causa principal, por lo general, el desarrollo se considera “terminado” por parte de cliente.

La Retrospectiva es un evento que se lleva a cabo dentro del Sprint por lo tanto implica que el “desarrollo” aún está vivo, en una fase “final” si, pero el evento se lleva a cabo dentro del Sprint (seguimos iterando) y el Sprint en si no finalizará hasta que no se lleve a cabo el mismo.

Fuente: leadingagileteams.com

No vamos a entrar en detalle en qué consiste una retrospectiva o las distintas dinámicas que se pueden llevar a cabo dentro de la misma para conseguir maximizar el output de la misma pero sí diremos que es totalmente necesario llevarla a cabo ya que en esta última Retrospectiva podemos:

  • Realizar las tareas propias de una Retrospectiva ordinaria como:
    • Inspeccionar las relaciones entre las personas.
    • Inspeccionar el proceso y las herramientas.
    • Revisar la DoD

Y adicionalmente:

  • Realizar un análisis de los puntos fuertes y los posibles puntos de mejora relacionados directamente con el desarrollo del producto, que podemos llevarnos a otro equipo como una lección aprendida y buenas/malas prácticas.
  • Plantear la siguiente cuestión: “Si mañana tuviera que volver a empezar el desarrollo de este producto ¿Que me llevaría de lo aprendido y que dejaría?”
  • Empoderar y agradecer al equipo su trabajo.

La salida de la retrospectiva

La salida o el documento resultante de este ejercicio está orientado al equipo.

Podemos aprovechar además esta última Retrospectiva para echar un vistazo atrás y analizar el global del resto de iteraciones, puede ser un buen momento sin duda.

Como conclusión tanto uno como otro tienen sentido, bien es cierto que el “post-mortem” está orientado más al ámbito de proyecto y se realiza sobre todo ante casos de fallo, mientras que la Retrospectiva es un evento que se realizará en todos los casos. El resultado pues de realizar la Retrospectiva del “último Sprint” (siempre existirá un siguiente aunque no sea en ese producto/proyecto) es el de llevarnos esa experiencia al desarrollo de otros Productos, el de seguir mejorando, y el de reconocer el trabajo del equipo.

Me gustaría saber la opinión que tenéis al respecto ¿Os animáis a compartir con nosotros/as vuestro punto de vista?

2 comments On La importancia de la última restrospectiva.

  • ¡Qué interesante! No había pensado en esto, pero es una herramienta muy potente.
    Saludos,
    Esther

    • Gracias Esther. La retrospectiva en si es uno de los eventos que más nos nutren en Scrum ya que se enfoca en mejorar y es por ello que cualquier aprendizaje es válido independientemente de si estamos cerrando una etapa/desarrollo.

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