1. Introducción
Durante los últimos años me he dedicado a ayudar a numerosas empresas a implantar el Método Kanban, esto me ha proporcionado experiencia y me ha curtido sobre los problemas que se dan durante este proceso y que nadie suele tener en cuenta porque surgen de situaciones reales, cotidianas que ningún curso te llega a enseñar.
Es por ello, que hoy os vengo a hablar desde mi experiencia personal de un tema bastante doloroso en la Transformación Digital de las organizaciones: la Gestión de Bloqueos con Kanban.
Cuando trabajas con el Método Kanban en un equipo, siempre tarde o temprano y por cualquier razón aparecen los bloqueos. Para los equipos de hecho cualquier cosa que les impida trabajar es un bloqueo. ¡ERROR!
En este momento, tanto como si eres un Coach o un Team Kanban Practitioner, tu misión es dejar claro qué es un bloqueo y qué no. Así como lo que implica tener un bloqueo a tener un elemento restringiendo el flujo de trabajo.
Empecemos con lo que se suele considerar bloqueo y NO lo es:
- Un cuello de botella (bottleneck) NO es un bloqueo. Un cuello de botella restringe y limita el trabajo en curso. Los cuellos de botella pueden ser de dos tipos y en ningún caso son bloqueos:
- Los hay de capacidad limitada, aquellos que te impiden hacer más trabajo. La limitación del WIP impuesta.
- Y de disponibilidad no instantánea. Capacidad limitada debido a la disponibilidad limitada.
- Retrasos o impedimentos debido a Bugs. Tu falta de empirismo programando o estimando no es un Bloqueo.
Vamos a utilizar una metáfora para entender la diferencia de lo que es un Bloqueo de lo que no.
Imagina que has comprado una vivienda de dos plantas de segunda mano y al par de semanas de vivir allí surgen numerosos problemas con las cañerías de la vivienda. Has detectado que en la planta superior el agua caliente llega de forma muy limitada o en poca cantidad y en la planta baja hay grifos que no funcionan.
Al llamar al fontanero y éste hacer un estudio, determina que el motivo de que el agua caliente llegue de forma tan limitada a la planta superior se debe al tipo de cañería y su grosor, lo cual no permite más caudal (esto sería nuestro cuello de botella de capacidad limitada).
En cuanto a los grifos de la planta baja, nos indica que han estado tanto tiempo sin uso que se ha generado un tapón de suciedad que impide el paso del agua y es necesario usar un ácido para limpiarlas (impide el paso del agua, este sería nuestro bloqueo).
Para terminar el fontanero le indica que no puede desatascar los grifos a la vez porque la cantidad de ácido en las cañerías para su limpieza por seguridad está limitado. (este sería el cuello de botella de disponibilidad no instantánea).
Decides que no vas a esperar al lunes y tú mismo intentas arreglar la grifería, destrozando una de las válvulas y teniendo que llamar de nuevo al fontanero (retrasos e impedimentos).
En definitiva, un bloqueo es un tipo de impedimento que no puede resolver internamente el equipo y que interrumpe el flujo de trabajo.
2. ¿Por qué hay que saber distinguir cuellos de botella de bloqueos?
Porque cada cual conlleva un pensamiento diferente a la hora de resolver el problema. Los Bloqueos deben ser vistos como aquellas variaciones de causa especial en nuestro flujo de trabajo.
Los ítems bloqueados requieren que la organización desarrolle la capacidad para la gestión y resolución de problemas para restaurar el flujo lo más rápido posible. De igual modo debe desarrollar la capacidad para analizar la causa principal y resolverla para prevenir la recurrencia.
3.Gestionando los Bloqueos
Ahora que sabemos identificar un bloqueo necesitamos visualizarlo en el panel kanban. Por convención se recomienda el uso de post it rosas que se colocan encima del ítem bloqueado.
Conviene aclarar que un ítem bloqueado consume WIP o de lo contrario no se abordará el problema hasta que sea quizás demasiado tarde. Los bloqueos no se resuelven poniéndonos a trabajar en otra cosa.
La experiencia me ha mostrado que luego de conocer los bloqueos se suele dar otro problema: No basta con decir que un ítem está bloqueado, ya que esto no conduce a que el equipo desarrolle las capacidades lo suficientemente sólidas como para desbloquearlo.
Lo que debemos hacer es: a este nuevo ítem se le va a llamar Issue, este nuevo elemento debe tener un número de seguimiento asignado, así como un miembro del equipo asignado (generalmente el Team Leader o Jefe de Proyecto) para asegurarse la resolución. Entraremos más en detalle aquí en la sección 4. Monitorización y reporting de bloqueos.
Algunos ejemplos típicos de bloqueos son:
- Requerimos una persona experta para dar resolución a una ambigüedad en los requisitos y no está disponible
- Necesitamos configurar un entorno y el ingeniero encargado de tal acción está ausente.
- Solicitamos un especialista en Bases de Datos para trabajar con un ítem pero este se encuentra ausente por vacaciones.
El mejor momento en Kanban para discutir y poner foco en los bloqueos se da en la Kanban Meeting (Daily). En ella el equipo debe centrarse en tratar de conocer los bloqueos y en el progreso realizado en su resolución. Las preguntas típicas de una Kanban Meeting deben ser:
- ¿Quién está trabajando en resolver la Issue ###?
- ¿Cuál es el estado de la resolución de la Issue ###?
- ¿Necesita la Issue ### ser escalada?
- ¿A quién?
Un equipo con un buen nivel de madurez será aquel en el que los miembros del equipo se muestran voluntarios en ayudar a la resolución de las Issues.
En otras situaciones donde este nivel de madurez no es tan evidente o aún está emergiendo, será el Jefe de Proyecto el que quizás tenga que asignar miembros del equipo para trabajar en la resolución de las Issues.
4. Monitorización y reporting de bloqueos
Como otros ítems los Issues deben ser monitorizados. Dicha monitorización debe incluir fecha de inicio y fecha de fin así como un enlace a todos los ítems afectados.
Hasta ahora hemos hecho referencia al tablero kanban físico pero, ¿qué ocurre con las herramientas digitales?
Sea cual sea la herramienta digital que se utilice para hacer la monitorización de los bloqueos, debe permitir esta monitorización o bien ser lo suficientemente personalizable como para que nosotros la podamos crear.
Como ya se mencionó anteriormente para los Issues utilizaremos los post it rosas con los siguientes campos:
- Fecha de Inicio y Fin
- Miembro del equipo asignado
- Descripción del problema
- Enlaces a los ítems afectados (bloqueados)
Otros campos que se podrían emplear y que nos aportan diferentes fuentes de información son:
- Histórico del esfuerzo realizado hasta su resolución
- Histórico de todos los individuos asignados
- Vía de escalado
- Tiempo estimado de resolución
- Evaluación del impacto
- Soluciones para atajar el problema de raíz y prevenir futuros fallos.
Aunque mostrar los Issues con post its rosas nos proporcionan un gran impacto visual y podemos determinar cuántos ítems se encuentran bloqueados al momento, resulta también útil el hacerles un seguimiento y reporting.
Un Diagrama de Flujo Acumulado de los Issues e ítems bloqueados nos proporcionan un gran indicador de las capacidades de la organización en la gestión y resolución de los Issues.
La organización debe ser consciente del impacto que los Issues pueden generar. Esta conciencia debe permitir tomar decisiones sobre las oportunidades de mejora y los posibles beneficios de invertir en reparar los problemas de raíz para prevenir posibles variaciones de ésta.
5. La infame columna Blocked
He visto en multitud de ocasiones como los equipos emplean la columna blocked en su sistema kanban. Tengo que reconocer que se me ponen los pelos de punta cada vez que la veo ya que demuestran un bajo nivel de madurez y poco conocimiento de las Prácticas Generales de Kanban. Además, de que el hacerlo supone generar más problemas de los que ya se pueden tener.
Usar la columna Blocked en el sistema kanban va en contra de las prácticas generales de Kanban. Concretamente la que más le afecta es la que hace referencia a Gestionar el Flujo.
El flujo de trabajo de un sistema kanban debería maximizar la entrega de valor, minimizar los tiempos de entrega y ser tan fluido como sea posible, para ello este debe ser continuo e ininterrumpido.
El uso de la columna kanban interrumpe y hace discontinuo el flujo. El usar dicha columna ya de por sí implica que todos los ítems en el tablero deben pasar por el estado Bloqueado ¿no te chirría ya esto de por sí?.
Por tanto, el que se desbloquee un ítem va a hacer que tengamos que volver a un estado anterior (o posterior dependiendo de donde coloques tu columna Blocked). Sin contar que la experiencia hace que los equipos se desentiendan del contenido de la columna Blocked y la suelan usar como cajón de sastre o agujero negro donde todo lo que entra nunca sale.
Los sistemas de flujo pueden ofrecer gran variedad de métricas que son importantes para todos aquellos Jefes de Proyecto, manager del sistema para construir estimaciones fiables. Te remito a la sección de métricas Lean y Kanban del siguiente artículo: https://www.extremeuncertainty.com/agile-metrics-ultimate-guide/
Además, te recomiendo la lectura de Agile Metrics in Action para aprender cómo obtener los datos que realmente importan. Métricas que en caso de usar una columna Blocked se verían comprometidas y no nos podríamos beneficiar de ellas.
La alternativa que puedes emplear y que ya se ha mencionado aquí en varias ocasiones, es emplear la convención de usar post its rosas para visualizar el ítem bloqueado.
Otra opción que puede satisfacer más a todos los fans de la columna Blocked puede ser el uso de un Swimlane en la misma columna del trabajo bloqueado. Considerándola un Aparcamiento para esas tareas pero ojo, teniendo en cuenta de que cada elemento bloqueado sigue consumiendo del Límite WIP impuesto.
Panel con Swimlane de Ítems Aplazados para los Ítems Blocked
6. Escalando Bloqueos
Cuando el equipo es incapaz de resolver un Issue por sí mismo o se requiere de una parte externa para resolverlo y no está disponible o no responde, el Issue debe ser escalado.
Es importante para la organización el desarrollar una fuerte capacidad de escalado de Issues ya que si esta capacidad es pobre o no existe, el mantenimiento y restauración del flujo después de un bloqueo puede ser problemático.
La base de una buena capacidad de escalado es un proceso o política de escalado bien documentado, mediante documentación, en un sitio web o wiki disponible para todos los miembros del equipo.
Es fundamental que no existan ambigüedades sobre cómo y dónde escalar el problema. El equipo de desarrollo se debe tomar su tiempo para definir estas vías de escalado y escribirlas en políticas. Haciendo esto el equipo sabrá a dónde enviar los Issues para su resolución.
No nos tenemos que olvidar del personal senior (managers), de los cuales se espera que formen parte del proceso tomando la responsabilidad de resolver los Issues.
7. Conclusiones
A lo largo del artículo hemos visto la importancia de distinguir los bloqueos y visualizarlos. Se ha mencionado el método usado mediante convención que se basa en el uso de post it rosas para indicar el Issue.
Cabe destacar que no es la única forma de realizarlo y cada equipo debe utilizar la que más se adapte a sus necesidades y más valor le aporte, siempre y cuando no se dejen de lado los principios kanban y permitan hacer el seguimiento del mismo hasta su resolución y no caer en el olvido.
A la hora de gestionar los bloqueos se ha mencionado la existencia de herramientas de monitorización y reporting. Desde mi punto de vista la más completa es el Diagrama de Flujo Acumulado ya que concentra una gran cantidad de información con la que poder trabajar en una única gráfica. Como puede ser el WIP, el Lead Time, Cycle Time, etc. Te dejo un recurso para que conozcas más sobre las métricas pinchando aquí.
Hay que indicar que los bloqueos son inevitables y pueden surgir por causas muy diversas, es trabajo de la organización estar preparada para actuar de la forma más adecuada según el caso y que ese procedimiento esté bien documentado.
En mi experiencia profesional, puedo asegurar que la gran mayoría de los casos de bloqueos estos se podrían haber evitado con una correcta definición de Políticas Explícitas que determinen el Definition of Ready de cada fase del flujo de trabajo de nuestro sistema kanban.
Por último, comentar que existen técnicas para prevenirlos, que dada su extensión se han quedado fuera del artículo, como es el caso de la técnica kanban Dark Matter Planning.
