domingo, 3 de enero de 2016

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

En productos que requieren varios equipos trabajando en paralelo es necesario gestionar las dependencias entre 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, en el último momento responsable, cuando se realiza la descomposición en historias más pequeñases cuando aparecen las dependencias.

Tratándose de planificaciones con equipos trabajando en paralelo son necesarios eventos tipo Release Planning de SAFe o The Big Room de Mike Cohn. Este tipo de eventos son eventos en que están presentes todos los equipos y en que 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 de 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 busca 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.

Finalmente los equipos trasladan sus historias planificadas a un tablero de release y hacen visibles las dependencias 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 establezca una dependencia con una cuerda 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 otro equipo.

No hay comentarios:

Publicar un comentario