Si estás en un equipo de Agile coaches (de agentes de cambio, de transformación o como le quieras llamar), ¿también te pasa que en las retrospectivas mezclas mejoras sobre cómo trabajar dentro del equipo y mejoras en la manera de abordar la transformación? 🧵
Cuando empiezo con cualquier equipo que va a hacer Scrum, suelo explicar que la diferencia entre una retrospectiva y un refinamiento es que la primera se centra en mejorar los acuerdos de trabajo (cómo trabajamos) y el segundo en mejorar el plan de trabajo (qué queremos hacer).
En un equipo que desarrolla software es relativamente fácil distinguir ambos focos. Sin embargo, cuando nuestro plan de trabajo se centra en cambiar la manera de trabajar y, además, formamos parte del sistema (es decir, cuando no venimos sólo de visita), la linea es difusa.
P.ej. Estáis comprobando que os cuesta encontrar huecos en vuestras agendas para pensar juntos. La solución obvia: necesitamos más gente en el equipo para repartirnos el trabajo y tener más holgura. Pero si pensamos de una manera más estratégica...
podemos crear un plan para dar más autonomía a los equipos, p.ej. enseñándoles a hacer sus propias retrospectivas. En un medio plazo tendréis esa holgura deseada.
Otro ejemplo. Observáis que vuestro trabajo con los equipos se centra en ayudar a gestionar bloqueos entre ellos. Una posible solución desde un punto de vista sistémico sería darles herramientas para gestionar esos bloqueos entre equipos.
De nuevo, de un problema del "equipo de agilistas" (del cómo trabajamos juntos) hemos llegado a un cambio en nuestra propia planificación (del qué queremos hacer para mejorar la organización).
Parece obvio que algunos "dolores" de los equipos de agilistas son "señales" sistémicas. ¿Cómo las distinguís vosotros? ¿Y cómo las gestionáis? ¿Cómo las podría gestionar una organización que no tuviera Agile coaches?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
