1. Sprint Retrospective Meeting

2. Presentador
John Camilo Trilleros
Restrepo
Ingeniero de Sistemas
Scrum Master en Informática & Tecnología
Stefanini
jcrestrepo@stefanini.com
john2005pro@gmail.com
Cel Sv +503 7241 5475
Cel Co +57 3152282624

3. La retrospectiva es el último evento dentro de un Sprint, este
evento está diseñado para que el Development Team se auto
auto-evalúe y diseñe un plan de mejora en conjunto, también
representa un espacio en el cual el equipo plantea alternativas de
adaptación a posibles escenarios que se pueden presentar en el
proceso de elaboración de un producto.
Introducción

4. Etapas de una retrospectiva
Preparar el escenario.
Recolectar Datos
Reflexionar.
Decidir que hacer.
Cerrar la retrospectiva.

5. 1. Preparar el escenario (puesta en escena)
La retrospectiva se inicia con la preparación del escenario, esta
actividad tendrá una duración entre 5 y 10 minutos, el facilitador
normalmente es el Scrum Master quién durante esta actividad
comunicará la agenda incluyendo cada una de las actividades y su
duración, comunicará luego el objetivo de la reunión y dará inicio a
la retrospectiva.
Antes de iniciar la retrospectiva el Scrum Master muestra al equipo las
reglas de etiqueta que guiaran las interacciones de los participantes a la
reunión.

6. 1.1 Reglas de etiqueta
Antes de iniciar la reunión de retrospectiva es importante establecer unas
reglas que permitan enmarcar y darle alcance a las actuaciones de los
participantes en la reunión, estas reglas ayudan a que la gente se enfoque y
que el facilitador tenga un referente para hacer que los asistentes no se
desvíen del objetivo de la reunión o para hacer que se enfoquen de nuevo.

7. 1.1 Reglas de etiqueta
Puntualidad.
Evitar todo tipo de interrupción (teléfono, atender otros temas
durante la reunión, participar parcialmente etc).
Únicamente conversaciones de interés para todos.
Solo una conversación a la vez.
Toda opinión importa.
Todos opinan.
No buscar culpables.
Ser positivo.

8. 2. Recolectar datos
Al termino de los Sprint tenemos información acerca del trabajo
terminado, así como del trabajo que quedó pendiente, las interacciones
entre los integrantes del equipo y los impedimentos que se presentaron,
estos son los datos que se utilizarán en la retrospectiva, el Scrum Master
quien durante la ejecución del Sprint observa el proceso, puede aportar
una visión de los temas que están mas ligados con los objetivos del
proyecto y proponer algunas ideas, sin embargo todos los asistentes
participan haciendo sus propios aportes, generalmente se realizan lluvias
de ideas respondiendo a las siguientes dos preguntas:
¿Qué está funcionando bien?
¿Qué debemos mejorar?

9. 2.1 ¿Qué está funcionando bien?
Los asistentes participan en un brainstorming mencionando
temas que consideren relevantes y que deben replicarse como
buenas prácticas en los siguientes Sprint, estas buenas prácticas
pueden ser asuntos de metodología, uso de herramientas,
interacciones entre los integrantes de los equipos entre otros..

10. 2.2 ¿Qué debemos mejorar?
Los asistentes participan en un brainstorming
mencionando temas que consideren relevantes para
mejorar en los siguientes Sprint o impedimentos que se
presentaron pero aún no han sido resueltos y que
afectan la velocidad del equipo o incluso pueden poner
en riesgo conseguir la meta de los Sprint, es
recomendable abordar primero los temas que pueden
ser manejados directamente por el equipo y de último
los temas que dependen otras instancias.

11. 2.2 ¿Qué debemos mejorar?
Para el brainstorming se pueden utilizar post-it y un
pizarrón o papel rotafolio, en el cual se pondrán las
ideas de los asistentes, agrupándolas por categorías, la
agrupación facilitará que después los asistentes
participen de una votación que permita priorizar por
categoría, la priorización guiará el orden en el cual
realizaremos la siguiente actividad dentro de la
retrospectiva.

12. 3. Reflexionar (análisis causal)
Se analizan los temas a mejorar o solucionar en el orden de prioridad de la
actividad anterior, el objetivo NO es encontrar culpables sino encontrar las
causas que ocasionan los problemas y plantear las mejoras necesarias
para quitar los impedimentos, mejorar el proceso o interacciones entre los
integrantes del equipo o con terceros. Para realizar esta actividad se
recomienda utilizar un diagrama de Ishikawa o espina de pez, el cual se
realiza en forma de dinámica grupal, se plantea el problema a analizar
como espina dorsal y las causas que lo generan en forma de espinas que
crecen a partir de la dorsal, el objetivo es preguntarnos el por qué de cada
una de las causas hasta llegar a la causa o causas raíz a partir de las cuales
podamos plantear una mejora o cambio de fondo.

13. 4. Decidir que hacer (plan de acción)
Los asistentes a la retrospectiva proponen soluciones para las causas mas
relevantes que produzcan la mayoría de problemas del proyecto o
requerimiento a través de un brainstorming, así mismo votan por las
soluciones que sean mas viables teniendo en cuenta factores como el
costo de su implementación, esfuerzo, tiempo de realización, tiempo de
dedicación entre otros. El resultado de este ejercicio es una lista de tareas,
que deben ser auto-asignadas bien sea durante la retrospectiva o se
adicionarán al Sprint Backlog del siguiente Sprint para que sean
ejecutadas por el DevelopMent Team, cuando se traten de tareas que no
pueda gestionar directamente el Development Team, ni auto-asignadas
por alguno de los asistentes a la retrospectiva, el Scrum Master debe
encargarse de ayudar a gestionarlas con los responsables dentro del
negocio.

14. 5 Cierre de la retrospectiva
Para dar cierre a la reunión:
El facilitador resume las principales conclusiones y decisiones.
Se valida conjuntamente con los asistentes si se logró el objetivo de la
reunión.
Se hace una pequeña retrospectiva de la retrospectiva (para hacer
cada vez mas efectiva la retrospectiva).
Al final se debió encontrar buenas prácticas que se deben replicar en los
siguientes Sprint, también se debió encontrar puntos a mejorar y lograr el
compromiso de los asistentes en auto-asignarse tareas que ayuden con la
solución de los problemas, así como identificar tareas que deben ser
gestionadas por terceros, toda esta información debe registrarse en un
acta para poder hacer seguimiento posterior.

15. Referencias
Xavier Albaladejo. Una retrospectiva ágil de Scrum, 21 octubre 2008.
Alexander Menzinsky. ¿Cómo identificar de forma ágil posibles
causas raíz de un problema?, 12 de junio de 2016.
Leonardo De Seta. Las 5 etapas de una retrospectiva efectiva, 08 Abril
2010.