lunes, 30 de octubre de 2023

Como mejorar los resultados del equipo, mejorando las retrospectivas

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 ;-) 

Accion 1: Redactar planes de mejora en términos de acciones concretas específicas (no metas) que el equipo pueda medir objetivamente para evaluar si el equipo está aplicando el cambio de proceso. Primero, mida para ver si el equipo está siguiendo la acción planificada.

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

Accion 2: "Necesitan poner el kaizen en el backlog. Necesitan usar Scrum para mejorar Scrum". 

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 

No hay comentarios:

Publicar un comentario