Indice de contenidos
¿Qué es y en qué consiste la Retrospectiva?
El propósito de la Retrospectiva o Sprint Retrospective según la Scrum Guide es un evento donde el Scrum Team busca la manera de mejorar a nivel de calidad y efectividad. En este evento suceden muchas conversaciones e interacciones sobre cómo mejorar los procesos, herramientas, las interacciones de las personas, endurecer el Definition Of Done, etc.
Estas mejoras que identifica el Scrum Team podrían añadirse al Sprint Backlog del equipo para abordarlas en el siguiente Sprint.
El evento de la retrospectiva sería el punto final del Sprint y dará espacio al próximo Sprint, la retro suele tener una duración de 3 horas o menos para un Sprint de un mes y evidentemente para Sprints más cortes, retros más cortas.
¿Qué preguntas debemos de plantearnos en la Retrospectiva en Scrum?
Durante la retrospectiva el Scrum Team podría debatir sobre las típicas preguntas que ya muchas personas conocen:
- ¿Qué fue bien durante el Sprint?
- ¿Qué se puede mejorar?
- ¿A qué nos comprometemos el próximo Sprint?
Como se puede observar están muy bien, pero son muy abiertas y muy básicas, asi que desde nuestro humilde punto de vista, hay que ir un paso más allá. Por ejemplo, pocas veces vemos equipos analizando los valores de Scrum, los pilares de Scrum o el empirismo, al mismo tiempo, vemos que la mayoría de los equipos fallan en el uso de Scrum debido a los valores: Coraje, Respeto, Franqueza, Foco y Compromiso. Pero hay mas preguntas que podemos plantearnos para reflexionar sobre cómo mejorar:
- ¿Qué impedimentos o problemas habíamos tenido durante el Sprint?
- ¿Tenemos la capacidad de entregar valor en cualquier momento sin esfuerzo relevantes? en otras palabras ¿Tenemos Continous Delivery y Continous Integration?
- ¿Cómo hacemos las pruebas para asegurar la calidad?¿Estamos implementando pruebas automatizadas?¿Utilizamos BDD y TDD u otros enfoques?
- ¿Nuestro Definition of Done nos está permitiendo producir unidades de valor de alta calidad? ¿Debemos endurecerlo?
- Podemos sacar nuestro Cycle Time Scatterplot y ver cómo se han comportado nuestros PBIs y si hay algún patrón: solo entregas al final, que han comprometido la calidad, bloqueos, etc.
- Nos hemos pasado en el 50%, 80% nuestro SLE (Service Level Expectation)
- ¿En qué medida hemos alcanzado nuestro Sprint Goal? ¿podemos tener en cuenta el orden de las cosas en el Sprint Backlog?
- ¿Estamos teniendo problemas con el nivel de conocimiento que impide a las personas avanzar? ¿Hemos probado Pair Programming? ¿Hemos probado Mob Programming?
- ¿Qué tal nos comunicamos?
- ¿Cómo es la colaboración en el equipo?
Siempre es una buena idea respaldar estas preguntas con datos, ya que es más fácil llegar a acuerdos con datos.
Ejemplos de Retrospectiva
A día de hoy hay variedad de formas de hacer o facilitar la retro, asi que, compartiremos unos tips básicos para facilitar una retro:
- Hacer un IceBreaker, algo ligero, 2 a 5 minutos como máximo.
- Revisar las acciones de mejora de la retrospectiva anterior y si pudieron ser realizadas o introducidas.
- Depende si es presencial o virtual, crear un espacio donde las personas pueden ir dejando sus post-its o notas sobre que fue bien y que podemos mejorar
- Sugerimos siempre que esta parte sea en modo anónimo y que las personas puedan aportar hasta un máximo de post-its
- Permitir a las personas explicar sus aportaciones
- Agrupar las notas, ya que pueden existir varias notas con diferentes palabras pero quieren decir lo mismo.
- Votar los post-its (si es anonima mucho mejor, Miró permite esta opción)
- Buscar acciones de mejora. Esta parte es donde fallan la mayoría de los equipos, las acciones deben de ser acciones que permiten responder a las siguientes preguntas:
- ¿Impacto o beneficio de la acción de mejora?
- ¿Resultados claves o métricas?
- ¿Cómo sabremos que la acción ha sido realizada?
- Todas las sub-actividades deben de llevar un Time Box
Otros formatos de Reto
En el pasado habíamos experimentado con las siguientes retros:
Anti-patrones de Retrospectiva en Scrum
En principio la retrospectiva parece un evento simple, sin embargo, los equipos Scrum a veces caen en antipatrones que disminuyen el valor de la misma ¿Qué son esos anti-patrones?
- Los integrantes del equipo no participan activamente.
- El Scrum Master viene con su lista de mejoras
- Los problemas no salen en la sesión de la retro, pero si fuera de la misma
- El equipo se aferra a la armonía artificial y no ve ningún problema
- El punto anterior a menuda viene debido a la falta de confianza
- Falta de honestidad, apertura y comunicación
- Durante la sesión el equipo se centra en las cosas que no puede mejorar o que están fuera de su círculo de influencia
- Mirar mal a las personas que buscan la mejora, siempre tachandoles de negativos
- Centrar la retro en el reproche y juego de culpa
- El Product Owner no participa como uno más, ya que no siente que es integrante del equipo
- Falta de preparación de la sesión
- El equipo está aburrido con la retro y la ve como una pérdida de tiempo
- Las personas no entienden el propósito de la retro
- ¿Qué hace el Scrum Master en la Sprint Retrospective?
Solo por matizar un concepto: El Scrum Master NO es el dueño de la retrospectiva ni tiene que facilitar este evento siempre, si esto pasa, seguramente el equipo está todavía lejos de dominar Scrum. Entonces, ¿Qué rol juega el Scrum Master en este evento? El SM puede animar y promover que el resto del Scrum Team busque la mejora y no deje de buscar la manera de mejorar sus procesos, prácticas e interacciones para ser más efectivo de cara al siguiente o siguientes Sprints.
El equipo Scrum en su conjunto planifica la manera de aumentar la calidad del producto mediante optimización del flujo de trabajo y valor, cuando hablamos de optimización de valor no nos referimos a maximización, sino al arte de encontrar el equilibrio entre eficiencia, eficacia y predictibilidad del flujo de trabajo, también pasa por revisar el Definition Of Done, siempre que no entre en conflicto con los estándares del producto y los de la organización.
Y para ir cerrando, lo mejor que le puede pasar a un equipo es no esperar a la retrospectiva para hablar de la manera de mejorar, sino, todo momento es un buen momento para ajustar y mejorar. El evento de la retrospectiva es simplemente una oportunidad formal para hacer que suceda este espacio donde buscar como mejorar como equipo.
