¿Cómo hacer que los equipos Scrum autogestionen sus dependencias?

Para productos que requieran varios equipos trabajando en paralelo es necesario gestionar las dependencias entre las historias de usuario y los trabajos que realizan los mismos.

La pila de producto de este tipo de proyectos grandes suele tener suficientes epics e historias de usuario con un alto grado de certidumbre que permiten planificar varios sprints. Con el nivel de granularidad que tienen seguramente presenten pocas dependencias entre si, hecho muy deseable ya que eso permite gestionar la pila de producto más fácilmente. Pero cuando llega el momento de la planificación de release o la planificación de sprint, cuando se realiza la descomposición en historias más pequeñas en el último momento responsable, es cuando aparecen las dependencias.

Tratándose de planificaciones con equipos trabajando en paralelo, son necesarios eventos tipo PI Planning de SAFe, Townhall o The Big Room de Mike Cohn. En este tipo de eventos están presentes todos los equipos y es donde estos planifican de forma conjunta la próxima release o los próximos sprints.

Tablero de release con las dependencias visibles

Cada equipo elige una serie de epics y/o historias de usuario de un tablero con la parte prioritaria de la pila de producto a construir, y luego los descompone junto con el Propietario del Producto en historias de usuario estimables y acometibles en sprints. Estas las planifican para los próximos sprints identificando riesgos y resolviendo dependencias inter-equipos de forma verbal negociando con los equipos involucrados.

Cuando se identifica una dependencia uno de los miembros trata con el equipo que va a construir la historia de la que son dependientes y se pone de acuerdo con este para que ambos planifiquen las dos historias dependientes en sprints secuenciales. De esta forma el equipo con la historia con dependencias da prioridad a la misma y toma el compromiso de finalizarla en el sprint planificado.

Ejemplo de un tablero de un tren (Agile Release Train)

Finalmente los equipos trasladan sus historias planificadas a un tablero de release y hacen visibles las dependencias resueltas mediante colores y cuerdas entre historias. En la imagen del ejemplo de arriba las historias naranjas son historias con dependencias hacia ellas, y las amarillas historias de las que no depende ninguna.

Es muy importante que cuando se refleje una dependencia en el tablero mediante la cuerda y los post-its correspondientes estén presentes los miembros, o al menos uno, de ambos equipos, ya que establecer una dependencia de forma unilateral hace que no se establezca el compromiso necesario del equipo que no está presente. La regla a seguir es que solo un miembro del equipo puede colocar una historia de usuario en el carril de su equipo.

Los tableros con dependencias resueltas son unos de esos artefactos que una vez obtenido, y en este caso visibilizadas las dependencias, arranca expresiones de sorpresa como "¡Ostras, esto no lo sabia!".