Índice de contenidos
Introducción a Kanban
1603: inicios de Kanban
En 1603, tras los conflictos militares casi constantes del siglo XIV y la agitación social de Japón, el país entró en un periodo de estabilidad y crecimiento económico. A medida que le economía japonesa prosperaba, las calles de las ciudades se llenaban de tiendas y negocios locales, que buscaban la atención y la conciencia de los clientes. Es en estas calles, dónde nace el término Kanban.
Kanban proviene de dos palabras japonesas, “Kan”, que significa señal, y “Ban”, que significa tablero. A medida que las calles y locales se volvían cada vez más concurridas, los propietarios de las tiendas empezaron a hacer letreros personalizados para atraer la atención de los transeúntes y contarles los servicios que cada uno ofrecía.
Poco a poco, los japoneses fueron utilizando estas tarjetas con distintos diseños, por lo que es muy frecuente encontrar tarjetas de Kanban con forma de pez para tiendas de pescadores, o en forma de pipa de madera, para tiendas de pipas.
Todas estas tarjetas tenían una cosa en común entre ellas y respecto a las tarjetas Kanban que conocemos hoy en día y visualizamos en nuestras herramientas de trabajo como Jira, comunican un mensaje de manera clara y concisa. El mensaje en este caso era saber cuántas personas había dentro de las tiendas, o lo que es lo mismo, controlar el aforo de espacios públicos o comercios.
1940: Lean Manufacturing en Toyota
Producir sólo lo que se necesita, cuando se necesita y en la cantidad necesaria (Taiichi Ōno).
En la década de los 40, Toyota no se imaginaba que acabaría siendo el gigante industrial que es hoy en día. Después de la II Guerra Mundial, la industria automovilística se encontraba estancada. Toyota se veía incapaz de competir con los fabricantes automovilísticos estadounidenses como Ford, la empresa sólo tenía perdidas. Al no tener beneficios, tampoco podía contratar más personal. Es entonces cuando el CEO de Toyota, Kiichiro Toyoda, se dio cuenta de que la diferencia de su empresa con las estadounidenses (las americanas producían diez veces más) no se arreglaría contratando más personal, la solución era un poco más compleja.
Toyota apostó por la innovación y la optimización de la organización del trabajo. Este cambio de cultura empresarial allanó el camino a Taiichi Ōno, un joven ingeniero industrial. Ōno tenía un carácter estricto, lo que definiríamos como “suave pero firme”, lo que le permitió ascender rápidamente en la jerarquía de la empresa. En 1949, se convirtió en gerente de tienda de máquinas, donde empezó a experimentar con nuevas herramientas y principios de la organización del trabajo. En el año 1954, fue ascendido a un puesto de director.
Ōno identifico y categorizo 7 tipos de desperdicios, o lo que en Toyota se conoce como Muda:
De los 7 desperdicios identificados por Ōno, la sobreproducción y el inventario que tenían de materia primas, eran los que más le preocupaban. ¿Qué hizo Ōno después de este análisis? Producir lo que se necesitaba cuando se necesitaba. Una respuesta lógica para el mundo actual en el que vivimos, pero revolucionaria en la década de los cincuenta.
Esto requería mantener los stocks al mínimo mientras se aseguraba un flujo de trabajo suave a través de todo el proceso. Pero ¿cómo iban a identificar cuando sería necesario un nuevo producto? Y lo más importante aún, ¿cómo avisarían a la línea de producción y a los proveedores de materias primas? Inspirado por los comercios minoristas y sus tarjetas Kanban, Ōno decidió visitar las cadenas de supermercado Piggly Wiggly en 1956 y quedó impresionado en como mantenían los estantes con la cantidad justa de producto. Cuando volvió a Japón, empezó a utilizar las tarjetas Kanban en papel para señalizar y rastrear la demanda en la fábrica de Toyota. Así nace el sistema Kanban.
Toyota usaba las tarjetas Kanban en cada coche terminado, de manera que cuando el coche se entregaba al cliente, la tarjeta volvía a la línea de producción. Los trabajadores solo podían trabajar en un coche cuando la tarjeta que identificaba una demanda volvía a ellos en el flujo de trabajo, y sólo cuando el número de tarjetas Kanban pendientes alcanzaba un umbral definido. De la misma forma, cada material utilizado en la cadena de producción, tenía su propia tarjeta, de modo que la señal de demanda fluyera hacia abajo a través de toda la cadena de producción, terminando en proveedores externos.
Este sistema redujo los inventarios, mejoró el rendimiento y proporciono una alta visibilidad del proceso. Su uso se extendió como la pólvora en toda la división de mecanizado. En 1963, se desarrolló un plan para propagarlo a toda la empresa, y poco después due adoptado en casi todos los procesos de Toyota.
Toyota pasó de operar con pérdidas, a ser el competidor global que es hoy. Ōno ascendió por todos los rangos superiores de la compañía, convirtiéndose en vicepresidente ejecutivo en 1975. Su trabajo dio lugar al nuevo significado de Kanban y sentó las bases técnicas modernas de gestión, conocidas como Sistema de Producción Toyota.
2003 – 2008: Kanban en la industria del Software
A medida que el Sistema de Producción Toyota ganaba popularidad, los gerentes de proyectos de distintos tipos de industria intentaban aplicar el sistema en sus trabajos.
En este momento, la gestión de proyectos en el mundo del software se iba alejando gradualmente de procesos engorrosos e ineficientes hacia un enfoque más ligero y ágil. Fue el año 2001, que se publica el Manifiesto Ágil, dónde se promueven, entre otros, el aceptar los cambios en los requisitos y entregar software funcional con frecuencia. Aun así, el Manifiesto no especifica cómo lograrlo. Es ahí cuando varios sistemas de gestión empiezan a llenar este vacío, los más conocidos actualmente son Scrum, eXtreme Programming (XP), y el Desarrollo de Software Lean.
Los tres métodos de trabajo tuvieron un impacto significativo en lo que estaba a punto de convertirse como el método Kanban.
- Scrum: muchos equipos de Scrum usaban tableros con tarjetas de historias de usuario (US) para mostrar y visualizar la información. Durante la planificación del Sprint, cada US o feature se escribía en una tarjeta separada. Juntas, estas tarjetas formaban lo que conocemos como el backlog del sprint y se colocaban en un tablero grande en un espacio de la oficina donde todo el equipo lo pudiese ver. Cada miembro del equipo podía acercarse al tablero, mirar las US y elegir la tarjeta con la que iba a trabajar. Cuando completaban el trabajo, devolvían la tarjeta al tablero, con las palabras tachadas. Este sistema era simple pero eficaz. Proporcionaba una alta visibilidad del progreso, permitiendo la sincronización del trabajo entre los programadores y mejoraba el flujo del trabajo ya que cada desarrollador podía elegir el tipo de feature a en el que se sentía mejor trabajando.
- Desarrollo de Software Lean: en 2003, Mary y Tom Poppendieck publicaron el libro Lean Software Development: An Agile Toolkit, donde tradujeron los principios de la fabricación Lean del Sistema de Producción Toyota al desarrollo del software y el trabajo del conocimiento. El libro se centra en la eliminación de desperdicios, el mapeo del flujo de valor y en los sistemas pull. En 2007, los mismos autores publicaron el libro Implementing Lean Software Development: From Concept to Cash, que explora más el uso de la teoría de colas para reducir los tiempos de entrega del software y los tableros Kanban como elemento del espacio de trabajo visual. En 2005, Jim Sutton y Peter Middleton publicaron Estrategias de Software Lean, donde identificaban los 5 principios de la producción lean en el desarrollo de software:
- Definir el valor
- Mapear el flujo de valor
- Implementar el flujo
- Mantener un proceso pull
- Buscar oportunidades de mejora
- Gestión Ágil: aparte de Scrum y de Lean, también se exploraron otros conceptos sobre cómo los equipos se podían volver más ágiles. En 2004, David Anderson publicó el libro Gestión Ágil para Ingeniería de Software: Aplicando la Teoría de Restricciones para Resultados Empresariales, donde se cubren conceptos como flujo, cuello de botella, control visual y diagrama de flujo acumulativo, todos los cuales se incorporan posteriormente en el método Kanban. En este momento, equipos que usaban tableros de Scrum, adoptaron estas nuevas técnicas y reorganizaron sus tableros introduciendo columnas que representaban las distintas etapas del trabajo, dando origen así a los tableros Kanban.
Los tableros Kanban, combinados con:
- Los Métodos de Desarrollo de Software Lean y Gestión Ágil;
- La Programación Pull;
- La Limitación del Trabajo a la Capacidad; y
- La Medición del flujo
…dieron lugar al desarrollo de software estilo Kanban. Este Kanban temprano fue aceptado como sistema propio, ya que ayudaba con todas aquellas cosas en las que Scrum no era particularmente bueno, como acortar el tiempo de ciclo desde la solicitud del cliente hasta la entrega, asegurando un flujo constante de trabajo.
A medida que la adopción del desarrollo de software con Kanban crecía lentamente, algunos pioneros ayudaron a difundir el conocimiento al respecto y dar forma a su futuro definitivo.
Microsoft fue de los primeros en introducir los principios de Kanban. Para aumentar la productividad, agregaron elementos de Scrum y Kanban como extensión del modelo existente de Feature Crew y el método de Bug Jail. Esto dio como resultado el primer proyecto Scrumban en 2004.
David Anderson, Dominica DeGrandis, Corey Ladas y Daniel Vacanti introdujeron el sistema Kanban en Corbis en 2007, donde introdujeron el concepto de carriles de natación para mantener los elementos de trabajo relacionados, juntos. La implementación y difusión del éxito en Corbis despertó el interés en otras empresas sobre el método Kanban.
Karl Scotland escuchó sobre el método Kanban en una conferencia de Agile en 2007, de la mano de David Anderson, de manera que decidió introducirlo en su equipo de Yahoo! ya que tenían un problema de duración del sprint con Scrum. La implementación fue tan exitosa, que Karl se convirtió en uno de los primeros y más prominentes defensores del método Kanban.
2009: el año dorado para Kanban
En enero de 2009, Corey Ladas publica el libro Scrumban: Essays on Kanban Systems for Lean Software Development, un intento de gusion entre Scrum, Lean y Kanban.
En abril del mismo año, Henrik Kniberg publica Kanban vs. Scrum: A Practical Guide, un artículo donde se cubren los principios de Kanban de manera fácil de entender.
En mayo, en la conferencia Lean Kanban 2009 organizada por Anderson en Miami, se presentaron los últimos desarrollos en la aplicación del Pensamiento Lean al desarrollo de software. Después de esta conferencia, se formó la Sociedad Informal del WIP Limitado, con la misión de unificar y difundir el conocimiento sobre el método Kanban. Esta sociedad proporcionó una plataforma para la agregación de artículos sobre Kanban, que ayudó a aumentar aún más la conciencia del método.
También en 2009 se lanzaron las primeras aplicaciones web para gestionar proyectos y procesos empresariales con el método Kanban: Agile Zen, Kanban Tool y LeanKit Kanban.
2010 en adelante: Kanban para todos
A medida que el conocimiento y el uso de Kanban se popularizaba, quedó claro que Kanban funciona en el desarrollo de software y también en cualquier proceso que contenga repeticiones (fabricación, ventas, marketing, reclutamiento, etc.). Incluso el ejército de Estados Unidos empezó a adoptar sus principios.
En marzo de 2010, Henrik Kniberg y Mattias Skarin publicaron Kanban y Scrum – Making the Most of Both. En abril del mismo año, David Anderson publicó Kanban: Successful Evolutionary Change for Your Technology Business. En 2011, Jim Benson y Tonianne DeMaria Barry publicaron Personal Kanban. Poco a poco, empezaron a aparecer numerosos otros libros y artículos en línea sobre Kanban, documentando experiencias individuales y sus diversas aplicaciones.
En 2016, se publicó Essential Kanban Condensed, donde se destilan las 5 prácticas de este método que explicaremos más adelante.
Kanban ¿para qué?
Como hemos visto en el apartado anterior, el método Kanban lo podemos utilizar en una variedad de contextos para mejorar la gestión y el flujo de trabajo.
Determina si Kanban es adecuado para tu equipo
En la metodología Scrum, después de la Sprint Planning, el backlog queda congelado, de manera que no se pueden hacer cambios en él. Ese estado suele durar unos 15 días por lo general, lo que puede llegar a generar frustración tanto para los desarrolladores como para los clientes finales.
¿Qué hacemos si hay una emergencia y una función específica necesita ser implementada ASAP?
¿Qué hacemos con todos los bugs descubiertos en el producto en vivo: los clientes finales necesitan esperar entre dos semanas y un mes para que los arreglen?
¿Cómo manejamos procesos que son más dinámicos por naturaleza, como el marketing de sitios web o la administración de servidores?
El método Kanban, con sus tableros Kanban y enfoque en el flujo, se convierte en una respuesta a estas dudas, proporcionando una forma altamente estructurada, visible y flexible de gestionar el trabajo.
Otras preguntas que puedes hacerte en tu equipo para ver si Kanban es el modelo que más se ajusta a tus necesidades son:
- Desde una perspectiva de Agile Máster, Agile Coach o Product Owner:
- ¿El equipo sabe identificar y plasmar de forma visual el flujo de trabajo?
- ¿Tienen cuellos de botella? ¿Están identificados?
- ¿Son conscientes del trabajo que realizan entre ellos?
- ¿Demandan flexibilidad para adaptarse a la demanda impredecible que les atropella constantemente?
- ¿Qué nivel de estructura buscan en la gestión de proyectos y procesos?
- Preguntas para realizar al equipo:
- ¿Tenéis dificultad para gestionar las tareas del Sprint?
- ¿Qué método de estimación utilizáis? ¿Creéis que os funciona?
- ¿Tenéis visible y compartido algún tablero de trabajo? ¿Lo entendéis?
- ¿Consideráis que hay transparencia y comunicación en el equipo?
- ¿Estamos dispuestos a comprometernos con la mejora continua y a empezar a experimentar cambios?
- ¿Os gustaría tener más autonomía y responsabilidad en la gestión propia del trabajo?
- ¿Qué aspectos del proceso actual mejoraríais u optimizaríais?
- ¿Existen acuerdos de equipo?
- ¿Compartís la misma visión y entendéis lo mismo para cada estado de trabajo?
Kanban es mucho más que un tablero bonito con Pósits de colores moviéndose cada día. Es una herramienta que nos permite la optimización de un proceso mediante su visualización. Nos ayuda a mejorar los flujos de trabajo en cualquier proceso productivo.
Las 5 practicas del libro Essential Kanban Condensed son:
- Visualizar el flujo de trabajo
- Limitar el trabajo en curso
- Medir y gestionar el flujo
- Definir políticas explicitas
- Implementar ciclos de feedback
- Evolución experimental para la mejora colaborativa
1-Visualizar el flujo de trabajo
Visualizar el flujo de trabajo es crucial, y uno de los principios esenciales del método Kanban. Con la visualización, obtenemos transparencia. Al tener un mismo tablero con todos los elementos de trabajo visibles para el equipo y la organización, todos tienen claro qué hay que hacer, en qué estoy o están mis compañeros trabajando, cuándo se espera que se complete el trabajo, y qué hemos entregado.
La visualización te ayudará a entender bien cómo está trabajando actualmente el equipo, lo que a su vez te permitirá descubrir por qué se hacen las cosas de esta manera descubrir por qué se hacen las cosas de esta manera y posteriormente podrás tomar decisiones concretas y objetivas para mejorar.
¿Cómo visualizamos el flujo de trabajo?
El flujo de trabajo es la secuencia de pasos que las tareas o el producto atraviesa des del inicio hasta la finalización o entrega. En Kanban, la visualización del flujo significa mapear pasos distintivos del trabajo en las columnas del tablero Kanban y seguir los elementos de trabajo mientras se avanza a través de estos estados. El simple hecho de nombrar estos estados puede revelar hechos sobre tu flujo que no conocías, incluso detectar cuellos de botella.
Los pasos para identificar el flujo de valor son:
- Identificar el flujo: el mapeo del flujo es el proceso mediante el cual ponemos un nombre a los estados por los que pasa la tarea, estados que agregan valor. Puedes ayudarte con verbalizar las actividades (analizar, desarrollar, testear, etc.). El flujo debe proporcionar claridad, facilitando saber en qué acciones nos debemos centrar y cuáles debemos minimizar porque no tienen sentido para el cliente final, lo que nombraríamos como “desperdicio”.
- Identifica el alcance del trabajo: una vez se haya dibujado el flujo de valor, el equipo tiene que decidir qué partes de él controlamos, en qué queremos centrarnos y cómo lo visualizaremos en un tablero Kanban. Si consideramos el flujo como un mapa, debemos marcar el camino por el que pasan las tareas. Cuanto mas estrecho y uniforme sea el equipo que trabaja en el flujo, más simple será la gestión del trabajo. Trata de no incluir ningún paso del proceso sobre el cual el equipo no tenga voz ni impacto, ya que creará incertidumbre y confusión.
- Asocia las etapas del flujo de trabajo a columnas en un tablero: puedes apoyarte en un tablero físico y visible en la oficina o bien utilizar una herramienta digital como Jira. Divide el tablero en columnas, cada una de las cuales será una etapa del flujo, de derecha a izquierda. Si tienes distintas clases de servicio, puedes ayudarte de swimnlanes para dividirlos en filas horizontales.
- Define los tipos de trabajo y qué significa el concepto de “Done” o entregado para el equipo: el primer paso es definir los tipos de tareas en los que trabaja el equipo y diferenciarlos con iconos o colores. Asegúrate de que el equipo conoce el significado de cada color o icono y cuáles son las definiciones que habéis acordado para cada elemento de trabajo.
- Define sobre una plantilla de tarjeta cada elemento de trabajo: para cada elemento de trabajo, define con el equipo qué información esencial se debe ver y qué se espera en cada tarjeta. Se pueden definir distintas plantillas de tarjetas en función de los tipos de trabajo o entregables que tengamos, donde se resalten y faciliten el intercambio de información mínima imprescindible.
- ¡Empieza a trabajar!: ahora que has definido colores, formatos, iconos, columnas y swimlanes, y el template de las tarjetas, ya puedes empezar a colocarlas en las columnas relevantes del tablero, según el estado de trabajo que se encuentren actualmente. Dentro de las columnas individuales, ordena las tarjetas según prioridad. La tarjeta más urgente debe ir en la parte superior seguida de la segunda más urgente y así sucesivamente. Con esto, solventamos el clásico problema de si todo es urgente, entonces nada lo es.
- Realiza un seguimiento del flujo y revisa el proceso periódicamente: seguir el flujo de estados te permitirá ver los cuellos de botella, los bloqueos y los estados donde el equipo se encuentra sobrecargado. Es crucial que el tablero se visite diariamente y que las tarjetas estén actualizadas para visibilizar.
2-Limitar el trabajo en curso (WIP)
Limitar el WIP (Work in Progress) es una característica fundamental de Kanban. Puede parecer contraintuitivo de primeras.
¿Le estamos diciendo a los equipos que trabaje menos?
No. Limitar el trabajo en curso significa limitar cuantas tareas pueden llevarse a cabo simultáneamente, no limitar el trabajo a realizar. Con esto, reducimos los tiempos de espera como los ciclos.
¿Por qué limitar el trabajo en curso?
- Fomenta una cultura de finalización del trabajo: empieza a terminar, deja de empezar. ¿Qué prefieres, tener 40 productos a medio camino de ser lanzados o 25 lanzados y generando ingresos? Limitar el trabajo significa centrarse en esos 25. La limitación ayuda a concentrarse en las tareas, lo que promueve terminar antes y monetizar. ¿Cómo nos ayuda esto con los blockers? Imagínate que tu equipo está trabajando en los 40 productos a la vez, si hay un incidente grave, tendrá que paralizar el trabajo de esos 40 productos. ¿No es mejor paralizar 25?
- Minimiza la multitarea y el caos: si limitamos el trabajo en progreso, reducimos el ruido y gestionamos mejor el caos. Si te lanzo una pelota de tenis, la cogerás fácilmente con las dos manos. Si te lanzo dos pelotas al mismo tiempo, puedes coger una con cada mano, coger solo una, o no coger ninguna. ¿Y si te lanzo 10 pelotas de golpe? Probablemente no cogerías ninguna: caos. Sucede lo mismo si trabajamos en muchas tareas a la vez. Mantener el enfoque constante en una tarea mejora la calidad del trabajo.
¿Cómo empiezo?
- Observa el proceso e identifica cuellos de botella: observa el tablero, fíjate si el equipo está sobrecargado, así podrás identificar cuellos de botella.
- Ajusta el límite del WIP: limita el trabajo en curso a la capacidad del estado del flujo más lento. Habla con el equipo, analiza por qué se crea un cuello de botella en ese paso (¿faltan recursos? ¿Son permisos? ¿Tal vez dependencias externas?).
- Analiza y revisita los límites: a medida que el proceso cambie, el equipo crezca, disminuye o cambie, es posible que necesites ajustar el límite.
3-Medir y gestionar el flujo
¿Pero qué es el flujo?
El flujo es el camino por el que pasa el trabajo por varios departamentos o varios niveles de producción. Es la experiencia única de cada trabajo que viaja a través del proceso.
¿Una tarea puede moverse por los estados sin problemas, o puede tener alguna interrupción en un estado?
Seguramente en algún momento te habrá frustrado empezar una tarea y tener que pausarla una o varias veces porque necesitas que alguien te confirme algún detalle, que te den permisos, o incluso que haya salido otra tarea más urgente que debes resolver inmediatamente. En estos casos, el flujo se interrumpe.
En la primera practica hemos visto como visualizar el flujo, en la segunda, como se mueven las tareas mediante el flujo. Midiendo y gestionando el flujo analizamos cómo estas dos rutinas impactan en el flujo y lo mejoramos.
¿Cómo lo medimos?
Con reuniones diarias o Daily Kanban. En estas reuniones que suelen hacerse a primera hora de la mañana entre 30 y 45 minutos, se analiza como el trabajo se va moviendo de un estado a otro. Puedes ayudar al equipo a identificar cuánto tiempo los lleva que una tarea se mueva de una columna a otra. Cuando las tareas se bloquean o se atascan en las columnas, tenemos que preguntarnos el por qué. A partir de ahí, podremos empezar a pensar qué acciones vamos a realizar para remediarlo.
Lo importante no es que las tareas se muevan rápido, sino la suavidad con la que se mueven de principio a fin, es decir, sin bloqueos.
Te propongo algunas preguntas para hacer en la Daily Kanban:
- ¿Alguien está bloqueado?
- ¿Con qué te puedo/podemos ayudar para desbloquearte?
¿Qué métricas puedo utilizar?
- Diagrama de flujo acumulativo: con esta métrica podrás ver la cantidad de trabajo en progreso que hay en cada estado. La uniformidad de este diagrama te dirá qué tan uniforme y predecible es tu equipo.
- Lead Time y Cicle Time: el Lead Time mide el tiempo de entrega, es decir, hace un promedio de tiempo entre que se empieza a trabajar en una tarea (In progress) hasta que se entrega (Done). El Cicle Time mide el tiempo des de que la tarea entra como petición en el backlog (To Do) hasta que se entrega (Done). Con estas dos métricas podrás saber y predecir el tiempo que tarda el equipo en producir.
Gestionar y medir el flujo te ayudará a:
- Mejorar el proceso en general y dejar de apagar incendios;
- Mejorar la previsibilidad del proceso;
- Madurar el proceso y te ayudará a entender que es menos importante; y
- Prever de forma objetiva los tiempos.
4-Definir políticas explicitas
Las personas solemos hacer suposiciones sobre todo lo que nos rodea. Algunas veces de manera inconsistente, otras conflictivas. Esto suele provocar malentendidos y que el trabajo en equipo sea ineficaz. El proceso repetitivo y la calidad de la ejecución de cada paso es lo que termina el éxito del trabajo realizado. También orienta al equipo sobre cómo tomar decisiones, de manera que les permite avanzar en el proceso de la mejor manera posible.
¿Qué entendemos por política en Kanban?
Una política en Kanban se refiere a un conocimiento común sobre qué se debe hacer en cada estado de trabajo para poder pasar al siguiente. El objetivo final es que se convierta en una rutina del equipo, de manera que les ayude a mantener el flujo.
Ten en cuenta lo siguiente:
- Nosotros somos los dueños del proceso, no al revés. Los procesos no nos pertenecen.
- Sé pragmático al definir las políticas.
- Crea un control visual que te permita ver qué trabajo está ejecutándose y qué pasos siguen a cada estado.
- Las políticas han de ayudar a los equipos a ser autoorganizados y a desarrollar relaciones.
Imagina las políticas de tu equipo como el Puente Golden Gate, tienen que ser fuertes para que el trabajo fluya sin problemas ni futuros incidentes. Cuando veas que las tareas suelen atascarse en algún estado, aprovecha para hacer preguntas sobre qué podemos mejorar o introducir para que esto no suceda.
Las políticas tienen que definir qué necesitamos que esté hecho de cada estado de manera simple y visual. Las siguientes preguntas pueden ayudarte a establecer políticas con tu equipo:
- ¿El equipo tiene claro el flujo de trabajo, dónde empieza una tarea y dónde termina?
- ¿El equipo sabe cuáles son los pasos de control de calidad?
- ¿El equipo entiende lo mismo por “terminado” en cada etapa del flujo?
- ¿El equipo sabe cómo priorizar una tarea urgente y la implicación que tiene para ellos y el flujo?
- ¿El equipo tiene claro cómo tratar las tareas no planificadas y cómo encajarlas en el flujo?
- ¿Cómo se tratan los incidentes que se encuentran en el proceso? ¿Detienen lo que están haciendo todos y solucionan el error? ¿Vuelven a poner la tarea del incidente al backlog?
5-Implementar ciclos de feedback
“Kanban debería conducir a la mejora diaria, la mejora de todos y la mejora en todas partes.” (Masaaki Imai)
Kanban es una metodología que toma cada iteración como una nueva oportunidad de mejora. Con Kanban no necesitas cambiar de inmediato, sino comenzar exactamente desde donde estás, simplemente observando, a partir de aquí, puedes trabajar en los 5 pasos de enfoque de la Teoría de las Restricciones:
- Identifica los cuellos de botella: observa el tablero y como fluye el trabajo para identificar donde el flujo de trabajo cambia drásticamente y se estanca.
- Explota los cuellos de botella: los cuellos de botella no coinciden con la capacidad de otros estados de trabajo. Sabiendo que la velocidad a la que el cuello de botella completa el trabajo es la velocidad de finalización del trabajo de todo el sistema, decide cómo suministraras mejores recursos a este estado más lento. Hazlo a un ritmo que no abrume al flujo ni al equipo.
- Subordinar todo a los cuellos de botella: el flujo de trabajo y las políticas establecidas tienen que estar sincronizadas con el paso del proceso más lento, de manera que se eviten o minimicen los impedimentos.
- Elevar los cuellos de botella: necesitarás fortalecer el estado invirtiendo en mejoras como son los recursos, el limite de estados u otras alternativas que consideres.
- Observar donde ocurren los cuellos de botella: es importante monitorear el proceso. Es común que haya cuellos de botella, de manera que tendrás que repetir los pasos 2 a 5 para resolverlos.
La eliminación de desperdicios o Muda te ayudará a analizar las tareas actuales en el flujo de valor y a identificar aquellas que no agregan valor directo a tu producto o proyecto. Si tu equipo responde a siempre se ha hecho así cuando les preguntas por algún paso, es hora de cuestionar el propósito y cambiarlo.
Es importante que como líder identifiques los desperdicios y los distingas entre los necesarios y los innecesarios. Reducir las actividades que no están directamente relacionadas con el valor del producto te permitirá mejorar.
La confianza en el cliente se gana cuando un servicio es confiable y predecible. (W. Edwards Deming)
6-Evolución experimental para la mejora colaborativa
Para estar alineados con la mejora continua de Kanban, podemos utilizar los ciclos PDCA.
Los ciclos cortos de PDA se basan en:
- Plan: se identifica una actividad a mejorar y se comunica al equipo. Idealmente, todos los involucrados deberían estar incluidos en el proceso de mejora.
- Do: en este momento se ejecuta el plan del paso anterior. Este, tiene que estar en línea con la implementación de políticas y procedimientos explícitos. Toma medidas tangibles que hayan salido del paso anterior.
- Check: evalúa las acciones llevadas a cabo en el paso anterior. Vincúlalas con la gestión y la medición del flujo de Kanban de tu equipo.
- Act: entendemos actuar como evaluar si los cambios que hemos realizado en la etapa anterior han dado resultados positivos o esperados. Si no lo han sido, significa que se pueden eliminar, ajustar o mejorar. En este caso, volveríamos a empezar des del primer paso.
Como empezar
Si quieres que te ayudemos a empezar con Kanban, puedes contactarnos, o puedes seguir esta guía simple.
En la primera fase, la de levantamiento, es importante que, como Agile Master, te reúnas lo antes posible con el equipo y el Product Owner para entender la demanda.
Análisis de la Demanda
Como Agile Máster, hacer el análisis de la demanda como primer paso te ayudará a:
- Comprender el contexto: al aterrizar en un equipo es importante que entiendas el entorno en el que opera el equipo, las expectativas de sus stakeholders y las necesidades de Negocio con respecto al equipo. Esto te ayudará a tener una primera imagen e idea que te ayudará, posteriormente, a planificar y ejecutar las actividades de mejora y la implementación de Kanban.
- Identificación de prioridades: analizando la demanda, podrás identificar las prioridades del equipo. A su vez, verás si el equipo comparte las mismas prioridades, si están establecidas o si tienes que hacer hincapié en ellas. Con las prioridades claras y compartidas, podrás ayudar al equipo a hacer una asignación efectiva de recursos y esfuerzos para abordar los desafíos que tienen.
- Alcance de mejoras: cuando realices el análisis de la demanda, tanto tu como Agile Máster como el equipo mismo identificareis oportunidades de mejora en áreas donde se pueden implementar cambios. Es muy probable que el equipo tenga ya claras esas áreas de mejora. Déjales hablar, escúchalos y anota sus preocupaciones, inquietudes e ideas.
- Alineación con los objetivos de Negocio: una vez analizada la demanda, podrás ver si el equipo está alineado con los objetivos y las prioridades de Negocio. Verás también si entregan valor real, y en caso de que no sea así, podrás ayudarles a cambiar los flujos para que así sea.
Reúne al equipo al completo, preferiblemente in situ en las oficinas. Si no puedes reunirlo presencialmente, hazlo online y apóyate de herramientas visuales como Miro.
El objetivo de analizar la demanda del equipo es entender:
- Quién pide al equipo
- Qué les piden
- Cómo les llegan estas solicitudes (chat de Teams, correo, petición de Jira, charla informal, etc.)
- Qué porcentaje de la demanda total representa cada solicitud
- Cómo priorizan cada tipo de solicitud, sea por clase de servicio o por solicitante
Te puedes apoyar en las siguientes preguntas a realizarles:
- ¿Quién es vuestro Business Owner? ¿Centraliza todas las peticiones que recibís de negocio?
- ¿Cómo os hace llegar vuestro Business Owner las peticiones?
- ¿Os prioriza el Business Owner las distintas peticiones de negocio que os hace llegar?
- ¿En caso de que no tengáis un solo Business Owner, qué personas de Negocio os hacen solicitudes?
- ¿A qué departamentos o productos pertenecen estos Business Owners o solicitantes de Negocio?
- ¿Por qué canal os hacen las solicitudes?
- ¿Tenéis reuniones periódicas con ellos o un espacio dónde hacer las peticiones y hacer seguimiento de las iniciativas?
- ¿Os llegan solicitudes de vuestro Head of Product? ¿Qué tipo de solicitudes son? ¿Por qué canal os llegan? ¿Suelen ser urgentes?
- ¿Otros equipos os realzan solicitudes?
- Qué clase de solicitudes son (cross, dependencias, ¿etc.)?
- ¿Por qué canal os llegan las solicitudes de otros equipos?
- ¿Qué porcentaje de cada solicitante representa la carga habitual de trabajo para el equipo?
- ¿Cómo priorizáis esta demanda?
- ¿Cómo gestionáis las demandas urgentes de los distintos solicitantes? ¿Tenéis una matriz o acuerdos de equipo sobre la priorización de la demanda?
- ¿Os sincronizáis con otros equipos con los que tenéis proyectos o iniciativas conjuntas?
- ¿Todas las solicitudes están en Jira? ¿Quién crea los tickets?
- ¿Los tickets de Jira están detallados con toda la información? ¿Quién detalla esta información? Y ¿cuándo (Planning, replenishment, dailies, etc.)?
- Si el equipo no tiene claro lo que se pide en un ticket, con quien lo gestiona (con el Product Owner, con el Business Owner, solo, ¿etc.)?
- ¿Tenéis una plantilla en los tickets de Jira con la información necesaria (qué se necesita, para qué, pasos a seguir, etc.)?
- ¿Tenéis Definition of Done y Definition of Ready compartidos y visibles en Jira para el equipo?
Con la ayuda de estas preguntas, iréis anotando en distintos Pósits el análisis de la demanda. Es recomendable que se utilicen distintos colores de Pósits por tipo de información (solicitante, porcentaje, urgencia, categoría de la solicitud, etc.). De esta manera será más visual.
Incentiva que sean ellos también quienes muevan los Pósits o las flechas si es necesario, hazles participes del proceso, tienen que entender que el ejercicio también es importante para que ellos compartan cómo ven la demanda y cómo la entienden.
Mapa Producto, Negocio, Equipo
Ahora que tenemos la demanda dibujada de una forma visual y compartida con el equipo, es hora de detallar un poco más como se relaciona respecto a las tecnologías, la predictibilidad y el equipo.
Con este ejercicio, podrás hacer:
- Alineación estratégica: relacionando la demanda con los productos, el negocio, la tecnología y el equipo te proporcionará una visión clara de si el equipo se encuentra alineado con la estrategia general de la organización. De esta manera, podemos ayudarle a evitar los desperdicios de tiempo y recursos que no contribuyen directamente a los objetivos de la organización.
- Identificar oportunidades: podrás analizar las tecnologías utilizadas por el equipo actualmente y ver si se pueden mejorar. De esta manera, se podrán resolver incidencias, mejorar la eficiencia, y proporcionar un entorno seguro donde se almacenan y des de donde se trabajan los datos del equipo.
- Predicción y planificación: al entender como se relacionan los productos con las tecnologías, podemos predecir mejor los plazos de entrega. De esta manera, podremos reducir la incertidumbre y ayudar a garantizar la entrega rápida y sin incidencias.
Parte del dibujo de la demanda para reunirte con el Product Owner y hacerle las siguientes preguntas para cada clase de solicitud:
- ¿Qué tipo de entregable representa esta solicitud? ¿Es un .csv, un Excel, un producto, un SQL, etc.?
- ¿Cuántas personas del equipo trabajan en esta solicitud?
- ¿A quién le llega esta solicitud? ¿Por qué canal? ¿Cómo se lo transmites al equipo?
- Qué tecnologías se ven implicadas para dar respuesta a esta solicitud (Tableau, Redshift, OnPrem, ¿etc.)?
- ¿Qué predictibilidad tiene esta clase de solicitud? ¿Es estándar? ¿Es expedito? ¿Hay deadline? ¿Es planificable? ¿Se queda en el backlog para cuando tengamos más capacidad?
- ¿Con qué urgencia categorizarías esta solicitud? ¿Te es fácil planificarla para el siguiente sprint o las siguientes dos semanas? ¿Lo categorizas como Blocker y paralizas todo para que lo entreguen lo antes posible? ¿Se queda en el backlog?
Es importante identificar las tendencias y los patrones en las solicitudes para entender mejor las necesidades de Negocio.
Análisis Productos o Servicios del equipo
En este paso, una vez hemos hecho el análisis de la demanda, y hemos identificado como esta demanda se relaciona con el Negocio y el Equipo, vamos a analizar los Productos que tiene el equipo junto con el Product Owner.
Analizar los productos o servicios que proporciona el equipo te ayudará a:
- Optimizar el flujo de trabajo: de manera que identifiquemos posibles áreas de mejora en el flujo. Al entender mejor cómo gestionamos y cómo entregamos los productos podemos identificar los cuellos de botella, las ineficiencias en los procesos y empezar a trabajar en resolver dichos problemas o mejoras.
- Identificar oportunidades de mejora: el equipo será consciente de cómo trabajan y podrán detectar oportunidades para mejorar la eficiencia, la calidad y la satisfacción de Negocio. En este punto, podremos incluir la optimización de procesos con automatismos, o rediseñando el flujo que tenemos actualmente, introducir o apostar por nuevas tecnologías como puede ser Cloud, adoptar nuevas practicas o establecer o revisar las prioridades del equipo.
- Alineación con las necesidades de Negocio: al entender y poner de manifiesto los productos del equipo existentes y su prioridad e impacto en el Negocio, alinearemos mejor el trabajo del equipo con estas necesidades y objetivos. De esta manera, garantizamos que el equipo trabaje en las áreas de mayor impacto y valor para la organización.
Para ello, te puedes apoyar de las siguientes preguntas:
- ¿Cuáles son los productos que entra el equipo?
- ¿Cuál es el objetivo y la visión del producto?
- ¿Con qué tecnología se relaciona el producto en la creación y la entrega del producto?
- ¿Quién es el principal cliente del Producto? ¿Quién lo va a utilizar?
- ¿Cuál es la frecuencia de entrega del Producto?
- ¿Qué tan predecible es el proceso de entrega del Producto?
- ¿Qué feedback recibimos de las entregas de Producto?
- ¿Cómo gestionamos ese feedback y cómo llega al equipo?
- ¿El equipo es consciente de las oportunidades de mejora de los procesos de los Productos?
- ¿Cómo recibes, como PO esas oportunidades de mejora des del equipo?
- ¿Cómo las priorizas?
- ¿Cómo llega al backlog?
- ¿Cómo se comunican esas mejoras a Negocio?
¿Pasamos a Kanban?
Si el equipo está trabajando en Scrum y no funciona porque la demanda no es planificable, les atropella los sprints, no tienen claro el flujo de trabajo, los roles están muy especializados, y no hay visibilidad ni transparencia sobre el trabajo que están realizando el equipo, adoptar la metodología Kanban te ayudará a:
- Mejorar la flexibilidad en la gestión del trabajo: con Kanban obtenemos mayor flexibilidad en la gestión de las tareas y proyectos. Mientras que, en Scrum, las iteraciones son fijas y no permite flexibilidad para la demanda no planificada, con Kanban podemos tener un flujo continuo de trabajo, con lo que mejoraremos la gestión de cambios de requisitos o prioridades.
- Enfoque en el flujo de valor: con Kanban nos centramos en optimizar el flujo de trabajo del equipo y en eliminar o reducir los cuellos de botella. Si Scrum te está generando cuellos de botella y un flujo de trabajo ineficiente, con Kanban puedes mejorar la velocidad de entrega.
- Visibilidad: con Kanban puedes dar más visibilidad al trabajo que se está realizando entre el equipo. De la misma forma, los stakeholders como Negocio o HPO pueden ver des del tablero de Jira el estado de las iniciativas, cómo estas se están priorizando y como avanzan. Con la visibilidad podremos identificar y atacar problemas que surjan de forma más rápida.
- Eliminación de sobre compromiso: en Scrum, el equipo se compromete a entregar una cantidad fija de tareas en un tiempo determinado. No significa que con Kanban el compromiso se vaya, pero a diferencia de Scrum, no genera frustración si el equipo no llega porque el alcance de tareas era mas complejo. De la misma forma, se fomenta la colaboración entre miembros del equipo para entregar las tareas conjuntamente y con mayor velocidad.
- Menos ceremonias: Scrum tiene cinco ceremonias, muchas de las cuales resultan ineficientes para los equipos o lo ven como una “pérdida de tiempo”. Kanban, tiene siete ceremonias, pero a diferencia de Scrum, son mas livianas y adaptables. Puedes adoptar aquellas que realmente te generen valor y te ayuden (por ejemplo, la gestión de los riesgos suele ser la menos utilizada por los equipos). Recuerda, la metodología tiene que estar al servicio del equipo, no al revés.
- Reducción de desperdicios: con Kanban podrás identificar y eliminar, siempre que se pueda, aquellos pasos del proceso que no tengan sentido y constituyen un problema para entregar valor. De esta manera, mejoraras la eficiencia y la productividad del equipo.
- Mejora del tiempo de entrega: cuando nos enfocamos en el “stop starting, start finishing” entregamos continuamente, minimizamos el trabajo en curso, y mantenemos el foco en las tareas que estamos haciendo, lo cual lleva a una aceleración de las entregas de producto.
