Los grandes desconocido del Método Kanban: roles y eventos

Empecé con Kanban hace 4 años a raíz  de que un equipo de mantenimiento de sistemas internos me pidió ayuda. Me estudié el blue book y lo utilicé de referencia. El blue book lo escribió David Andersson hace más de diez años para mostrar el Método Kanban (la aplicación de sistemas kanban industriales al mundo del conocimiento). En este tiempo ha ido evolucionando el Método Kanban incorporando nuevas prácticas y nuevos roles y eventos. Dado que durante los siguientes años he acompañado a pocos equipos Kanban, no me he ido a actualizado. El año pasado, impartiendo una formación básica, un compañero me hizo la siguiente pregunta: He leído que en el Método Kanban hay siete eventos y dos roles, ¿sabes algo? En aquel momento me quedé “pillado” y pensé “tengo que investigar esto… ya me pasó con Scrum”.

La pregunta es: ¿Eventos y Roles en el Método Kanban? Técnicamente podemos decir que sí. Aunque, si no los tienes al empezar a implantarlo no te preocupes. El Método Kanban utiliza la filosofía de empezar por dónde te encuentres actualmente, y usar una evolución continua para hacer una implantación segura. Esto es diferente respecto a Scrum que defiende más “o haces todo o no eres Scrum”, y debes tener un Product Owner y un Scrum Master antes de poder hacer Scrum. ¡Minipunto para el Método Kanban!  

¿Qué roles hay en Kanban?

Cualquiera que se dedique o haya dedicado a implantar Scrum en una organización sin experiencia, sabe que suele haber problemas al introducir los roles: ¿Qué hace un Product Owner? ¿El Scrum Master es un Jefe de Proyectos ágil? Estos roles no existen en las organizaciones actuales, lo que provoca un cambio organizacional y nos dificulta la implantación de Scrum. El Método Kanban sin embargo, no prefija ninguno rol. Deja que los propios equipos se organicen en torno al trabajo y que ellos mismos sean los que consigan que el trabajo fluya.  

Pero, durante estos años desde que se publica el método Kanban, David Anderson y todo el equipo de la Lean Kanban University, han descubierto que muchos equipos acaban por necesitar dos roles para poder ser más efectivos. Puedes aplicar el Método Kanban sin tenerlos, pero a muchos equipos les funciona el tenerlo.

El primero de estos roles no tiene nombre oficial porque no se prescribe pero se le conoce como Flow Master o Service Delivery Manager. Esta figura se encarga de ayudar al equipo de trabajo a que las tareas fluyan a lo largo del tablero de manera sostenida en el tiempo. Su misión no es coordinar al equipo o asignar tareas, sino de jugar un papel de observador y facilitador para que los equipos tomen decisiones y el sistema funcione. Podemos ver correlación con el Scrum Master, pero en Kanban no se define exactamente sus tareas como si lo haces tú Scrum.

En mi opinión, cuando apostamos por un método o framework que promueve la autoorganización de las personas, necesitamos un rol de este estilo. La autoorganización es algo que no tenemos entrenado y se tarda un tiempo en aprender a trabajar de esta manera. Por eso este tipo de roles ayudan mucho a las organizaciones que apuestan por la autoorganización de los equipos.

El otro rol detectado por el Método Kanban es el que se suele llamar Service Request Manager o Product Manager (incluso Product Owner). Al ser una figura que se focaliza en la demanda, se asemeja con el Product Owner de Scrum. Una vez más, en Scrum tiene sus funciones mucho más definidas. Poner orden en las peticiones, gestionar la demanda, trabajar las expectativas con los diferentes interesados o definir políticas de priorización pueden ser algunas de sus funciones.

Una vez acompañé a un equipo que daba servicio a una compañía donde tenían equipos distribuidos en cuatro países y donde cada uno de esos países disponía de tres personas que podrían hacer peticiones al equipo. Empezamos a ver choques de intereses entre las personas, y solicitamos una persona que centraliza todas las peticiones y que nos ayudará a decidir qué era lo que había que hacer en cada momento. A pesar de no tener tanta experiencia en Kanban, nosotros también detectamos la necesidad de este rol.

¿Eventos?

Una de las prácticas del Método Kanban es el la utilización de feedback loops o circuitos de retroalimentación. Si queremos que haya mejora contínua tenemos que reservar espacios en los que podamos tener conversaciones sobre diferentes aspectos del sistema y del servicio que prestamos. Inicialmente el blue book sólo recomendaba dos eventos en el Método Kanban: la daily y la retrospectiva. Hoy en día se han definido siete eventos. Cada cuánto tiempo debemos hacerlos depende del contexto. Esto se conoce como “cadencia”.

