Evitar decisiones asteroides en Scrum

¿Alguna vez ha tenido la experiencia de que una decisión tomada en una reunión es después rechazada en una reunión diferente? ¿O tal vez usted ha asistido a un larga reunión para debatir una cuestión importante sólo para descubrir después que la verdadera decisión se tomó más tarde en la semana por un equipo diferente? Ambas experiencias son lo que yo llamo “decisiones asteroides”.

Para aquellos que no esténn familiarizados, asteroids era un juego arcade clásico de finales de 1970 \ principios de 1980. Fue el primer videojuego con el que jugué y si está interesado puede jugar aquí online. El objetivo era volar el espacio profundo en un pequeño cohete triangular con el fin de hacer estallar a todas las rocas (asteroides) y evitar una colisión con otros asteroides y un platillo volador. Lo que hizo que el juego fuera divertido fue poder estallar un asteroide, que se convertía entonces en dos o tres asteroides más pequeños que luego había que evitar … y la partida se ponía más rápida en los niveles superiores.

Cuando Scrum es un solo equipo trabajando en un solo Product Backlog, la toma de decisiones es bastante sencilla y las decisiones asteroides son fáciles de evitar. Sin embargo, no puedo pensar en ningún proyecto de software no trivial que no incluya múltiples equipos, y cuando varios equipos están trabajando en el mismo producto, tenemos más decisiones para coordinar. Para un proyecto gestionado tradicionalmente, es la responsabilidad del director del proyecto de finalizar las decisiones y evitar colisiones. No es de extrañar que el ser un jefe de proyecto sea tan estresante – cientos de decisiones deben tomarse y gestionarse durante la vida del proyecto.

Con Scrum y proyectos ágiles, empujamos la autoridad para tomar decisiones a los miembros del equipo. Debido a que cada miembro del equipo tiene autonomía para tomar decisiones sobre su trabajo, también hay que tener en cuenta el impacto de sus decisiones sobre los demás. Una vez más, para el caso simple de un solo equipo de trabajo en un solo Product Backlog, no hay una gran cantidad de complejidad y coordinación que gestionar. Sin embargo, los equipos de Scrum luchan con regularidad para evitar estas colisiones. Es una buena cosa que los equipos de Scrum tienen el Scrum Diario y su calendario fijo para ayudar a los miembros del equipo a evitar decisiones asteroides.

¿Pero lo que sucede a los equipos Scrum en los casos no triviales? ¿Limitamos simplemente la autoridad de un miembro del equipo en su toma de decisiones y dejamos a los jefes de equipo (o managers funcionales) que tomen todas las decisiones importantes? ¿O tal vez se trata de un buen trabajo para un ScrumMaster – gestionar y coordinar todas las decisiones para asegurar que no hay colisiones entre los equipos? ¡¡Por supuesto que no!! Esto es, básicamente, ir de nuevo a la vieja forma de trabajar y tirar a la basura todas las ventajas de los equipos de auto-organización.

A Jeff Sutherland le gusta decir que todo lo que necesita para escalar Scrum está integrado en el marco. A menudo habla de que cómo varios equipos de Scrum trabajan juntos es algo parecido a esos robots araña de seis patas autónomas, que aprenden a caminar por primera vez. Necesitan un conjunto de reglas simples para asegurar que puedan auto-organizar la conducta de sus patas y que la interacción de cada pierna trabaje al unísono con los otras. Desafortunadamente, Scrum no ofrece un conjunto de reglas para ayudar a evitar colisiones de equipo. Eso sería demasiado fácil y reducir la capacidad de una organización de auto-organizarse.

Entonces, ¿hay un kit de inicio que podemos utilizar con respecto a la toma de decisiones y empezar desde ahí? Pues resulta que, Mike Dwyer (@MikeD999) ofreció este conjunto de ensayos de fácil uso en la lista de correo CST que podría ser beneficioso para Scrum Equipos. En lugar de volver a inventar la rueda, pensé que podría compartirlo con ustedes.

1. Todos los equipos de Scrum deben respetar las prioridades de los otros equipos y pedir lo mismo a cambio. Puesto que cada equipo está interconectado, tiene sentido que busquemos soluciones buenas para ambas partes.
2. El propósito de todas las reuniones celebradas por equipos de Scrum es tomar decisiones que los muevan más cerca del resultado deseado que está frente a ellos, es decir, las reuniones terminan en acción, no análisis. No se utilizan las reuniones como una manera de llamar la atención sobre lo listo que eres.
3. Cualquier persona que participe en una reunión con un equipo de Scrum debe estar facultada para tomar una decisión para la cual tendrá el apoyo de su organización. Es crucial que los otros equipos envíen a la persona adecuada para una reunión, de otro modo se quedan sin tomar decisiones .

Si bien nuestro objetivo con esta heurística es tomar decisiones oportunas con personas que toman decisiones pertinentes e invertidas, con el fin de evitar las decisiones de asteroides, no debemos forzar una decisión antes de estar listos. En los casos en los que tenemos prioridades en conflicto o que las personas que deben tomar las decisiones no se puede llegar a un consenso, nuestra posición por defecto debería ser la de pasar a un experimento de caja de tiempo para recopilar datos en colaboración con nuestros compañeros y buscar retroalimentación para refinar nuestra comprensión.

Cuando tenemos datos del experimento, el resultado normalmente es claro y evidente. Y si eso no funciona, siempre podemos tomar una pequeña decisión que nos mueve hacia adelante y podemos volver a visitar, recorrer o refactorizar esa decisión después.