Los temas de "caballo muerto" prohibidos en las retrospectivas de sprint, ¿es esta una buena práctica? ¿Por qué o por qué no?

¿Es este un estándar o una buena práctica para facilitar una retrospectiva para 'censurar' problemas conocidos como este?

Si y no. Siento que está mal censurar cualquier cosa, especialmente hablar de impedimentos en una retrospectiva. Por otro lado, discutir todo el tema una y otra vez cuando nada ha cambiado es improductivo y un desperdicio .

Como ejemplo: en mi antiguo equipo, el edificio de oficinas no tenía aire acondicionado. Dado que el edificio estaba alquilado y el arrendador estaba en quiebra, el arrendador no invertiría en aire acondicionado y la empresa no quería invertir en absoluto en un edificio que no era de su propiedad.

Así que no había aire acondicionado y hacía calor . Pero no había nada que pudiera cambiarse. Lo reportamos, sprint tras sprint, como un impedimento y un lastre para la producción. Pero eso es todo lo que pudimos hacer.

Pero como nada cambió desde el último sprint, no tenía sentido discutirlo cada vez. Lo ponemos en nuestras pegatinas, lo informamos hacia arriba y listo. Luego pasamos a discutir y pasamos tiempo en temas que podríamos cambiar .

Entonces, para resumir: nunca está bien censurar, pero es una buena práctica aceptar lo que no puedes cambiar y comenzar a cambiar las cosas que puedes, sin vencer al caballo muerto.

El equipo Scrum por sí solo no puede resolver todos los impedimentos. Es una buena idea tener algún tipo de ruta de escalada para los problemas que están fuera del control del equipo, pero que son recurrentes y dañinos.

Como Scrum Master, a menudo buscaba escalar este tipo de problema mediante un proceso de informes.

Por ejemplo, podría producir un informe de sprint que diga algo como:

Notamos en nuestra retrospectiva este sprint que hay un problema recurrente con el proveedor externo que está afectando negativamente al equipo. Creemos que esto puede reducir la productividad del equipo hasta en un 10 % debido al impacto de los tiempos de espera y los inicios retrasados.

Es posible que una vez que destaque regularmente un impacto en la productividad, llame la atención de su gerencia.

También consideraría un enfoque de radiador de información para este tipo de problema. Por ejemplo, podría colocar una lista de los 'tres principales problemas recurrentes' del equipo en la pared de un área pública de la oficina.

Este enfoque puede ser particularmente poderoso si varios equipos Scrum informan sobre los mismos problemas.

Una retrospectiva no debe prohibir temas. Y una retrospectiva tampoco debe hacerle perder el tiempo a la gente.

Dicho esto, lo que podría hacer es categorizar los elementos retrospectivos según diferentes categorías de influencia :

• Elementos que el equipo puede cambiar
• Elementos en los que el equipo puede influir
• Todo lo demás / Elementos que el equipo debe aceptar

Una vez que haya hecho eso, el equipo debe enfocar el retro en los elementos que el equipo tiene más control y menos en los elementos fuera de control. Con el tiempo, las personas aumentarán naturalmente los elementos en función del nivel de influencia que el equipo pueda tener en lugar de seguir golpeando a los caballos muertos.

Hay una gran cantidad de ejemplos de Circles of Influence en Internet, a continuación elegí uno de https://www.innovationgames.com/circles-and-soup/ ya que también ofrece una forma de ver esto como un juego retro. .

Una última nota: a veces, el límite entre "influenciar" y "aceptar" es muy delgado y depende de las habilidades de SM. Si ese es el caso, la sugerencia de BenLinders puede ser un buen enfoque (es decir, tener una reunión específica para analizar el problema).

Censurar un impedimento desde la retrospectiva no lo soluciona. Como parece ser un impedimento importante que está bloqueando al equipo, ¿tal vez valga la pena organizar una reunión por separado para analizar el problema para obtener un entendimiento compartido y encontrar una salida al impedimento?

Las ventajas de planificar una reunión específica son:

• Puedes enfocarte en el impedimento y darle la atención que necesita. Es más efectivo.
• Puede elegir una técnica específica para analizarlo realmente (como 5 veces por qué, mapeo de flujo de valor, etc.).
• En su retrospectiva, habrá espacio para abordar otras cosas importantes. El aprendizaje y la mejora no tienen que detenerse debido a un gran problema.
• Como equipo, es una gran oportunidad para practicar las habilidades de resolución de problemas.
• Dado que es una reunión separada, puede elegir quién debe asistir. No es necesario que todo el equipo asista a esta reunión, y podría ser útil invitar a personas ajenas al equipo que puedan tener ideas o puedan ayudarlo a resolverlo.

¿Te serviría algo como esto?

Si se plantea el mismo impedimento Sprint tras Sprint, eso plantea algunas preguntas.

¿Alguien está trabajando activamente para resolver el impedimento? Tal vez no se pueda resolver dentro del Equipo Scrum y tal vez no se pueda resolver en un Sprint, pero ¿qué se está haciendo para minimizar su impacto y, en última instancia, resolver los problemas subyacentes?

Durante la planificación del Sprint, ¿las personas son conscientes de estos impedimentos y, si lo son, por qué se incorpora al Sprint trabajo que probablemente se verá obstaculizado? Si el trabajo es de tan alto valor que realmente es el próximo trabajo que se debe hacer, entonces tal vez se deba dedicar más esfuerzo o recursos para manejar el impedimento. De lo contrario, tal vez el trabajo deba posponerse: el trabajo iniciado pero sin terminar es un desperdicio, entonces, ¿por qué introduciría desperdicios a sabiendas en su proceso de desarrollo?

Parece incorrecto prohibir que se discutan ciertos temas. Pero también es incorrecto no trabajar para resolver estos impedimentos y es incorrecto agregar a sabiendas trabajo que se verá obstaculizado.