¡Hay agilidad más allá del Scrum! - Kanban y STATIK
En muchas ocasiones (IMHO diría demasiadas) cuando hablamos de Agilidad nuestra mente imagina escenarios con equipos trabajando en Scrum, y cada vez más. Y es que no es para menos contando con que según el 16th State of Agile Report de 2022 el 87% de los encuestados reporta que está usando Scrum en alguno de sus equipos frente a un 58% que se obtuvo en el report de tiempos pandémicos (2020).
Aun así, este importante incremento del 29% por parte de Scrum no se lleva la palma en esta ocasión, si no que el uso de Kanban se ha disparado nada menos que un 49%, desde un 7% en 2020 a un 56% en 2022.
¿Kanban? ¿Cómo que Kanban? Pues sí, Kanban. Y yo personalmente creo que por una sencilla razón:
En sus primeros compases, la implantación de Scrum puede llegar a ser excesivamente disruptiva cuando se implanta en un entorno ya funcionando a su manera. En momentos delicados, con alta incertidumbre o tensión, el ser humano por naturaleza tiende a refugiarse en lo conocido y es común ver "pasos atrás" en las implantaciones de Scrum cuando este es un modelo notablemente diferente del conocido. Con Kanban, podemos no tener este problema si lo hacemos bien.
Mis padres (médicos de profesión) siempre dicen que lo complicado de las intervenciones quirúrgicas es que tienes que hacerlo con "la máquina en marcha", ¡Imagínate un mecánico arreglando un coche con el motor en marcha y sin poderlo parar!
Algo parecido pasa con las implantaciones de agilidad, muchas veces el objetivo es implantar agilidad en un producto/proyecto en marcha y, claro, no lo puedes parar...
Como ya sabemos, en las implantaciones de Kanban el punto de partida es la forma de trabajo en ese momento, y el análisis de la forma del trabajo implantada, las razones de ser de esta y las definiciones del camino a seguir para adoptar un modelo Kanban no siempre son sencillas, ahí es donde entra a ayudarnos STATIK.
STATIK
STATIK significa "System Thinking Approach To Introduce Kanban", algo así como Enfoque de pensamiento sistémico para introducir Kanban.
Volviendo al símil del cuerpo humano, los sistemas digestivo, nervioso, circulatorio, respiratorio... tienen su propia manera de funcionar pero no están aislados, tienen una interacción con el resto de sistemas y su desempeño se ve afectado en mayor o menor medida por el funcionamiento del sistema completo. Este enfoque de visión global (sistémica) es la base del proceso STATIK.
STATIK está organizado en 8 pasos (+1 previo) iterativos pero no necesariamente secuenciales (salvo el paso previo, este sí lo tendremos que ejecutar en primer lugar):
PASO 0: IDENTIFICACIÓN DE SERVICIOS
En muchas ocasiones (normalmente por crecimiento sin control) hemos visto que en un mismo sistema se están tratando diferentes servicios. Antes de empezar con el proceso debemos identificar y separar estos servicios y aplicar los pasos siguientes para cada uno de los servicios identificados.
PASO 1: PROPÓSITO
¿Qué estamos haciendo? ¿Qué quiere el cliente? ¿Qué define el cliente como "bueno"? ¿Qué y cómo estamos midiendo? ¿En qué punto está nuestro criterio "fit for purpose"? Recordemos que normalmente estos sistemas ya vienen funcionando, con lo que es probable que hayan definidos unos SLA, SLE, KPI, OKR... Es el momento de analizar esos parámetros indicadores y tenerlos en cuenta, tenemos que entender de manera muy clara qué es lo que hace que el sistema sea adecuado para el cliente.
PASO 2: INSATISFACCIONES
Hay que tener en cuenta tanto las insatisfacciones externas (cliente) como las internas (equipos) y en caso de insatisfacciones comunes, los puntos de vista de ambos. A veces las insatisfacciones externas e internas están relacionadas por un problema común y habrá que equilibrar la solución.
Habrán otras ocasiones en los que algunas insatisfacciones no se podrán corregir, a veces podremos mitigarlas en parte o incluso no podremos actuar sobre ellas y nos tocará aceptarlas.
Es momento también de establecer expectativas realistas comunes.
PASO 3: DEMANDA
¿De dónde y cómo viene el trabajo nuevo? ¿Cómo se organiza o clasifica ese nuevo trabajo? ¿Es constante el flujo de entrada de trabajo? ¿Qué se espera que haga el sistema con este nuevo trabajo? ¿Es correcto el nivel de equilibrio entre detalle y abstracción? En este paso debemos ser capaces de identificar los distintos tipos de trabajos que fluyen en nuestro sistema así como los orígenes que nos lo introducen. Es muy útil (siguiendo el System Thinking Approach) identificar el por qué de cada trabajo, para asegurarnos que estamos remando en la dirección correcta para cumplir los propósitos definidos en el paso 1.
PASO 4: CAPACIDAD
Si contamos con un histórico es momento de explotarlo. Debemos identificar la capacidad del equipo tanto a nivel de eficiencia como a nivel de eficacia. Debemos analizar la cantidad total de trabajo que el equipo puede asumir, la cantidad total de trabajo valioso para el cliente, la calidad de este trabajo y el "gap" (en caso de que exista) entre esta capacidad y las expectativas del cliente.
PASO 5: FLUJO DE TRABAJO
Tenemos definidos los diferentes tipos de trabajo del paso 3 y de ellos podemos extraer una primera aproximación del que será nuestro flujo de trabajo. Este flujo deberá estar en mejora contínua, no debemos intentar crear el flujo perfecto que cubra al 100% todos los casos por los que pasan nuestros ítems, simplemente extraer los principales estados por los que pasa nuestro trabajo. Al contrario de lo que se piensa muchas veces, no es incorrecto establecer estados que no aporten valor real al trabajo si estos son necesarios en el flujo. Una vez definido el flujo, este conformará normalmente las columnas de nuestro tablero Kanban.
PASO 6: CLASES DE SERVICIO
Si en el paso 5 hemos definido las columnas, en este paso deberemos definir las filas. Un error común es confundir clases de servicio con tipos de trabajo, existirán sistemas en los que una clase de servicio solo gestiona un tipo de trabajo, pero no siempre es así, de hecho, lo normal es que no lo sea. En Kanban una clase de servicio cumple un conjunto de normas que se utilizan para categorizar los ítems de trabajo. En el 90% de los casos esta categorización suele ser por prioridad o urgencia y por nivel de riesgo pero no en todos los casos. Existe una especie de "estándar" sobre las clases de servicio de Kanban en la que se establecen las siguientes en función de su coste de retraso con respecto al tiempo:
- Expedito
- Fecha fija
- Estándar
- Intangible
Esta clasificación, aunque muchas veces se nos venda como "estándar" no es la única y además puede ser contraproducente en algunos casos, por ejemplo, en equipos de soporte he visto varios con la clasificación de tipo MTTR (Mean time to response/recovery/resolve...) mucho más enfocada a sus objetivos.
PASO 7: SISTEMA KANBAN
Basado en todo lo que se ha extraído en los pasos anteriores ya podemos definir nuestro sistema Kanban al completo (definición de las políticas explícitas, WIPs, métricas útiles, diseño de tarjetas, adaptación de reuniones existentes a feedback loops o cadencias, etc.) Para este paso podemos echarle un vistazo al conocido Kanban Madurity Model (KMM)
PASO 8: SOCIALIZAR, NEGOCIAR Y PUESTA EN MARCHA
Es momento de compartir y lanzar la iniciativa. Al igual que pasaba con las insatisfacciones debemos tener en cuenta todos los puntos de vista implicados e incluso los no implicados ya que en este punto es positiva también la visión de las partes interesadas externas. Es muy importante recoger feedback e implementar posibles mejoras que puedan surgir.
CONCLUSIÓN
Con esto no tendremos un sistema Kanban perfecto pero STATIK nos ayuda a responder a la típica pregunta de "¿Por dónde empiezo?" con esta guía. Kanban lleva implícita la mejora contínua por tanto debemos entender este punto como nuestro nuevo punto de partida para continuar mejorando.
Keep calm and be agile ;)