Uno de los diferenciadores clave de Kanban es su enfoque en los procesos y no en las personas. Por ello, Kanban no prescribe roles formales. Su primer principio es "Empezar con lo que haces ahora", lo que incluye respetar los roles, responsabilidades y títulos de trabajo existentes. Sin embargo, con el tiempo, suelen emerger ciertas responsabilidades clave.
7.1. Diferencias con Scrum (no existen roles formales)
Es fundamental entender que Kanban no tiene equivalentes directos a los roles de Scrum:
- No hay un Product Owner: La responsabilidad de priorizar el trabajo puede recaer en un comité, un jefe de producto o el propio equipo.
- No hay un Scrum Master: Las funciones de facilitar reuniones, eliminar impedimentos y promover el método son una responsabilidad compartida, aunque a menudo un "coach" o un gestor asume parte de esta carga.
- No hay un Equipo de Desarrollo como una unidad formal con un conjunto específico de responsabilidades. El "equipo" en Kanban es simplemente el grupo de personas que colabora para mover el trabajo a través del flujo.
Kanban se superpone a la estructura existente, buscando optimizarla, no reemplazarla. La idea no es cambiar quién hace qué, sino cómo fluye el trabajo a través de las personas y sus funciones actuales.
7.2. Propietario del flujo o Service Delivery Manager (SDM)
Aunque no es un rol formal, la responsabilidad de velar por el flujo de trabajo a menudo recae en una persona que actúa como Service Delivery Manager. Esta persona se preocupa por la eficiencia y la efectividad del proceso Kanban.
- Responsabilidades: Su foco principal es la entrega de valor al cliente. Se encarga de monitorizar el flujo, identificar cuellos de botella y otros impedimentos, y asegurar que el equipo los resuelva.
- Facilitador: Generalmente, facilita la reunión de Revisión del Flujo (Service Delivery Review), donde se analizan las métricas del sistema para identificar oportunidades de mejora.
- Enfoque: Su lema es "mejorar el sistema". No gestiona a las personas, sino que ayuda al equipo a gestionar el flujo de trabajo de manera más eficaz.
7.3. Coach de mejora o Service Request Manager (SRM)
Otra responsabilidad que suele surgir es la del Service Request Manager. Esta figura se centra en la parte inicial del tablero, gestionando la demanda y las expectativas de los clientes o stakeholders.
- Responsabilidades: Ayuda a los stakeholders a definir y priorizar las solicitudes de trabajo antes de que el equipo se comprometa a realizarlas. Es el guardián de la entrada al sistema (el "Backlog").
- Comunicación: Actúa como un punto de contacto principal para los clientes, comunicando el estado del trabajo y gestionando las expectativas sobre cuándo se podría atender una nueva solicitud.
- Enfoque: Su objetivo es asegurar que el equipo trabaje en las cosas correctas y que el sistema no se vea desbordado por un exceso de demanda o por peticiones poco claras.
7.4. Responsabilidad compartida del equipo
Más allá de cualquier rol emergente, el principio más importante en Kanban es la propiedad colectiva. Todo el equipo es dueño del tablero y del proceso.
- Gestión del flujo: Cualquier miembro del equipo puede y debe tomar la iniciativa para mover una tarjeta, señalar un bloqueo o proponer una mejora en el tablero.
- "Stop starting, start finishing": Cuando una columna alcanza su límite WIP, la responsabilidad del equipo es colaborar para descongestionar esa etapa antes de empezar trabajo nuevo. Si los testers están sobrecargados, los desarrolladores deben ayudar, ya sea probando, automatizando tests o resolviendo dudas.
- Mejora continua: Todo el equipo participa en las retrospectivas y contribuye a la evolución del sistema Kanban. La mejora del proceso no es tarea de un solo "coach", sino un compromiso de todos.
Esta cultura de responsabilidad compartida es lo que permite a los equipos Kanban ser ágiles, flexibles y resilientes ante los problemas.