Mi equipo tiene ciertos problemas que ya he determinado, a saber:
En general, el equipo está trabajando bastante lento.
¿Cómo puedo tener una retrospectiva para traer esto a la superficie sin herir ningún sentimiento? Es decir, la retrospectiva debe abordar esencialmente el tiempo de ciclo alto y estos problemas.
No hay nada de malo en darle a un equipo un alcance para la retrospectiva , especialmente cuando estas reuniones no aportan demasiado para el equipo. Puede establecer un tema como "velocidad" o "número de artículos entregados" y dejar que el equipo discuta estos temas. Cuando aprenda a lidiar con un alcance reducido, puede proporcionarles uno más grande. Según mi experiencia, un equipo puede tener mejores retrospectivas y procesos mejorados en 2 o 3 meses con esta técnica.
Recuerde que el objetivo de un equipo ágil es ser autoorganizado. Para lograr esto, deben tener la oportunidad de identificar sus propias fallas y encontrar sus propias soluciones.
Puede ser muy tentador intervenir y guiar la retrospectiva. Pero esto corre el riesgo de quitarle al equipo la responsabilidad de arreglar sus propios problemas, lo que puede ser contraproducente. No hay nada de malo en sugerir soluciones, pero desea que el equipo detecte los problemas.
Como Scrum Master, cuando identifico problemas, normalmente trato de encontrar alguna forma de resaltarlos. Por ejemplo, si el equipo está dividiendo historias en sprints de tiempo limitado, comenzaría a rastrear esto y hacer que los resultados sean visibles. Por lo general, el equipo comienza a abordar el problema una vez que lo reconoce.
Al leer su lista, me sorprende que ninguno de estos elementos haya sido mencionado en la retrospectiva. Por ejemplo, ¿el evaluador no ha comentado la forma en que se divide el trabajo de control de calidad? ¿Nadie ha mencionado que están rompiendo tareas a través del cuadro de tiempo?
¿Quizás el formato de retrospectiva que está usando no alienta a los miembros del equipo a hablar? Esta es una de las razones por las que un enfoque común para las retrospectivas es hacer que los miembros del equipo escriban sus comentarios de forma independiente al comienzo de la retrospectiva. Luego, el equipo en su conjunto discute cada elemento por turno. Esto asegura que todos tengan voz.
Hemos experimentado un problema similar en la empresa para la que trabajo y, por lo general, se trata de una cuestión de confianza entre el equipo. Antes de que realmente pueda abordar los problemas de tiempo de ciclo, debe reconstruir la unidad del equipo.
Probablemente la retrospectiva más exitosa que hemos tenido, comenzamos como cualquier otra con una pregunta de verificación y leyendo la directiva principal. Repartimos montones de tarjetas de 3x5 y rotuladores a todos y pusimos un tazón grande en el medio y les dijimos a todos que escribieran cualquier cosa y todo lo que sintieran sobre el equipo y su entorno de trabajo actual. Después de que todos terminaron de escribir, nuestro moderador leyó cada uno en voz alta y los pegó en una pizarra blanca. Cuando el recipiente estuvo vacío, habíamos llenado por completo una pizarra grande y preguntó si alguien vio algo de lo que quisieran hablar.
Fue una reunión larga de 4 horas, pero cuando terminamos, todas las personas se sintieron mucho mejor con el equipo y en 2 iteraciones estábamos superando a todos los demás equipos del departamento y fue más fácil guiar futuras retrospectivas para señalar cualquier problema porque el equipo sintió que todos podían hablar libremente.
Leí dos preguntas:
En general, invertir ahora en la formación y el desarrollo de equipos podría aumentar enormemente la eficiencia y la eficacia en el futuro.
La recomendación general para la primera pregunta proviene de la teoría de la negociación. No conozco la expresión original en inglés, pero debería ser similar a: Soft to the person, hard to the point .
Yo probaría algo similar a lo siguiente:
Primero, prepárate:
Después de que el equipo discutió sus observaciones, lo que condujo a temas positivos y negativos, haga un descanso y luego trabaje en los temas:
Como de costumbre, mantenga al equipo en movimiento involucrándolos usando tarjetas, rotafolios, etc.
Parece que su equipo no recibió la inducción correcta sobre el proceso y los beneficios de implementar la metodología Agile.
Le sugiero que detenga sus actividades de ingeniería, ejecute formalmente un inicio de proyecto que cubra el proceso, los roles y las responsabilidades, los beneficios de la realización del producto/proyecto. Más tarde, revise su cartera de productos y continúe su viaje.
Tenga en cuenta que la retrospectiva siempre es reactiva y ayuda a abordar las lecciones aprendidas (errores costosos).
Podría ser útil hacer un ejercicio retrospectivo para llegar a una buena comprensión de por qué las personas no se emparejan lo suficiente (por cierto, lo que es "suficiente") y no colaboran lo suficiente como equipo.
Puede usar preguntas para esto, o un ejercicio de constelación (descrito en mi libro ) o cualquier otro ejercicio para generar conocimiento.
Enfóquese primero en construir una imagen compartida con el equipo de cómo les está yendo ahora, lo ayudará a tener un mejor caso para tomar acción. Hay muchas posibilidades de que el propio equipo decida qué hacer más o menos. Aquí es donde un ejercicio de estrella de mar puede ser valioso.
@BenLinders
Bryan Oakley