Antes de comenzar un disclaimer sobre este post:
- La intención es generar debate y desafiar a los lectores con un título provocativo.
- No intenta poner un enfoque (Lean/Agile) por encima del otro ni enfrentarlos sino comprenderlos un poco mejor y aprovecharlos según el contexto y los objetivos perseguidos.
Ahora si… vamos al grano. Supongo que como le pasará a muchos agilistas, comparto varios grupos de Whatsapp con varios colegas de agilidad en los que debatimos de temas varios relacionados con la agilidad. En uno de los grupos que estoy generalmente estos debates se dan en tono relajado, con cierto grado de bullying entre los participantes y suele surgir frecuentemente la temática del “humo ágil”, las prácticas más o menos “homeopáticas” que rodean a la agilidad o sobre qué es o no “abrazamiento de árboles” ágil y que tan culpables somos algunos de los allí presentes de ser promotores de esas prácticas. A sabiendas de mi gusto por Kanban, suelen intentar hacerme enfadar diciendo que Kanban es para la fabricación de automóviles y no para software y bromas por el estilo… la cuestión es que hace unos días, en ese grupo afirmé lo siguiente: “Tengo que aclarar algo, a pesar de declararme un fanboy, para mi Kanban no es agile”, lo que desató un debate y puesta en común de distintos puntos de vista y el posterior posteo de una imagen en LinkedIn que compartiré más abajo y que también dió bastante que hablar.
A continuación quisiera compartir mi punto de vista de por qué para mi Kanban no es ágil.
Antes de contar las razones de mi postura quisiera aclarar algo, esta postura no significa que Kanban sea más o menos valioso por ser o no ser agile, es más si es o no ágil no es relevante per se, no pasa por ahí la cosa, lo que sí creo importante tener claro es para qué se diseñó Kanban, qué objetivos persigue, cuándo es más adecuado utilizarlo y qué le podría estar faltando que la agilidad si nos debería proveer.
Entonces… ¿Por qué considero que Kanban no es agile?
Originalmente Kanban nace en los 40s como parte del Toyota Production System, específicamente un subsistema de lo que se conoce como sistema JIT (Just In Time), y es una práctica del mundo fabril, relacionado con el funcionamiento de cadenas de producción seriada. Se lo define como un sistema de información basado en señales visuales cuyo objetivo principal es la búsqueda de eficiencia en los procesos, una visión muy Tayolerana de la gestión si se quiere, donde estamos ante un contexto de producción seriada de productos (Aquí el chiste de que kanban es para fabricar autos y no software aplica perfecto).
El Kanban del que hablo no es exactamente este que acabo de describir, sino de una adaptación del mismo que hizo David Anderson a través de varios años de experiencia aplicando teoría de restricciones y pensamiento lean en equipos que entregaban trabajo del conocimiento (software específicamente), que luego plasmó en algunos libros que dan nombre a lo que hoy se conoce como método Kanban. Aquí tenemos un primer punto, este método está inspirado en el kanban de Toyota, y recordemos que el objetivo del pensamiento lean y el toyotismo es la eficiencia, es decir busca optimizar el uso de recursos o hacer más con menos, sin cortes en el flujo de entrega de valor. Por otro lado, seguramente habrán escuchado cientos de veces que agile no está pensado en términos de eficiencia sino en eficacia, es decir que el foco está en los resultados a obtener no en los costos o maximización el uso de recursos, muchas veces cuando doy alguna formación sobre el mindset ágil suelo decir que si conocemos perfectamente qué hay que hacer y no hay espacio para la adaptación, seguramente aplicar agilidad aquí nos costará más caro que si aplicamos un enfoque predictivo.
El siguiente gráfico explica visualmente la diferencia entre eficiencia y eficacia:
Para continuar, creo que es importante poner en común una definición de agilidad antes de seguir hablando sobre de si Kanban es o no agile. Como sabemos no existe una única definición oficial y aquí aplica el chiste, si le preguntas a diez agilistas qué es la agilidad probablemente obtengas once respuestas, pero tratando de quitarle los distintos condimentos y puntos de vista personales e intentando hacer un esbozo objetivo podríamos decir como punto de partida y basándonos en lo que dice el manifiesto ágil lo siguiente:
La agilidad es un mindset descrito por cuatro valores, definido por doce principios y manifestado en varias técnicas, herramientas, prácticas y/o marcos de trabajo, o dicho visualmente que siempre queda más claro:
Vamos entonces al segundo punto relacionado a los valores de la agilidad, que para recordarlos son los siguientes:
“Personas e interacciones” por sobre “Procesos y herramientas”
“Colaboración con el cliente” por sobre “Negociación contractual”
“Software funcionando” por sobre “Documentación extensiva”
“Responder al cambio” por sobre “Seguir un plan”
Además de los 12 principios que nombrarlos a todos aquí sería excesivo pero se pueden revisar en el sitio web oficial del Agile Manifesto.
Kanban está inspirado en pensamiento lean y no comparte los mismos valores ni principios que acabamos de nombrar, y si miramos sus seis prácticas así lo evidencian:
- Visualizar el flujo
- Limitar el WIP (Work In Progress)
- Gestionar el flujo
- Hacer políticas explícitas
- Establecer circuitos de retroalimentación
- Mejorar y evolucionar
Ninguna de estas prácticas está específicamente orientada a entregar software funcionando de manera temprana ni incremental, en ninguna práctica se explicita que se deba colaborar con el cliente de manera regular ni tampoco se habla de la forma en que interactúan las personas, la motivación o la manera de comunicarse. Importante… no quiere decir que el hecho de limitar el WIP o visualizar el flujo no nos ayuden a poder entregar software de manera frecuente y continua o ser más adaptables al cambio, o que en la mejora y evolución no se pueda tratar la motivación o las interacciones personales… mi punto es que perfectamente podemos trabajar con un equipo desarrolladores esclavos donde no hay un mínimo de posibilidad de pensar en la motivación, donde el alcance está perfectamente preestablecido de antemano y no hay posibilidad de adaptar o cambiar nada, o que deba entregarse de manera continua o incremental ni que sea necesario sentar en la misma mesa al negocio con los desarrolladores todo esto sin romper ninguna de las prácticas de Kanban.
Sin embargo, si hacemos una rápida recorrida por scrum, por diseño necesitamos un Product Owner que trabaje con los desarrolladores y existen varias instancias donde especifica su interacción (planning, review, daily, retrospectiva y refinamiento), la definición de qué es un sprint requiere definir e intentar cumplir un objetivo de sprint que debe inspeccionarse junto a stakeholders al final del sprint para obtener feedback y adaptar el backlog en consecuencia. Rápidamente vemos que los valores de personas e interacciones, adaptación al cambio, software funcionando y colaboración con el cliente están presentes por diseño del marco de trabajo. Repito… esto no hace a Scrum mejor que Kanban, solo digo que tienen enfoques diferentes, y mirando los valores y principios en los que se basan me atrevo a afirmar que Kanban no es agile, aunque eso no significa que sea incompatible con la agilidad o que no se pueda hacer agilidad con Kanban, pero no trae agilidad por diseño, al fin y al cabo es una herramienta y muy noble y útil por cierto, que probablemente nos traiga más alegrías que si aplicamos scrum por la fuerza en cualquier contexto. Tampoco quita que podamos tomar prácticas de Kanban para potenciar Scrum o viceversa, agregándoles condimentos a ambos que quizás no tienen por diseño.
Luego de esa afirmación en el grupo de WhatsApp que comentaba al principio, me puse a buscar a ver si algún agilista famoso decía algo parecido, y me encontré un artículo de Ron Jeffries, uno de los firmantes del manifiesto ágil y padre de Extreme Programming que contaba algo parecido a mi punto de vista al respecto, el artículo en cuestión se puede leer aquí pero les dejo un extracto de una de las partes que más me gustan y con la que estoy totalmente de acuerdo.
Volviendo al debate inicial, lo importante no es si es ágil o no, sino saber cuándo aplicar cada cosa, tristemente he visto muchísimos casos donde he detectado dos cosas, la primera es que se ve a Kanban como un paso previo a Scrum, siendo Scrum de alguna manera una “evolución” obligada, la segunda quizás relacionada es aplicar Scrum a todo, a cualquier tipo de iniciativa porque es lo que se conoce y lo que hace todo el mundo, sin importar si es imposible hacer alguna adaptación en el alcance y las fechas ya vienen escritas en piedra, o si es imposible hacer entregas parciales, si no hay producto para entregar e inspeccionar o si no podemos sentar a un representante del negocio junto con el equipo de desarrollo para llevar adelante la iniciativa. En esta línea me he encontrado con ejemplos como scrum aplicado en recursos humanos para procesos de contratación, notemos que aquí no hay producto y por tanto no hay Product Owner, no hay entregables para inspeccionar y cambiar el rumbo, generalmente solamente estamos llamando sprints a períodos de dos semanas y tenemos un backlog de trabajo inmutable que debemos sacar adelante.
Probablemente cuando hablamos de entrega de servicios más que desarrollo incremental de productos con incertidumbre, es más probable que Kanban nos ayude a mejorar nuestro proceso y en consecuencia la entrega del valor y la satisfacción de nuestros clientes (Notar que estamos hablando de eficiencia y mejora de procesos). El anterior no es el único aspecto a evaluar a la hora de decidir por qué camino ir, como ejemplo de otros factores les comparto a continuación un funnel que utilizo para hacer un punteo rápido de la “pinta” que tiene un equipo de trabajo para ver si tiene mejor fit con Scrum o Kanban, en mi defensa quiero aclarar que es una herramienta de creación propia que no tiene mucho tiempo dedicado en su creación y que probablemente es muy mejorable aún (Feedback bienvenido), pero que quizás sea de utilidad. El funcionamiento se basa en analizar cada factor y mover la pequeña flecha hacia el lado que mejor cumple el enunciado y luego teniendo en cuenta que los cuatro primeros factores son los de mayor peso, determinar cuál opción hace mejor fit teniendo en cuenta qué lado tiene más flechas.
Creo que sería ideal combinar este funnel con Wardley Maps para tener un análisis más detallado e indicios más claros sobre qué camino tomar pero eso es tema para otro artículo.
Para cerrar y como dije más arriba, lo relevante aquí no es la pertenencia o no a la agilidad, sino saber cuándo aplicar cada cosa y los objetivos que persigue cada enfoque, cada marco de trabajo, método o herramienta por diseño, es importante tener una caja de herramientas con varias opciones para aplicar según el caso, ya que:
Si la única herramienta que conocemos es el martillo seguramente todos los problemas tendrán pinta de clavos.
Si llegaste hasta acá te doy la gracias por leerme y me gustaría conocer tu opinión al respecto.
Hasta el próximo post!
Escrito y publicado por:
Mauro Strione.
Lead Agile Coach.
https://www.linkedin.com/in/maurostrione/
