Silos: visualizando y resolviendo las dependencias del equipo

 
Silos

Recientemente, mientras estábamos facilitando un EVDnC, uno de los equipos tenía dificultades para decidir qué tareas debía realizar quién y cuáles de ellas debían hacerse en conjunto. Continuamente surgía algo como: «pero yo no sabía que tú necesitabas eso», «yo me puse a esperar que el Back en hiciese tal cosa y ellos ni lo miraron», «Tengo algunas dependencias en relación a ti, pero aún no te lo he dicho». Mucho debate y poca armonización.

Era un equipo con las siguientes especialidades: Experiencia de Usuario (UX) e Interfaz de Usuario (UI), Back end, Front end y Quality Assurance (QA). El marco Kanban no traducía las dependencias y la historia no avanzaba. Proponemos entonces un marco diferente.

El marco de dependencias

Utilizando una hoja de Flipchart, ponemos un círculo para cada especialidad en su hueco.

A continuación, trazamos líneas que enlacen cada especialidad.

Cogemos la historia de usuario más prioritaria del Product Backlog, la que estaba provocando mucho debate y proponemos el siguiente reto: Por favor, poned en pos-it todas las tareas técnicas que cada especialista necesita hacer para que la historia cumpla nuestra Definición de Hecho (Definition of Done). Cada especialidad tiene su color de pos-it.

Las tareas que dependen del especialista y solo del especialista quedan dentro del círculo. Todas las tareas que dependen del trabajo en conjunto con otro especialista deben quedar en línea de salida. Cualquier tarea que dependa de 3 o más especialistas debe permanecer en el centro del marco.

La siguiente Figura presenta el marco rellenado.

Silos

El marco de dependencias

La lectura que podemos hacer de ella es:

  • UX/UI tiene 2 tareas y no dependen de nadie;
  • El Front end tiene 6 tareas, 2 dependen de la UX/UI y 1 depende del Back end;
  • El Back end tiene también 6 tareas, 1 depende del UX/UI;
  • El QA tiene 5 tareas, 1 depende del Back end y 1 depende de todos los demás.

Los movimientos

Cuando la dependencia desaparezca, la tarea se podrá mover dentro del círculo del especialista.

Cuando la tarea concluya, debe ser retirada del cuadro. La Historia de Usuario estará lista cuando todo el cuadro esté vacío.

Las tareas pueden surgir a lo largo del desarrollo o el equipo puede descubrir alguna dependencia. Sin embargo, es necesario tener cuidado y evitar que eso se vuelva un bastón para la planificación apresurada y mal hecha. Las nuevas dependencias siempre deben comunicarse y combinarse entre las partes.

Acuerdos

Son necesarios algunos acuerdos
1 – Debemos procurar resolver primero las dependencias mayores (centro del marco), después las dependencias menores (rectas), y por último las tareas de los especialistas (dentro del círculo.
2 – No puedo atribuir una tarea a otra persona. Puedo indicar la dependencia, pero no escribo post-its de colores que no son de mi especialidad.
3 – Combine bien el momento en el que las dependencias se tratan. No esperes al Daily Meeting para ello.

¿Y si tengo más especialistas en mi equipo?

Puedes crear otros formatos de marco (pentágonos, hexágonos, etc.), pero ten mucho cuidado con tanta especialización en el equipo. Recuerda la Ley de Brook. La cantidad de interconexiones de comunicación es una explosión combinatoria dada por la fórmula.

Ley de BrooksLey de Brooks

Trayendo una imagen

Ejemplificando la Lay de Brooks

Ejemplificando la Lay de Brooks

Con cada nudo de especialista que creas en el equipo, aumentas un overhead de comunicación, aumentas el coste de coordinación, aumentas la complejidad del handoff de historias y dificultas prácticas ágiles importantes como limitación de WIP (Work in Progress, trabajo en proceso) y Swarming.

 

«

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *