comenzar reflexionando sobre la directriz principal del espacio, propuesta por de Norm Kerth: "Independientemente de lo que descubramos, entendemos y realmente creemos que todos hicieron el mejor trabajo que pudieron, dado lo que sabían en ese momento, sus habilidades y destrezas, los recursos disponibles y la situación en ese momento"
Premisa: los datos deben direccionar la retrospectiva, sino se analizan datos y hechos solo estan promoviendo mejoras cosméticas ;-)
En segundo lugar, medir el cambio en el rendimiento para
evaluar si el kaizen tuvo los resultados deseados.
Dentro de una retrospectiva, haga lo siguiente:
1. Examine
las mejoras comprobables anteriores para ver si el equipo realmente las hizo y
si tuvieron un impacto positivo.
2. Para
cada mejora propuesta, pregunte cómo validará el equipo la mejora (cómo sabe si
el equipo tomó la acción planificada y en qué medida).
3. Si
no puedes validar la mejora propuesta, no la aceptes.
Para medir si una acción de mejora realmente funciona,
necesita un medidor, una escala y una línea de base del rendimiento actual
Identifique el impedimento más importante en la Retrospectiva del Sprint y elimínelo antes del final del siguiente Sprint. Para eliminar el impedimento de máxima prioridad, colóquelo en el trabajo pendiente del sprint como una tarea con pruebas de aceptación (consulte Mejoras comprobables) que determinarán cuándo está terminado. Tener cuidado sino ha analizado adecuadamente la dinámica del sistema y no ha entendido la causa raíz de la disfunción principal, no estara atacando el problema sino un sintoma :-)
fuentes:
scrumbook.org.datasenter.no/retrospective-pattern-language/testable-improvements.html
scrumbook.org.datasenter.no/retrospective-pattern-language/scrumming-the-scrum.html
