Kanban en el mundo ágil y en el mundo del software
Por: Vanessa Amaya
Mundo ágil
Yo encuentro 2 categorías de la agilidad: medios y habilitadores.
Los medios para la agilidad, para mí, son los vehículos en los que decidimos subirnos para implementar marcos ágiles, con rutas para caminar dentro de esta nueva forma de trabajo. Los medios más conocidos hasta ahora son: Scrum, Kanban, Devops, eXtreme Programming, Lean Change , Agile People, Management 3.0 y entre los menos populares pero ya cada vez más conocidos y usados (gracias al universo) están TDD (Test Driven Development, Desarrollo guiado por pruebas) y BDD (Behavior Driven Development, Desarrollo guiado por comportamiento).
Los habilitadores para la agilidad, para mí, son las disciplinas y prácticas que no nacieron para y desde la agilidad pero que han entrado a este mundo para ayudar a apoyar e impulsar estos vehículos, por ejemplo: Design Thinking, Visual Thinking, Coaching, Mentoring, OKR’s, Estructuras Liberadoras, Facilitación gráfica, Liderazgo servicial, Facilitación de reuniones, Business Analysis, Product Discovery y prácticas para mejorar la comunicación & colaboración.
Hablemos de Kanban
Siendo Kanban un tema importante pero no tan popular como lo ha sido Scrum, antes de entrar al detalle del tema de esta Blog, quiero especificar 3 términos que considero importantes para el mundo de Kanban:
Sistema Kanban: Es el sistema para controlar el inventario utilizado por el ingeniero de Toyota Taiichi Ohno para la cadena de suministro. Surgió como un sistema de programación para la producción ajustada y la fabricación “just in time” (JIT o justo a tiempo).
Método Kanban: Es la combinación que hizo David J. Anderson en 2005 con elementos del trabajo de W Edwards Deming, Eli Goldratt, Peter Drucker y Taiichi Ohno. El método incorpora conceptos como sistemas “pull” (de arrastre), teoría de colas y flujo. Es esta la combinación que entra al mundo ágil, no directamente, pero adoptado como vehículo para implementar agilidad.
Tablero Kanban: Una herramienta para implementar Kanban. Hay muchos que usan el Tablero Kanban SIN usar el método Kanban. Prueba de ello es que este tablero ha sido adoptado dentro de Scrum y muchos implementan Scrum con el Tablero de Kanban pero no tienen ni idea de qué se trata Kanban.
En este Blog me voy a referir al Método Kanban aplicado al desarrollo de software.
Y un día llegó Kanban…
La mayoría de las personas que conozco, hemos entrado al mundo ágil de la mano de Scrum debido a la estrategia de comunicación y certificaciones que se construyó alrededor que ha provocado su popularidad. Muchos pensábamos que era la única opción y pensando en eso, se empezó a distorsionar Scrum con el síndrome de la zapatilla de cenicienta cuando se lo querían poner las hermanastras, dando como resultado un Scrum puesto a fuerza que solo aumentaba la resistencia a usar un marco ágil.
He sido testigo que en las Pymes, los roles de Scrum no encuentran tanta resistencia para ser implementados, pero en algunos Corporativos la resistencia es muy alta porque la estructura corporativa tiene que cambiar y si no hay una estrategia global es muy difícil. Creo que por ello, ya en la más reciente guía de Scrum ya no dice “roles” sino “responsabilidades”.
Entonces un día llega Kanban sin roles prescritos diciéndonos: “empieza con lo que haces ahora”. Y después de tantas barreras con los roles donde había un Product Owner de título pero sin ejercer, un Scrum Master ejerciendo como Project Manager, o un Scrum Master ejerciendo también como Product Owner porque este último es inexistente en su organización y un equipo de desarrollo perdido en la incongruencia de su entorno, el optar por Kanban comenzó a ser una opción.
Un factor que afecta mucho a los equipos es la falta de equipos dedicados, es decir, un mismo equipo se encarga de más de un proyecto, en el mejor de los casos en 2 al mismo tiempo, en el más fatigante de los casos en 3 o más donde la primera sacrificada es: la calidad en la entrega.
Este factor impacta a Scrum porque su estructura está pensada para cuidar la calidad generando entregas frecuentes con equipos dedicados.
Y llega Kanban poniendo enfoque en gestionar la demanda, entendiéndola, clasificando los elementos de trabajo (solicitudes, requisitos, ideas), manejando las relaciones con los stakeholders y fomentando la transparencia dentro del sistema en torno a la priorización del trabajo, sin importar si el equipo está dedicado o no porque también llega Kanban con un WIP Limit (Work in Progress Limit) para cuidar la calidad dentro de un flujo continuo de entrega.
¿Para desarrollo o para mantenimiento de software?
Kanban encontró una entrada para el mantenimiento de software debido a la necesidad de hacer entregas continuas de acuerdo a la criticidad de las incidencias así como también de acuerdo a la importancia de las mejoras identificadas.
Recientemente estuve colaborando con la Comunidad UndefinedDevs en un live sobre Gestión para Desarrolladores y surgió el tema de Scrum y Kanban, se mencionó que Kanban no le había gustado a alguien porque por el tema del flujo continuo, que sentían que no tenían un respiro como en Scrum con las Dailys, los Sprint Reviews y la retrospectivas. Cuando sucede esto, quiere decir que no se está aplicando el Método Kanban de manera efectiva ya que están omitiendo los Ciclos de Retroalimentación que tiene Kanban, llamados también Cadencias, donde hay eventos que dan este respiro, valor y procesos analíticos que no solo le dan aire al equipo sino que ayudan en su mejora continua.
Ahora bien, lo anterior que he mencionado, no solo aplica para mantenimiento de aplicaciones, también puede aplicar para desarrollos nuevos.
Kanban más allá del software
Aparte de implementar Kanban en equipos de desarrollo de software, he tenido la oportunidad de implementar Kanban en equipos de Marketing, Reclutamiento, RRHH y en la forma en la que me organizo para cumplir en mi trabajo y en las comunidades de práctica donde participo.
