Systems Thinking Approach to Introducing Kanban (o STATIK) es, según David Anderson (el padre del método Kanban), el enfoque principal para cualquiera que quiera adoptar Kanban. Su aplicación generalmente se da en grupos, involucrando a todas las personas que participan en la ejecución del servicio para el que se pretende aplicar dicho método.
El método STATIK es extremadamente exploratorio, por lo que también se puede utilizar para mejorar una implementación Kanban existente o incluso para resolver problemas y tomar decisiones utilizando el pensamiento sistémico y los principios y prácticas de Kanban.
STATIK es un tema frecuente en la comunidad Kanban. Natália Manha, de PagSeguro, incluso hizo una publicación en Agile.pub mostrando que STATIK es mucho más simple de lo que el nombre lo hace parecer.
La idea de esta publicación es brindar ideas sobre cómo aplicar cada uno de los 8 pasos de STATIK, con consejos basados en la experiencia de la aplicación del método en diferentes contextos, desde departamentos jurídicos hasta equipos de tecnología.
Introducción
Si ya conoces STATIK, te aconsejo que vayas directamente a los consejos para cada paso. De lo contrario, vale la pena leer el texto completo.
De todos modos, lo más importante aquí es:
¡Deja de empezar y empieza a terminar!
Bien, incluso antes del primer paso, el consejo es: no olvides que el enfoque se basa en el pensamiento sistémico.
Systems thinking, tal como lo define Peter Senge en su libro “La Quinta Disciplina”, es una forma de analizar los estándares en una organización desde un punto de vista amplio, en lugar de mirar una pequeña parte de forma aislada.
Senge usa un elefante como metáfora para explicar el pensamiento sistémico: si divides un elefante en dos, no tendrás dos elefantes pequeños. No hay forma de mirar solo una parte del elefante si quieres aprender a lidiar con él. Una organización, como un elefante, es un organismo vivo y, por lo tanto, debe gestionarse bajo una visión integral en lugar de partes aisladas.
Es muy fácil dejarse seducir por STATIK paso a paso y dejar de lado el pensamiento sistémico. Seguir una receta de repostería (o los 8 simples pasos de STATIK) no es suficiente para garantizar que tendrás un pastel (o un sistema Kanban) cuando llegues al final. Mucho menos que el resultado de esta receta te aplacará el hambre (o los problemas que quieres solucionar con Kanban).
Incluso con 8 pasos explícitos, STATIK es un método iterativo y no requiere que todos los pasos se utilicen en su aplicación. Mucho menos que se hagan en orden. Es importante recordar que el entorno en el que te encuentras probablemente sea complejo y no existe una receta para resolver tus problemas. Pero existen buenas prácticas que pueden ayudarte.
1. Objetivo: Comprender quién es tu cliente y qué significa el éxito para él
El método Kanban habla mucho de eficiencia, pero reconoce explícitamente el poder de la eficacia. El propósito del grupo que está ejecutando STATIK es el pilar central para asegurar que la dirección en la que caminamos (o corremos) sea la correcta.
El consejo aquí es utilizar técnicas ya conocidas como Elevator Pitch, o incluso la parte inicial del Tanque de Decantación Knowledge21. He estado usando una plantilla (no recuerdo de dónde la saqué, ¡discúlpame!), que ha funcionado bien:
NOSOTROS COMO <quiénes somos>
PROVEEMOS <qué hacemos>
PARA <cliente>
A FIN DE <motivo por el cual el cliente nos busca>
Por lo general, divido al grupo de personas en grupos más pequeños. Cada uno completa la plantilla y luego hacemos un dot-voting para cada parte de la plantilla, llegando a un consenso juntos.
Usa y abusa de la discusión de propósito en equipos de baja madurez, que claramente nunca se detuvieron a discutir quiénes son o qué hacen en realidad. Por lo general, en estos casos, solo la discusión del propósito ya es de gran valor. Recuerda: más que crear un sistema Kanban, deseas que las personas involucradas en el sistema actual comprendan las relaciones sistémicas existentes.
2. Insatisfacciones: la base de la evolución
Peter Senge, en su libro “La Quinta Disciplina”, define como Tensión Creativa la diferencia que cada individuo percibe entre la realidad actual y el futuro ideal. Es esta percepción (es así hoy, pero idealmente sería de esta otra manera) la que hace que el individuo progrese, para cambiar la realidad percibida para ser cada vez más similar al futuro deseado, y así resolver su tensión.
Si queremos que el grupo en cuestión aplique la mejora continua, dado que Kanban es fundamentalmente un método de mejora, la Tensión Creativa propuesta por Senge es probablemente el mejor combustible para el grupo.
El consejo en este paso es dejar que cada uno llene y exponga las insatisfacciones existentes con el sistema actual.
Un estándar que he visto surgir es aquel en el que solo aparecen insatisfacciones desde la perspectiva de quienes trabajan en el sistema. Yo suelo aprovechar este estándar y les pido que clasifiquen cada insatisfacción como “interna” (la percibimos) o externa (la perciben los clientes o stakeholders).
Cuando la escasez de insatisfacción externa se hace explícita (algo común en entornos menos maduros), me tomo el tiempo para generar esta tensión en el grupo y hacerles ver el sistema desde la perspectiva del cliente (algo común en entornos más maduros).
Agrupar y priorizar las insatisfacciones en un grupo es un ejercicio bastante recomendado para asegurar el enfoque durante los siguientes pasos.
3. Análisis de la demanda: trabajo en curso
Tener en cuenta el principio Kanban de “Empieza con lo que haces ahora” es el consejo principal para este paso.
Por lo general, le pido a la gente que escriba en post-its las actividades que están en marcha, o si ya tienen una pizarra, pegarlos allí. Para cada actividad, le pido a la persona que comparta con todos cuál es la actividad, de dónde vino (quién la solicitó) y con qué frecuencia se solicitan actividades de este tipo.
Es importante recordar el pensamiento sistémico en este punto y tratar de que el grupo vaya más allá de “quien lo pidió fue mi jefe”. Estar alineado con el propósito (paso 1) es fundamental en cada una de las actividades. En algunos casos, vale incluso preguntar: “¿Por qué estamos haciendo esta actividad?”.
Recuerda: la discusión es de gran valor para mejorar la visión sistémica del grupo.
También vale la pena estar atento a los estándares que surgirán: actividades similares, en grandes cantidades, pueden significar un “tipo de demanda” con la que el grupo generalmente se ocupa. Las organizaciones de baja madurez generalmente se ocupan de tareas generadas por los propios miembros en lugar de demandas solicitadas por el cliente, y encontrar los tipos de demandas que provienen del cliente es un paso fundamental para comprender y administrar el sistema.
4. Análisis de capacidad (o ausencia de este)
Suelo extraer el análisis de capacidad por las últimas actividades entregadas por el grupo. No siempre contamos con un contexto lo suficientemente bien definido para realizar los análisis fundamentales de esta etapa, como cuánto tiempo nos llevó hacer esta actividad (Lead Time) o cuántos de estos entregamos por semana. Pero las preguntas de esta etapa, junto con las preguntas ya planteadas, nos ayudan a comprender mejor el flujo de los diferentes tipos de demanda que maneja el grupo.
Una pregunta que generalmente genera una buena tensión en la gente para extraer un poco más de efectividad es: ¿Tuvimos algún tipo de feedback sobre esta entrega?
El consejo principal aquí es que incluso en escenarios más inmaduros en los que la información recopilada en este paso es nebulosa, generalmente sirve para validar los tipos de demanda que surgieron y para explicar conceptos básicos de métricas de eficiencia y negocios.
5. Workflow: conocimiento a lo largo del tiempo
En este paso se analiza el workflow de cada tipo de demanda identificado. Workflow es una palabra común en la mayoría de las organizaciones y se entiende como la secuencia de pasos establecida para completar una actividad determinada.
Resulta que, para los trabajadores del conocimiento, el workflow debe verse como la secuencia de los pasos principales para aprender sobre el elemento en el que estamos trabajando.
Confieso que nunca pude realmente escapar de la visión fabril de workflow en este paso y analizarlo desde la perspectiva del trabajador del conocimiento, sin embargo, planteo el workflow visto por el equipo.
La sugerencia, en este paso, es considerar el workflow solo de los tipos de demanda más prioritarios. Priorizar los tipos de demanda en conjunto antes de analizar el workflow y, por supuesto, una buena idea.
6. Clases de servicio – ¿WTF?
Las clases de servicio son políticas sobre cómo un elemento debe ser tratado por nuestro grupo, dadas sus características. Las principales clases de servicio utilizadas en Kanban son generalmente (en traducción libre):
- Urgente: elementos que hay que entregar lo antes posible, de lo contrario tendremos (o ya estamos teniendo) ¡una pérdida absurda!
- Fecha fija: elementos que, si no se entregan en una determinada fecha, ya no necesitan entregarse (como Black Friday)
- Estándar: elementos comunes, de los que tratamos todos los días, y que no tienen nada de especial en la entrega esperada hasta que son urgentes
- Intangibles: elementos sin un gran rendimiento o impacto financiero esperado después de la entrega, pero si funcionan puede ser una gran ventaja para la organización
Me gusta mucho la relación entre clases de servicio y horizontes de planificación.
El consejo aquí es pedirle al grupo que traiga ejemplos de demandas urgentes, con fecha fija, estándar e intangibles en su contexto. Y para cada ejemplo, que digan qué característica clasifica esa demanda en esa clase de servicio. Por ejemplo: “el bug de la semana pasada fue urgente porque detuvo la producción”. En otras palabras: los elementos que paran la producción, ¡son urgentes para nosotros!
Si nunca has usado clases de servicio y la madurez del grupo es muy baja, usar la priorización solo por el tipo de demanda (identificada en los pasos anteriores) y omitir este paso puede ser lo más apropiado.
7. Design Kanban System – Modelado del sistema
¡Ha llegado el momento más esperado! Es hora de unir todo el aprendizaje y la percepción sistémica adquirida en los pasos anteriores y modelar el sistema Kanban. Los pasos principales del workflow tienden a convertirse aquí en columnas. Las actividades en curso tienden a estar ya categorizadas en tipos de demanda. Las clases de servicio tienden a convertirse en rayas en tu pizarra. Las métricas recopiladas pueden ser la base para definir los límites de WIP.
¡Pero cálmate! El consejo principal aquí es: no modeles un sistema más complejo que el que necesita el grupo en este momento. El cambio tiene que ser evolutivo. No tiene sentido usar el límite de WIP para grupos con una madurez muy baja, por ejemplo.
Quizás la mayor ganancia de este tipo de grupo es la visualización del trabajo en curso, de los defectos (bugs y problemas) que aparecen en cada etapa, o incluso de los tipos de demanda que están fluyendo en la pizarra. Quizás el simple hecho de tener una pizarra sea una ganancia suficiente por el momento. Si bien es tentador utilizar todo lo aprendido sobre Kanban hasta la fecha, no generes más estrés del que necesita el grupo.
8. Rollout – ¡Pongamos en marcha el sistema Kanban!
Después del diseño, está la parte más divertida: coge la cinta adhesiva de colores, los post-its, los bolígrafos y ¡vamos a la pizarra! Este suele ser un momento simbólico y de gran colaboración para equipos que nunca han tenido contacto con Kanban.
El consejo principal aquí es recopilar feedbacks que tengan algún tipo de relación con el sistema (stakeholders) y que no participaron en las fases anteriores de STATIK. Obtener un feedback de ese director que es parte esencial de tu proceso (ese paso de aprobación que siempre ocurre al final), o de otras áreas de la organización que requieren trabajo para el grupo que está implementando el sistema Kanban.
Es importante mantener al grupo en una posición sencilla, donde nadie intente ser “la persona más inteligente de la sala”, siguiendo los consejos del propio David Anderson.
Conclusiones y referencias
Espero que los consejos os hayan sido de ayuda. Os dejo a continuación algunas de las principales referencias, y os pido, por favor, que complementéis los consejos y referencias en los comentarios del blog.
¡Feedbacks y preguntas también son siempre muy bienvenidos!
Libros sobre STATIK
Si quieres saber más sobre Kanban, asegúrate de leer estos libros.
- La Quinta Disciplina – Peter Senge: lo puse en el primer lugar de la lista a propósito. Un libro que definitivamente deberías leer para comprender mejor las organizaciones y el pensamiento sistémico. También está en inglés en Audible.com
- Kanban from the Inside – Mike Burrows: hay un capítulo completo sobre STATIK. El libro es de 2014, por lo que no está tan actualizado, pero es quizás la mejor referencia bibliográfica sobre STATIK.
- Essential Kanban Condensed (¡gratis!) – Andy Carmichael y David Anderson: “kanban guide”. Sucinta y directa. Menciona brevemente STATIK. De hecho, todo en este libro se cita brevemente. jeje.
- Kanban Maturity Model – Teodora Bozheva y David J. Anderson: Habla sobre las etapas de madurez (una palabra muy utilizada a lo largo de esta publicación), y las características de cada nivel.
