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.
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 - Elija bien el momento en el que se tratan las dependencias. No espere a la reunión diaria para ello.
¿Y si tengo más especialistas en mi equipo?
Puede crear otros formatos de tablero (pentágonos, hexágonos etc.), pero tenga mucho cuidado con tanta especialización en el equipo. Recuerde la Ley de Brooks. La cantidad de interconexiones de comunicación es una explosión combinatoria dada por la fórmula:
Ley de Brooks
Trayendo una imagen:
Ejemplificando la Ley de Brooks
Con cada nudo de especialista que crea en el equipo, aumentas un overhead de comunicación, aumenta el coste de coordinación, aumenta la complejidad del handoff de historias y dificulta prácticas ágiles importantes como limitación de WIP (Work in Progress, trabajo en proceso) y Swarming.
