¿Cómo debemos implementar elementos de Sprint Retrospectives?

Recomiendo cambiar el enfoque de sus retrospectivas. En lugar de encontrar ideas, intente concentrarse en cómo implementar una sola idea. Digamos que tiene tres partes de la reunión: encontrar ideas, cuál es el siguiente paso y cómo implementar ese paso.

En la primera parte, haces la recopilación de ideas, nada nuevo aquí, pero en la segunda parte eliges solo una idea , que el equipo implementará durante el próximo Sprint. En la tercera parte, realiza una reunión de planificación como una sesión sobre cómo implementar esa idea y llevar el resultado, las tareas, a su tablero de Scrum. Se recomienda encarecidamente cronometrar estas partes para que tenga suficiente tiempo para la tercera parte.

Con este enfoque tienes tu enfoque y seguimiento. No hay necesidad de hablar sobre el progreso de la idea durante el día a día, pero puede ayudar mucho. Poner las "tareas de ideas" creadas en el Sprint Backlog con un color diferente también puede ayudar, pero este truco depende del equipo.

Si no tienes las mejoras en tu Tablero Scrum, no serán visibles, y esto quiere decir que no existen (sí, puedes tener mejoras en tu Tablero Scrum).

El presupuesto es una pregunta interesante. Un buen Product Owner sabe que las mejoras continuas son cruciales en Scrum, el marco se trata de la mejora continua, por lo que no es cuestión de tenerlas o no. Si todavía tiene problemas, entonces necesita hacer más entrenamiento y ayudar a las personas a comprender la importancia de las mejoras continuas en cada nivel. Hacerlos extraoficialmente no es una buena idea , porque entonces ya no hay transparencia real, lo que eventualmente conducirá a la desconfianza entre el propietario del producto y el equipo Scrum.

Las retrospectivas son para la mejora de procesos

El propósito de una retrospectiva en Scrum es "inspeccionar y adaptar" el proceso del equipo. No pretende ser una sesión de lluvia de ideas para ideas de productos, o para generar historias de usuarios que la gente quiera ver en el panel de tareas; se trata de mejorar el proceso interno del equipo para hacer más de lo que funciona y menos de lo que no .

Por ejemplo, su equipo puede decidir que necesita renovar la "definición de hecho". O tal vez decidan que necesitan refactorizar la forma en que ramifican y fusionan el código fuente, o necesitan agregar un servidor de integración continua al flujo de trabajo.

Todo lo que sea interno del equipo va al Sprint Backlog (no al Product Backlog) y, por lo tanto, no requiere ningún consenso fuera del equipo. Sin embargo, si su retrospectiva identifica problemas de proceso que son externalidades (por ejemplo, la necesidad de asignaciones para un nuevo servidor de CI o fallas continuas relacionadas con transferencias entre equipos), entonces, por supuesto, la organización más grande deberá ser consciente de los problemas. .

Haz que los problemas sean visibles

La retrospectiva se trata de hacer visibles los problemas y permitir que el equipo tenga libertad de acción para autoorganizarse en torno a una solución. Sin embargo, si su cultura corporativa realmente no permite que el equipo Scrum resuelva los problemas, el equipo tiene el derecho y la responsabilidad de aumentar la visibilidad del problema y luego dejarlo directamente en manos de la gerencia.

Por ejemplo, si su equipo identifica la falta de un servidor de CI como un cuello de botella del proceso, entonces este problema debe plantearse con la organización. Si los que manejan los hilos de la bolsa dicen "prescindir", entonces esa es una decisión comercial con la que deben vivir: el trabajo del equipo es simplemente hacer que el costo de esa decisión comercial sea completamente visible.

Eso significa que nadie trabaja horas extras no pagadas ejecutando pruebas de integración manualmente, o la integración funciona "fuera del tablero". Si es trabajo, ¡va a la pizarra!

Si la organización dice que no a la CI, entonces las pruebas de fusión e integración simplemente se convierten en historias explícitas en el Sprint Backlog que:

1. requieren estimación;
2. consumir tiempo y esfuerzo; y
3. redirija los recursos, las horas de trabajo y los puntos de la historia lejos de las nuevas características.

El hecho de que estas tareas adicionales reduzcan la capacidad de los elementos del Product Backlog no es ni bueno ni malo; es simplemente una consecuencia natural de la decisión empresarial, y siempre que sea transparente y visible tanto para el equipo como para la organización, la responsabilidad de aceptar la capacidad reducida o cambiar la situación pertenece únicamente a la dirección.

El papel del Scrum Master

El papel del Scrum Master en todo esto es:

1. Facilitar la Retrospectiva de Scrum.
2. Anime al equipo a implementar mejoras de procesos internos por sí mismos.
3. Actualice los artefactos del proceso, como el Sprint Backlog o el cartel de "Definición de hecho" para reflejar los cambios acordados por el equipo.
4. Facilite la comunicación con la organización externa cuando los problemas sean más amplios que el proceso interno del equipo.

Y eso es. No eres una niñera. Su trabajo no es "administrar" los resultados de la retrospectiva, perseguir a las personas para asegurarse de que están implementando cambios o cualquier otra cosa que huela a microgestión. Eres un facilitador, un árbitro de proceso y un entrenador; no pierda de vista la función central que permite que Scrum funcione sin problemas como proceso .

Veo y experimento solo dos tipos de mejoras que surgen de las retrospectivas (o cualquier otra sesión de lecciones aprendidas):

• La idea de mejora se puede manejar dentro de su equipo (y por lo tanto su presupuesto) y solo debe implementarse si resultará en un beneficio directo para su equipo y, por lo tanto, en el progreso general de su proyecto. El seguimiento comienza en la próxima reunión de pie. Solo puede implementarlo si tiene un valor real para su equipo; de lo contrario, el equipo no lo hará. En ese caso, déjalo caer.

Cuando tenga éxito, puede distribuir esta lección aprendida al resto de su organización.

• La mejora está fuera de la autoridad o capacidad de su equipo (por ejemplo, procesos organizativos, o depende de herramientas o...). Aquí no puede hacer nada más que tratar de convencer a los demás (por ejemplo, a su gerente) de que mejoraría enormemente sus (y posiblemente otros) equipos, reduciría costos, aceleraría la entrega, etc. Esto está fuera del presupuesto de su proyecto, a menos que se decida que puede agregar esto como un elemento de alcance adicional que debe realizar su equipo, teniendo en cuenta el impacto en el presupuesto disponible. De lo contrario, está completamente fuera del alcance de su equipo y solo puede recordar a las personas relevantes su importancia (con nuevos casos, números adicionales de desperdicio, etc.) y verificar regularmente si hay algún progreso.