He estado alentando a mi equipo actual a adoptar cambios en los procesos y flujos de trabajo para ser más ágiles. Se acerca nuestra primera retrospectiva y estoy buscando algunos consejos sobre cómo llevar a cabo la retrospectiva de una manera alentadora que influya en las personas para que adopten al menos algunos cambios.
He hablado con otros desarrolladores y con nuestro encargado de control de calidad y el director del equipo sobre sus opiniones y experiencias. Hasta ahora parece haber un acuerdo común sobre cambios positivos, pero tampoco mucha experiencia con procesos o flujos de trabajo ágiles.
Entre las sugerencias que creo que tienen puntos en común con múltiples compañeros de equipo están:
Además de hablar con los compañeros de equipo sobre puntos en común y sus preocupaciones y experiencias, ¿cómo debo realizar la retrospectiva real con el resto del equipo?
Suponiendo que podamos seguir haciendo retrospectivas periódicas, ¿cuál es algún consejo para hacer el mejor uso de las retrospectivas para impulsar incluso cambios incrementales en nuestro proceso?
Dejando de lado el hecho de que al menos algunos de los elementos de su agenda parecen ser intrínsecamente antipatrones de Scrum (pregunte por qué en una pregunta separada pero vinculada si realmente quiere saber), usted y el equipo se acercan a la Retrospectiva de Sprint evento incorrectamente al tratarlo principalmente como un ejercicio de mejora de procedimientos o herramientas. Si bien ese es a veces el resultado final, no es exactamente el objetivo del evento.
La Guía Scrum 2021 explica el propósito de la retrospectiva con bastante claridad, pero he subrayado algunos elementos para enfatizar:
El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado. ... Se identifican las suposiciones que los llevaron por mal camino y se exploran sus orígenes . El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas .
En otras palabras, el objetivo de la mejora de procesos no comienza con una lista de correcciones con viñetas. En cambio, es una exploración del proceso de todo el equipo, donde el equipo se esfuerza por identificar qué salió bien (para poder hacer más de esas cosas) y qué no salió tan bien , para que todo el equipo pueda colaborar en el proceso. soluciones que pueden ser acordadas, probadas y medidas.
Si bien es ciertamente una buena idea tratar de identificar algo factible en una retrospectiva que probablemente conduzca a una mejora tangible del proceso, en realidad es la comunicación y la colaboración dentro del equipo lo que crea la oportunidad de aprender, crecer y mejorar continuamente como equipo. Al ingresar al evento Sprint Retrospective con una lista de posibles soluciones, en lugar de un formato en el que el equipo se siente seguro al identificar honesta y colectivamente muda , mura y muri , ya ha secuestrado el valor real del evento (equipo completo). colaboración y la voluntad de inspeccionar y adaptar juntos) y lo reemplazó con un ejercicio de solución predigerido. ¡No hagas eso!
Supongo que estás usando Scrum.
Para un equipo que es relativamente nuevo en Scrum, las pocas retrospectivas iniciales tienen más que ver con aprender a resolver problemas por sí mismos que con resolver muchos problemas.
¿Estás en el rol de Scrum Master? Si es así, entonces podría investigar algunos posibles formatos retrospectivos. Probablemente, el más común de estos es recopilar comentarios sobre el sprint del equipo, agrupar comentarios similares y luego hacer que el equipo vote sobre qué temas quieren discutir primero.
La clave aquí es que el equipo desarrolle un patrón para identificar sus problemas y luego proponer soluciones para ellos. En el rol de Scrum Master, a menudo puede ayudar con esto brindándoles información. Por ejemplo, podrías decir algo como:
"Tuvimos bastantes problemas con el entorno de preparación en este sprint, conté 4 y fueron disruptivos. Puede valer la pena considerar esto con sus comentarios".
Para que quede claro aquí, usted no está estableciendo la agenda para la reunión. En cambio, está proporcionando información para que el equipo la considere. Es importante que el equipo reconozca bien los problemas , por lo que no es lo ideal que les cuenten los problemas a cucharadas.
davidg
RoboBear
Todd A. Jacobs
Bogdán
davidg