¿Son privados los detalles de las retrospectivas?

Durante una Retrospectiva de Sprint, los miembros del equipo recopilan y discuten sus oportunidades de mejora. El Scrum Master y el Product Owner también deberían participar en la Retrospectiva, ya que son parte del equipo. Los miembros del equipo no tienen que limitarse a mejoras para sus procesos. También pueden decidir, por ejemplo, desarrollar sus habilidades con respecto a una tecnología específica o utilizar otras oportunidades de desarrollo.

Sin embargo, los equipos a menudo no están seguros de si deben compartir las mejoras identificadas con otros o mantenerlas para sí mismos.

En mi opinión, es ideal si los resultados de las retrospectivas de todos los equipos siempre se comparten con otros. Después de todo, la transparencia es uno de los pilares sobre los que se construye el proceso Scrum. Pero aunque acogería muy bien una cultura de apertura en la que todo pueda compartirse con todos, eso lamentablemente ocurre muy raramente.

He encontrado que la mayoría de los equipos Scrum no tienen problemas para hacer públicos la mayor parte de los puntos de mejora que identificaron en la Retrospectiva. Estos elementos son cosas predecibles con las que otros equipos ágiles en la organización también se ocupan: volverse mejor en un cierto ámbito, aprender algo específico o descubrir cómo lograr más o cómo completar ciertas cosas antes en el sprint.

De vez en cuando ocurre que un equipo no quiere compartir algo con otras personas

Estos son algunos ejemplos que yo mismo he experimentado:- El equipo quiere aprender una nueva tecnología que no encaja completamente con la dirección de la empresa, pero que suena tan prometedora que el equipo quiere probarla de todos modos.- El código en una parte del sistema debe limpiarse, de lo cual el Product Owner también sabe, pero por ciertas razones no se quiere hacer público que está tan mal y que se necesita un alto grado de refactorización.- El equipo quiere descubrir cómo trabajar mejor con otro grupo, cuyos miembros, si leyeran esto aquí, preguntarían por qué exactamente se debe mejorar la relación.

Quiero enfatizar una vez más que, aunque la transparencia es extremadamente beneficiosa para los equipos ágiles, aún no todos los equipos han llegado a ese punto. Mientras que tal vez quieran mantener los resultados de sus próximas retrospectivas para sí mismos, pueden trabajar para poder abrirse mejor en el futuro.

Hacer pública una mejora planificada puede afectar la capacidad de realizar esa mejora. Ese es el caso, por ejemplo, en el último ejemplo mencionado anteriormente.

Anunciar que uno quiere mejorar la colaboración con marketing puede llevar a que allí se opongan a este cambio o que quieran saber qué exactamente no está bien y por qué se desea un cambio.

(Por supuesto, también podría ser que se esté abierto a mejorar la relación. Por lo tanto, siempre discutiría la situación con alguien de ese grupo).

Simplemente pregunta en la Retro

El equipo tiene entonces al final del sprint una lista de cambios deseados en los que se ha acordado conjuntamente. Siempre pregunto al equipo si alguien tiene algo en contra de publicar esta lista. Si no hay objeciones, cuelgo esta lista en la puerta de la sala del equipo o la publico en la página de inicio del equipo.

Si hay objeciones, a menudo es suficiente simplemente quitar ese elemento de la lista pública.

En última instancia, los equipos Scrum deberían tener el coraje de hacer transparentes tantas de sus mejoras planificadas como sea posible. Sin embargo, en ciertos casos es ventajoso mantener uno u otro elemento de la retrospectiva para uno mismo.