Una de las primeras preguntas que surgen al adoptar Kanban en un equipo es: ¿quién hace qué? Kanban es intencionalmente no prescriptivo respecto a la estructura organizativa — no dicta cómo deben llamarse los puestos ni cuántas personas debe haber en el equipo. Sin embargo, el método Kanban sí reconoce dos responsabilidades funcionales que, si se cubren bien, marcan la diferencia en la calidad del servicio.
01 · El punto de partidaPor qué Kanban no prescribe roles fijos.
El método Kanban, formalizado por David Anderson, parte de un principio fundamental: empieza con lo que tienes. Esto significa que no se impone ninguna reorganización estructural. Los roles, títulos y jerarquías existentes permanecen intactos al comenzar con Kanban.
Esta filosofía contrasta con frameworks como Scrum, que establece exactamente tres roles: Product Owner, Scrum Master y Developers. Kanban asume que la organización ya tiene sus propias estructuras y que Kanban se superpone a ellas para mejorar el flujo, no para reemplazarlas.
Sin embargo, con la experiencia en múltiples organizaciones, el método Kanban ha identificado dos áreas de responsabilidad que aparecen de forma natural en los sistemas Kanban que funcionan bien. Estas responsabilidades reciben el nombre de Service Request Manager y Service Delivery Manager.
02 · Primer rolEl Service Request Manager.
El Service Request Manager (SRM) es la persona responsable de gestionar las peticiones que entran al sistema. Su foco está en el lado de la demanda: entiende qué quieren los clientes, prioriza las peticiones según el valor y el riesgo, y decide qué entra al sistema y cuándo.
Las responsabilidades principales del Service Request Manager incluyen:
- Gestionar y ordenar el backlog de peticiones entrantes.
- Comunicarse con los clientes y stakeholders para entender sus necesidades.
- Evaluar el valor y la urgencia de cada petición usando herramientas como el Cost of Delay.
- Decidir qué ítems tienen prioridad cuando el sistema tiene capacidad disponible.
- Asegurarse de que los ítems que entran al sistema están suficientemente bien definidos para ser procesados.
Si buscas una analogía con Scrum, el Service Request Manager tiene similitudes con el Product Owner en lo que respecta a la gestión de la demanda. Sin embargo, en Kanban esta responsabilidad no implica necesariamente una única persona — puede distribuirse entre varias, dependiendo del contexto.
La gestión de las peticiones es tan importante como la ejecución del trabajo. Sin una buena gestión de la demanda, el sistema siempre estará sobrecargado.— Principio del método Kanban
03 · Segundo rolEl Service Delivery Manager.
El Service Delivery Manager (SDM) es la persona responsable de que el flujo de trabajo a través del sistema sea lo más suave y eficiente posible. Su foco está en el lado de la entrega: observa el tablero, identifica bloqueos, gestiona las dependencias y toma medidas para que el trabajo fluya.
Las responsabilidades principales del Service Delivery Manager incluyen:
- Monitorizar el flujo de trabajo en el tablero Kanban.
- Identificar y resolver bloqueos que impiden que el trabajo avance.
- Gestionar las dependencias entre ítems o entre equipos.
- Facilitar las reuniones del equipo como el Daily Kanban y las revisiones de flujo.
- Recopilar y analizar métricas de flujo: lead time, cycle time, throughput.
- Proponer mejoras al sistema Kanban basándose en los datos.
La analogía más cercana en Scrum sería el Scrum Master, aunque el SDM tiene un enfoque más operativo en el día a día del flujo. Mientras el Scrum Master facilita el proceso Scrum, el SDM gestiona activamente el flujo de trabajo.
04 · La práctica¿Una persona puede asumir ambos roles?
En equipos pequeños es habitual que una sola persona asuma ambas responsabilidades — o incluso que se distribuyan entre todos los miembros del equipo de forma rotativa. En equipos más grandes o con flujos complejos, tener personas dedicadas a cada responsabilidad mejora la calidad de la gestión.
Lo importante no es el título — es que ambas responsabilidades estén cubiertas. Si nadie gestiona activamente las peticiones entrantes, el sistema se sobrecarga. Si nadie monitoriza el flujo, los bloqueos se acumulan en silencio. Kanban deja la libertad de resolver esto como mejor convenga a cada organización.
05 · La confusión habitualRoles Kanban vs. títulos organizativos.
Una confusión frecuente es identificar directamente los roles Kanban con títulos organizativos específicos. El Service Request Manager no es necesariamente el Product Manager, ni el Service Delivery Manager es el Team Lead. Son responsabilidades funcionales que pueden recaer en personas con cualquier título.
En la práctica, lo que define quién asume cada responsabilidad es el contexto del equipo, la estructura organizativa existente y, sobre todo, quién tiene la visibilidad y la autoridad para tomar las decisiones correspondientes. Kanban simplemente da nombre a estas responsabilidades para que el equipo pueda hablar de ellas con claridad.