En este caso vamos a comentar sobre una reunión, que si bien no se encuentra dentro de ningún modelo, metodología o conjunto de buenas prácticas (TecnoEstrategia made XD) pensamos que aporta información muy importante justo en el inicio del sprint, o más bien antes del inicio.

Introducción

Este tipo de reuniones (Ante Mortem) no están contempladas dentro de scrum ni dentro de ningún otro modelo más o menos «acotado». Sin embargo es una práctica muy habitual dentro de casi cualquier proyecto.

¿Quién no ha visto antes de un sprint (o del comienzo de un proyecto, trabajo, etcétera) a personas del equipo decir y anticipar lo que ellos piensan que saldrá mal? en desarrollo y en proyectos tecnológicos esto, creemos, que está a la orden del día.

Aunque dichas prácticas no se engloban como «normales» dentro de los procesos escritos y documentados y estén consideradas más bien de «café», lo que proponemos desde TecnoEstrategia es la «formación e inclusión» de estos comentarios, ironías, etcétera dentro de un proceso de desarrollo.

Al final se trata de contar con el equipo, con sus sentimientos, con sus percepciones y en definitiva seguir un modelo y unos principios de desarrollo colaborativos y positivos.

Si buscamos resumir en una frase el objetivo de estas reuniones, esta podría ser: analizar lo que puede salir mal antes de comenzar el siguiente sprint.

Por tanto, se busca ante todo, identificar los riesgos del futuro sprint.

La idea es que participen todos los miembros del equipo y sobre todo mantener una serie de skills que tienen que tener como resultados que los conflictos y las tomas de decisiones sean productivos, y precisamente de esto trata el modelo de reunión que proponemos.

Desarrollo de una reunión Ante mortem

El equipo al completo (cada persona debería hacer una lista previa a la reunión y al menos dedicar un tiempo a reflexionar sobre lo que ha escrito) expone los problemas que cree que pueden llegar a ocurrir, bien sean durante el desarrollo del sprint o bien directamente sobre el producto.

Se busca encontrar los posibles riesgos, bien sean en forma de problema tangible sobre cosas concretas (modelo, metodología, funcionalidad, tecnológica, etcétera) o bien sobre las actitudes, comportamientos, emociones, soft-skills, etcétera del equipo.

Técnica propuesta

Se pueden proponer tres preguntas claves:

– ¿Qué irá mal?

– ¿Por qué irá mal?

– ¿Dónde veis una posibilidad de auténtico desastre, por qué?

Después se pueden clasificar en común, es decir se clasifican por todo el equipo por igual, y se intenta determinar:

– Gravedad

– Impacto

– Riesgo

– Importancia al negocio

Una vez acotados esos futuros problemas, la idea es intentar solucionarlos o al menos estar preparados por si surgen.

Resultados

El objetivo básico y principal es encontrar, por un lado la manera de identificar riesgos, miedos de los miembros del equipo, y futuros problemas.

Si se hace de una manera positiva y constructiva, es fácil identificar problemas que si bien no forman parte del propio sprint sí que suelen afectar a las demás partes de la organización que no están inmersas en los procesos de desarrollo.

Algunos datos interesantes que se pueden obtener son:

– Problemas y/o riesgos en común.

– Problemas y/o riesgos ocultos.

– Detalles, prácticas, etcétera que están en un estadio muy inicial de riesgo y/o problema y que de seguir así se convertirán en ello.

Algunas métricas útiles dentro de un proceso de mejora continua

– Número de problemas/riesgos identificados

– Relación de problemas/riesgos con

– Urgencia

– Impacto en el negocio

– Ralentización del proyecto

– Clasificación de problemas y/o riesgos (menor, mayor, grave, bloqueante)

– Funcionalidad VS bugs

– Relación con los valores de importancia al negocio

– Relación con los valores de urgencia

– Relación con los valores de frecuencia de uso

– Relación con estados de preparación

– Áreas concretas de problemas/riesgos

– Capa de gestión

– Capa de aplicaciones (partes del sistema)

– Capa de metodología /forma de trabajo

Y hasta aquí la primera reunión de la serie, en breve seguiremos aportando nuestro particular punto de vista sobre las reuniones en un modelo agile de desarrollo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *