Retrospectiva: ¿diferencia entre recopilar datos y generar insights?

Estoy leyendo un libro llamado Agile Retrospectives y el autor sugiere dividir las retrospectivas en 4 etapas. Dos de las etapas parecen tan similares:

La recopilación de datos y la recopilación de información parecen lo mismo, ya que no puedo imaginar que algunos de estos ejercicios funcionen si hiciera un ejercicio de recopilación de datos y generación de información.

Algunos de los ejercicios de generación de conocimientos también requieren que usted... ¡reúna datos! Muy confuso. ¿La gente está usando ambas etapas en retros?

¿Tiene sentido? ¿Alguna idea?

Actualización: mi confusión se debe a mi incapacidad para vincularme a un ejercicio de recopilación de datos con una fase de recopilación de información. Ese es mi problema.

Por ejemplo: hago que el equipo haga una lluvia de ideas sobre lo que salió bien, lo que no salió bien en la etapa de recopilación de datos, luego simplemente dejo eso a un lado y paso a un ejercicio de conocimiento de datos que también, en sí mismo, requiere que el equipo escriba un montón de ideas abajo.

Respuestas (2)

Las dos etapas requieren un tipo diferente de pensamiento. Se complementan entre sí, junto con las otras etapas, para llegar a acciones que ayudarán al equipo a mejorar de manera efectiva.

  • Recopilar datos consiste en obtener información sobre el problema, tanto hechos como sentimientos. El equipo trabajará para crear una imagen compartida de la situación actual basada en lo que saben ahora.
  • Generar información se trata de llegar a una solución sobre cómo lidiar con los problemas que la recopilación de datos ha revelado. Estás buscando soluciones. En ese proceso, es posible que deba profundizar, por lo tanto, obtener información/datos adicionales. También puede ver esto como una iteración entre recopilar datos y generar información.

Lo principal a tener en cuenta es obtener una comprensión suficientemente buena de cuáles son los problemas reales antes de intentar encontrar soluciones. Esto aumenta la posibilidad de idear acciones efectivas que ayudarán a resolver el problema o evitar que suceda en el futuro.

A menudo hago un paso intermedio. Después de recopilar los datos, le pido al equipo que se agrupe y priorice o haga una votación por puntos. Luego, solo elegimos uno o dos problemas para generar información y decidir las acciones para abordar esos problemas. ¡Tiene sentido!

Creo que la idea detrás de las dos partes separadas (he hecho algo similar) es esta

  • Recopilación de datos: se centró en 'lo que sucedió' y realmente debería tratarse de hechos en lugar de cualquier interpretación. Es decir, "Las compilaciones se rompen con demasiada frecuencia" o "La prueba del componente X se retrasó, lo que significa que no tuvimos tiempo de resolver los errores antes del final del sprint".
  • Insights: centrado en la interpretación de los datos y lo que debería/podría hacerse en el futuro para evitar la misma situación (o fomentar la misma situación si fuera algo bueno:)). Es decir, '¡Necesitamos acortar el tiempo que toman las compilaciones para que las personas reciban comentarios antes y puedan corregir su código de mierda!' etc.

La idea aquí es evitar demasiada discusión y posiblemente herir los sentimientos al resolver lo que sucedió. Al programar esa parte de la reunión, puede pasar a la discusión de lo que se debe hacer. De lo contrario, se puede pasar demasiado tiempo en lo primero que alguien menciona, terminas en una madriguera de conejo y la reunión pierde la oportunidad de discutir algo realmente importante.