Scrum: Buscando los problemas y soluciones en las retrospectivas

Como hemos visto muchas veces, la mejora continua está muy ligada a los equipos ágiles. Concretamente, en las retrospectivas de Scrum, el equipo busca mejorar su productividad y calidad del producto en el que están trabajando, identificando los problemas, descubriendo las causas, creando un plan de acción, etc… Para equipos poco experimentados puede ser muy complicado llegar a encontrar el origen de los problemas y plantear soluciones efectivas de mejora, por lo que puede ser muy importante adoptar herramientas o estrategias que nos ayuden a conseguir nuestras metas.

Encontrar la raíz de los problemas

Durante la retrospectiva, el equipo buscará los problemas más importantes con los que se ha encontrado (por ejemplo, votando todo el equipo entre los distintos problemas propuestos, usando un diagrama de estrella). Sin embargo, es muy habitual encontrarnos que, aunque el problema es evidente, nos cuesta mucho encontrar o compartir las causas. Una posible solución es utilizar técnicas como la de los 5 porqué, en la que el Scrum Master pregunta para explorar las relaciones de causa-efecto del problema que está siendo analizado. Las preguntas se irían haciendo una tras otra, afinando en la causa del problema hasta llegar a la causa inicial de la cadena de causas, no siendo necesario que las preguntas sean exactamente 5.

Por ejemplo:

Problema: Durante el último sprint han surgido muchos bugs.

¿Por qué han surgido muchos bugs? Porque hemos tenido que desarrollar en un módulo de código heredado

¿Por qué han surgido muchos bugs por culpa de código heredado? Porque la calidad del código era baja.

Es muy habitual que respondiendo a estas preguntas encontremos ramificaciones. Existen otras herramientas como el diagrama de Ishikawa o de espina de pez, en el que el problema sería la espina central y a partir de ella saldrían las ramificaciones de espinas que representarían las causas. Igual que con la técnica de los 5 porqué, el objetivo es encontrar las causas raíces o iniciales que el equipo considere que son los orígenes del problema.

Proponer soluciones

Una vez encontradas las causas de los problemas, otro escollo suele ser encontrar soluciones adecuadas para los problemas. Muchas veces erramos al proponer soluciones muy genéricas, o estás son impersonales y nadie las lidera, etc. Una buena aproximación es proponer objetivos SMART como ejemplo de definición. ¿Qué significan las siglas SMART?

Specific: lo más concreto posible.
Measurable: debe ser medible, cuantificable.
Achievable: posible, alcanzable por el equipo.
Relevant: relevante para solucionar el problema.
Time-bound: definido en el tiempo.

Por ejemplo, si hemos identificado un problema de calidad de código en el proyecto, en lugar de proponer refactorizar las partes con peor calidad. Sería más acertado plantear que todos los desarrolladores del equipo eliminen 20 violaciones de “Sonar” a la semana, por ejemplo. Al estar definido en el tiempo y ser medible, es muy sencillo de ver si se ha cumplido en la siguiente retrospectiva. Además, contar con objetivos SMART simplifica la generación de tareas o acciones a seguir para solucionar los problemas.

Aplicar las soluciones

El ser Scrum un marco de trabajo iterativo, implica que vamos a poder ir incorporando las soluciones o mejoras veamos que están funcionando o dejar de ejecutar aquellas que han dejado de tener sentido por los cambios producidos en el marco del proyecto. Para ello es importante que una vez planificado acciones en la retrospectiva, las ejecutemos en el siguiente sprint y verifiquemos su mejora en la próxima retrospectiva a ser posible. El poder ir mejorando el proceso, sumado a la experiencia que irá ganando el equipo son clave para la mejora de la productiva y calidad de la que hablábamos al principio.

Javier Sanz