El primero de ellos es la reunión diaria o daily stand up meeting. Este evento se centra principalmente en bloqueos, dependencias y cualquier cosa que haga que nuestro trabajo no fluya. Recordemos que el objetivo de un equipo que usa el Método Kanban es que el trabajo fluya y no hablar de lo que hace cada miembro. Las conversaciones deben centrarse en todo lo que nos impida que el trabajo fluya.

El segundo evento es el Replenishment. Durante este evento, el equipo de trabajo y el  Service Request Manager lo utilizan para decidir qué es lo próximo que va a pasar el punto de compromiso. Este punto de compromiso es el momento en el que el trabajo debe realizarse y es donde empezaremos a medir el tiempo de respuesta del propio equipo.Tiene cierta similitud con la Sprint Planning aunque difieren en el nivel de profundidad y detalle.

El siguiente evento es el de Service Delivery Planning donde estudiamos la entrega del trabajo finalizado. En ocasiones, una vez terminadas las tareas, se quedan en espera de entrar al siguiente equipo o despliegue en producción. Por tanto, este evento nos ayuda a definir cómo va a ser esa entrega y cuándo la vamos a realizar. Este evento podría llegar a ser prescindible si tenemos una entrega continua, o desde luego duraría menos ya que solo hablaríamos sobre la efectividad de la entrega.  

El cuarto evento es el Service Delivery Review donde evaluamos el servicio que estamos prestando. Análogo a la retrospectiva de Scrum, no nos centramos tanto en las personas y en sus relaciones, sino que  ponemos el foco en el propio servicio. ¿Estamos siendo capaces de entregar? ¿Estamos siendo capaces de dar un buen servicio? ¿Estamos cumpliendo con los compromisos que tenemos con los clientes? El foco es evaluar el propio servicio en sí, aunque es cierto que en ese servicio participan personas y sus relaciones son relevantes.  Quizás Scrum sí que le da más relevante a que hablemos de las relaciones entre las personas de lo que el Método Kanban propone.

Los siguientes tres eventos no tienen una correlación directa con Scrum. Podemos decir que son parte del trabajo del Product Owner ya que esta figura se encarga del Product Management. En Scrum estos eventos se podrían hacer, sin embargo, no están prescritos en la guía Scrum.

El quinto evento es la Strategy Review. Cómo su nombre indica estudiamos la estrategia de nuestro sistema y lo contrastamos con la de la organización. Tratamos es ver si estamos siguiendo la estrategia marcada y si estamos bien alineados. Con todo ello podremos tomar decisiones. Recordemos que uno de los Principios del Método Kanban es el propósito para dar servicio. Tenemos que revisar nuestro propósito para saber  si damos buen servicio.

Otro evento es el llamado Operations Review. Este evento nos ayuda cuando utilizamos el Método Kanban en varios sistemas que se relacionan. Juntamos a los diferentes sistemas que interaccionan entre sí de cara a evaluar la operación completa. ¿Somos capaces de hacer fluir el trabajo entren los diferentes sistemas? Algunas personas pueden comparar este evento con una especie de escalado. Podemos decir que en parte sí, porque el escalado en Kanban consiste en tener más equipos realizando el Método y no tanto creando una jerarquía.

Por último, tenemos el evento de Risk Review. En este evento evaluamos los diferentes riesgos que atacan el sistema o sistemas circundantes.Cuando conocía la existencia de este evento me llamó mucho la atención. Es curioso como en Scrum no existe una gestión de riesgos prescrita. Aún así, creo que un buen Product Owner debería incorporarlo en su kit de funciones. El Método Kanban sin embargo, sí ha considerado la existencia de un evento en el cual trabajamos los riesgos de nuestro sistema y cómo podemos tomar acciones de cara a proteger al mismo de esos riesgos. Por ejemplo, si nuestro sistema da servicio a un negocio que no es constante a lo largo del año, sino que en ciertos momentos tienen picos de trabajo, eso tenemos que ser capaces de preverlo. Un ejemplo muy típico es el mundo retail donde hay periodos especiales  (como las rebajas o el black friday) y sufren picos de necesidades y en otros periodos quizás la demanda sea baja. 

Todos estos eventos  están entrelazados y de alguna manera unos se alimentan de otros. Tenemos un equipo o un sistema que se dedica a entregar trabajo y un montón de cadencias de oportunidades para reunirnos y tener conversaciones con los diferentes puntos importantes para el sistema: riesgos, operaciones, cómo estamos trabajando diariamente… Recuerda que el Método Kanban intenta implantar poco a poco e ir introduciendo estos eventos a medida que vayan siendo necesarios y a medida que vayamos profundizando en la implantación del Método Kanban de la organización.

Y tú… ¿Cuál de estos roles y eventos tienes en tu sistema Kanban?