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 End 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 tablero kanban no traducía las dependencias y la historia no avanzaba. Proponemos entonces un tablero diferente.

El tablero 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 post-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 tablero».

La siguiente figura presenta el tablero rellenado.

Silos

El tablero 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 tablero. La Historia de Usuario estará lista cuando todo el tablero 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 tablero), 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 la reunión diaria para ello.

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

Puedes crear otros formatos de tablero (pentágonos, hexágonos etc.), pero ten mucho cuidado con tanta especialización en el equipo. Recuerda la Ley de Brooks. 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 Ley de Brooks

Ejemplificando la Ley 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 *