En casi todo en Agilidad, no hay doctrinas incuestionables (y así debe ser, cuidado con los frameworks y metodologías religiosas y los sacerdotes). Hay muchas opiniones (como las mías y otras tantas) para llevar acabo una cultura bajo apenas 4 valores y 12 principios. Cada uno tiene, lógicamente, sus opiniones, interpretaciones y maneras de ver la agilidad, basadas en sus experiencias, conocimiento, maneras de ver la vida, lo que ha sufrido, lo que ha disfrutado, etc.
También es cierto que algunas maneras de interpretar la Agilidad son más razonables, otras son discutibles y otras… difícilmente pueden interpretarse como Ágiles (como, por ejemplo, pretender trabajar en cascada y justificar que la cultura es Ágil).
Y, en linea con lo anterior, este post va de cosas que a mí me parecen razonables a la hora de hacer retrospectivas y que quizá para ti puedan ser discutibles.
Entiendo, doy por hecho, que todo el mundo que facilita retros ya se ha leído (si no ya sabes), o conoce, el libro Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers), el Improving Agile Retrospectives: Helping Teams Become More Efficient
Los anteriores son la parte fácil, la alcance de cualquiera, lo que todo el mundo se sabe, la parte más «happy», la más de colocar post-it, etc., y no es lo que echo de menos en las retrospectivas. La mayoría de las retros que veo se centran en llamativas dinámicas, generalmente sobre satisfacción, cómo sentimos que fue el Sprint, etc., lo cual esta genial, pero lo que echo de menos es…
Nunca hacer mención a cómo ayudar de manera sana a aportar valor al negocio, a la organización y mejorar la efectividad
El valor es la palabra importante de un Product Owner, pero entre que el Product Owner es parte del equipo, entre que debería ir a las retros y entre que, aunque sea cosa más de Product Owner, el valor no debería ser ajeno al equipo… se me hace raro cuando en ninguna retrospectiva se hace mención a cómo mejorar en lo que refiere a entregar valor a la organización, al incremento.
No hablar de eficiencia y desperdicio
Esto si que pilla más cerca, en el sentido de que si que le pilla más cerca al Scrum Master (recuerda el post de la eficiencia del proceso Ágil), que debería preocuparse mucho por la eficiencia del proceso Ágil, le toca al equipo técnico, que obviamente es parte activa de ello y, de manera similar al caso anterior… también al Product Owner, en lo que refiere a ayudar en lo que pueda.
No entrar en reflexionar sobre deuda técnica
Lo más normal es que no todas las retros traten la Deuda Técnica… ¿pero nunca hablar de ello? ¿No reflexionar nunca sobre qué dice, por ejemplo, Sonar de cómo va la Deuda Técnica? Ciertamente la Deuda Técnia cosa del día a día, como lavarse los dientes, pero hay veces que la cosa está en un nivel que… pide retrospectiva.
No hablar del “para que”
Muchas retrospectivas acaban analizando un problema y proponiendo una solución, pero pediría hacer la reflexión de «¿para qué?». Para qué vamos a probar ese experimento, que mejora de fondo esperamos obtener, que, probablemente ande rondando alguno de los puntos anteriores.
.
.
A un nivel más operativo, puedes complementar este post con este de 6 errores típicos en retrospectivas Ágiles
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024