(This article is the translation of the english version. You can read the original in this link)

“Hay que identificar las opciones de mejora, y no las obvias, sino hacer un análisis en detalle de estudio de viabilidad de propuestas, impacto positivo o negativo, restricciones que pueden derivarse, cuantificar el margen de mejora, cuantificar el beneficio”

Lo que me he ido encontrando casi siempre que pensamos en realizar una retrospectiva de una iteración en un proyecto ágil es que estamos en cierta manera “encorsetados” por el estándar de facto que nos marca Scrum y los Scrum Master de referencia, pero creo que nuestra obligación es tomar uno de los bastiones de la agilidad como bandera, la mejora continua, y no quedarnos simplemente en aplicar el framework y andar los pasos que otros, más intrépidos, nos marcaron.

Antes de exponer la técnica propuesta de retrospectiva, identifiquemos el contexto en el que nos movemos.

(Creo que es interesante, para aquellos que no tengáis una cierta familiaridad con la gestión ágil de proyectos y más concretamente con Scrum, hacer una visita a la Web de Scrum Alliance, para mí la referencia a la hora de certificaciones CSM o CPO en la que podéis leer una guía rápida en el siguiente enlace: https://www.scrumalliance.org/why-scrum/scrum-guide )

¿Qué son realmente las reuniones de retrospectiva?

Por un lado tenemos que el objetivo de la reunión de retrospectiva es:

  • Inspeccionar cómo transcurrió el sprint en lo referente al equipo (Scrum Team y Stakeholders), relaciones, procesos y herramientas (herramientas y necesidades, no solo herramientas técnicas como puede ser un IDE adecuado, un gestor de código fuente que funcione correctamente, etc. Cualquier tipo de necesidad como material, pizarra, una silla, teléfono para poder comunicarme con el PO, etc.)
  • Identificar y ordenar (por impacto) aquellos elementos que tienen mayor margen de mejora
  • Crear un plan de acción para implementar las mejoras en la manera en la que el Scrum Team trabaja. (La relación con los stakeholders, identificación de necesidades, de impedimentos, métricas, reporting, etc. también es trabajo, no solo es picar código)

Si lo traducimos a un lenguaje más entendible, básicamente queremos contestar a tres cuestiones básicas:

  • ¿Qué ha ido bien durante el sprint?
  • ¿Qué ha ido mal durante el sprint?
  • ¿Cómo podemos mejorar para la siguiente iteración?

Y ahí llega el papel decisivo de un buen Scrum Master. Tiene la obligación (sí, es su obligación) de persuadir, incitar, facilitar y promover dentro del Scrum Team la identificación de problemas y las opciones de mejora. Y no las obvias, sino hacer un análisis en detalle de estudio de viabilidad de propuestas, impacto positivo o negativo, restricciones que pueden derivarse, cuantificar el margen de mejora, cuantificar el beneficio. Scrum es un marco muy serio de trabajo, no por usar rotuladores de colores y post-its rosas es un juego. Realmente si el equipo es maduro, el margen de mejora es abrumador, pero hay que tomarse en serio el análisis del riesgo, el análisis de impacto, el análisis de los stakeholders y sus necesidades, la viabilidad en recursos (tiempo, coste y restricciones), el impacto tecnológico, la viabilidad técnica en el entorno arquitectónico objetivo, hacer un estudio de retorno de la inversión en las mejoras que tengan un alto grado de impacto, etc.

Si tenéis familiaridad con el marco, sabréis que básicamente lo que nos vamos a encontrar en la inmensa mayoría de ocasiones es la clásica “estrella de mar”.

Imagen obtenida de http://www.javiergarzas.com/2013/01/retrospectiva-software-agil.html

Con un aspecto real parecido a este

Imagen obtenida de http://scrum.menzinsky.com/2015/11/hay-alguna-tecnica-de-retrospectiva-que.html

Y es cierto que es una técnica muy adecuada y que tiene un gran potencial a la hora de actuar como catalizador para la generación de opciones de mejora, de cambiar la forma de pensar del equipo y darle una orientación positiva y constructiva a la reunión. El principal riesgo de las restrospectivas es que no sean productivas, que no se identifiquen opciones de mejora sino problemas a evitar en vez de “el cómo” evitarlos. Es obligación del Scrum Master (Sí, insisto, es su obligación) conseguir que el equipo construya opciones de mejora desde la perspectiva SMART (Specific, Measurable, Assignable, Realistic, Time-related) tan manida para el planteamiento de objetivos. Es importante tener en cuenta que las opciones de mejora son en objetivos para mejorar la ejecución del proyecto.

Pero la bondad de la técnica que acapara el 90% de la retrospectivas se convierte en más ocasiones de las que pensamos en su principal enemigo. Nos alejamos tanto de la orientación a la identificación de los problemas para construir opciones de mejora que dejamos de evaluar de manera exhaustiva esos mismos problemas que queremos solventar. Para mí, no debería existir una “starfish” sin su correspondiente grafo de  análisis de problemas. Esta técnica consiste en lo siguiente.

Análisis del problema

Deberemos construir un grafo cuyos nodos son los grupos en los que hayamos clasificado los problemas identificados en el sprint y las aristas sean las relaciones causales (causa -> consecuencia) o relaciones de interdependencia (causa <-> causa) entre esos problemas es, posiblemente, una de las mejores maneras de dar pie a una retrospectiva provechosa y una técnica de opciones de mejora eficaz. En una ilustración resumida, podríamos verlo de la siguiente manera:

Cada miembro del equipo tiene que identificar 5 problemas del proyecto. Es importante que cada uno complete su identificación antes de proceder a pegar los post-it en la pizarra y evitar que haya cierto sesgo y que prevalezca la idea de aquellos que tienen un mayor peso específico en el equipo.

Identificación de problemas - Sprint Retrospective

Identificación de problemas

 

Una vez colocados en la pizarra, se agrupan por los criterios que se identifiquen entre todo el grupo. Aquí es importante la labor del Scrum Master como facilitador a la hora de que el grupo sea capaz de identificar unos criterios de agrupación que aporten información de contexto útil y valiosa.

Agrupación de problemas - Sprint Retrospective

Agrupación de problemas

Una vez agrupados los problemas, procedemos a buscar la causa raíz, identificando, por ejemplo, los Five Whys de esos problemas y los incluimos en los grupos correspondientes, respetando la relación de causa raíz en el eje vertical. No es necesario establecer 5 pasos en cada problema, algunos serán una causa raíz originariamente, otros no necesitarán más de 3 pasos y otros necesitarán los “Five Whys”. También tengamos en cuenta que en un determinado eslabón nos encontremos con que la causa ya esté identificada como problema anteriormente, pudiendo haber cadenas causales que incluyan elementos considerados como primarios.

Una vez hecho este trabajo, revisamos si los elementos de la cadena causal están en el grupo correcto, ya que es posible que la causa de un problema, o uno de los eslabones intermedios de la cadena causal esté en otro grupo diferente. (Por ejemplo podemos identificar un problema que es la poca fiabilidad de las estimaciones, pero puede ser porque no tenemos solvencia técnica en una herramienta en concreto. El primer problema podría estar encuadrado en el grupo de “problemas de planificación”, pero su siguiente eslabón causal estaría en el de “problemas de capacitación”)

Buscar la causa raíz. Five Whys - Sprint Retrospective

Buscar la causa raíz. Five Whys

 

Ahora establecemos un grafo pintando aristas entre los grupos o entre problemas de distintos grupos (sin contar las relaciones causales de la técnica de los Five Whys, que se expresan por precedencia en el eje vertical)

Elaboración del grafo causal - Sprint Retrospective

Elaboración del grafo causal

 

Por último, cada miembro del equipo coge varios post-it con un peso y los asigna a los problemas que él considera más relevantes o que tienen mayor impacto en el proyecto. Suelo usar Fibonacci y usar 2, 3, 5 y 8 para que haya diferencia en la asignación de pesos y sea más complicado que se contrarresten los de menor valor.

Asignación de pesos - Sprint Retrospective

Asignación de pesos

Nos debería quedar algo más o menos así

Grafo de dependencia de problemas - Sprint Retrospective

Grafo de dependencia de problemas

 

Y ahora ya tan solo nos quedaría empezar la parte constructiva de la retrospectiva, la que es realmente productiva. Pero creo que es importante tener una serie de herramientas que permitan sacar partido al marco ágil en la ejecución de proyecto, más allá de rellenar pizarras con colores y pegatinas.

Gracias por haber leído el post completo, me alegra que haya resultado lo suficientemente interesante como para que llegues hasta aquí. Por favor, no te olvides de compartir este y otros post con aquellos que consideres que puedan tener un interés parecido o a quienes les pueda resultar útil. ¡El conocimiento hay que compartirlo!