Retrospectiva del Sprint
Finalidad y duración
Hay un Principio del Manifiesto por el Desarrollo Ágil, que dice: “A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento en consecuencia”.
Según la guía Scrum, el propósito de la retrospectiva Sprint es planificar formas de aumentar la calidad y la eficacia. La intención es reflexionar juntos sobre el trabajo del sprint anterior e identificar mejoras en un proceso continuo de aportar valor.
El propósito de este evento se puede detallar en lo siguiente:
- Inspeccionar cómo fue el último Sprint con respecto a individuos, interacciones, procesos, herramientas y su Definición de Hecho (DoD - Definition of Done). Por eso, la retrospectiva no es el foro adecuado para hablar sobre el producto como tal, o sobre el feedback de producto que los stakeholders hayan podido aportar.
- Identificar qué fue bien, qué problemas surgieron y cómo se resolvieron o no.
- Identificar los cambios más útiles para mejorar su eficacia. Las mejoras más impactantes se abordan lo antes posible.
En este evento se aprovechan las perspectivas y la experiencia de todos los participantes para compartir y conciliar puntos de vista diferentes, así como desarrollar medidas específicas para futuras mejoras.
Los participantes y la duración serán los indicados en la guía Scrum.
Desarrollo del evento
En Combat Agile se va a continuar integrando todas las acciones necesarias de la forma más natural posible reutilizando las herramientas que ya conocemos.
Por ese motivo no se esperará a la retrospectiva para “rememorar” lo que ocurrió durante el Sprint que tenga que ver con nuestro trabajo como equipo sino que, cuando surja un tema que encaje en lo dicho al principio, se añadirá al backlog como otro issue más. Se puede hacer añadíendolo al Sprint Backlog ordenado al final (ya que se hará al final) y sin estimar (para que no afecte en el burndown), o se pueden etiquetar con una etiqueta “Retrospectiva” que sea independiente de los hitos.
Probaremos estas dos formas y elegiremos la que ofrezca mejores resultados. También podría tenerse un proyecto aparte ya que no forma parte de un producto en concreto, pero para el curso vamos a hacerlo en el mismo para simplificar.
Los issues deben poder ser SMART: Específicas (Specific), measurable (Medibles), alcanzables (Achievable), realistas (Realistic) y de duración limitada (Time-bound).
Se irán recorriendo los issues a tratar de uno en uno al igual que se hacían con los impactos. No se debería avanzar hasta el siguiente a menos que el issue se dé por completado, se rechace hacer ningún cambio al respecto o se establezca una mejora.
El término mejora lo vamos a usar para un issue de retrospectiva que es SMART, ha sido tratado en una retro y tenemos claro cómo implementarlo.
Los issues de la Retro es importante mantenerlos ordenados por orden de impacto, ya que si no hubiera tiempo para hablar de todos en la Retro ni siquiera se hará y quedarán pendientes para otra (pueden esperar por ser de menor impacto). No obstante, esto no puede bloquear la mejora del equipo así que al menos debe haber una mejora que implementar.
El orden mantendrá arriba a las mejoras aprobadas con las que ya se está trabajando, por lo que lo primero de lo que se hablará en la Retro es del impacto que han tenido, si deben mantenerse tal cual o si hay que mejorarlas en algún sentido.
Lo más apropiado es que el orden lo establezca el SM ya que es el responsable de la efectividad del equipo. Además, conocerá todos los temas a tratar antes de la Retro y puede actuar al conocerlos, preocuparse por conocer más detalles sobre un issue concreto o, por ejemplo, preparar una dinámica durante la Retro para impulsar el correcto empleo de Scrum.
El SM también debe velar porque todos los miembros del equipo aporten. Quizás alguien no se sienta con confianza suficiente como expresar sus opiniones (Apertura), se haya sentido avergonzado al discutir sobre ellos (Respeto) o no le preocupe la Retro (Compromiso), ahí debe estar atento el SM para hacer ver la importancia de mejorar como equipo y que los valores Scrum se mantengan vivos.
Propuesta de mejora
Se implementarán un número de mejoras que se pueden abordar de manera realista junto con el desarrollo del producto (aproximadamente dos, las que tengan más impacto). A estos issues se les pondrá como fecha de vencimiento el día de la retrospectiva en el que se han aprobado como mejoras. El resto se quedarán sin asignar fecha.
Se recomienda que se asignen las mejoras al SM para que sea el que tenga más presente cómo el equipo se propone mejorar, evaluarlas por si pudiera haber algún impedimento o si hay que tratar con actores fuera del alcance del equipo (en la misma organización o completamente externo).
También pueden ser implementadas por otro miembro del equipo o incluso por personal externo si se tratan de mejoras en infraestructuras, compras, etc…