Cosas que echo en falta el la mayoría de retrospectivas que veo

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, el Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth u otros tantos. Y entiendo que si facilitas retros desde hace tiempo… ya se te ha quedado corta la empalagosa web de funretrospectives.

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

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Latest posts by jgarzas (see all)

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *