Lycka Bonita

En mi opinión, su punto más conflictivo de Kanban es su respuesta ante atascos en la cadena de producción. Kanban propone un límite en el trabajo (WIP, Work In Progress) que puede ser asignado a cada etapa de la cadena de producción. El WIP actúa como un cuello de botella artificial detectando tempranamente atascos en ambos lados de la etapa atascada: los trabajos se acumulan en su entrada, la alimentación de tareas a las etapas posteriores se detiene.

Kanban sugiere corregir esta ineficiente situación parando la producción de la cadena y que cada operario deja de trabajar en su puesto para ayudar a desatascar el problema. Una vez solucionado el problema se vuelve a la normalidad.

Kanban, en la práctica: nuestro problema

Hasta ahora no había tenido la oportunidad de enfrentarme a una situación similar en la vida real, además una situación similar al descrito en la imagen que acompaña esta entrada: no podemos desplegar una versión.

Nuestras circunstancias :

• Somos un equipo distribuido de 5 personas en 2 centros de trabajo a varios cientos de km de distancia.
• Se trata de un proyecto que nos ha sido entregado recientemente para que llevemos su mantenimiento correctivo y evolutivo.
• El proyecto está basado en versiones antiguas de tecnologías en cuya integración no tenemos conocimiento ni experiencia suficiente. Además presenta importantes puntos de mejora en más de un área.
• Una de las primeras cosas que hemos hecho al recibir el control del proyecto ha sido eliminar todo el código de pruebas… qué locura no? nuestras razones teníamos
• Partimos de un punto en el que el proyecto arranca, funciona y ha sido validado por los usuarios en un ambiente de preproducción.
• Nuestro primer objetivo, simplificar. Llevamos una reducción del 75% en el tamaño del WAR, en el tiempo de compilación y arranque, también una importante simplificación de la estructura del proyecto… pero no arranca correctamente.

En estas circunstancias, los desarrollos no pueden ser validados hasta conseguir arrancar el proyecto y comprobar si funcionan. Qué debemos hacer?

• Debemos parar todos los desarrollos y poner a todas las personas a reparar la línea base hasta conseguir desplegar esta versión?
• O debemos seguir cada uno con lo nuestro? Una persona o un equipo arreglando la línea base y el resto continuando con los desarrollos, que se validarán cuando la línea base se arregle?

Kanban, en la práctica: qué hicimos?

La primera semana después de romper la línea base seguimos al pie de la letra la recomendación de Kanban. Paramos la cadena de producción y nos pusimos todos a intentar que el proyecto arrancase nuevamente. 5 pollos sin cabeza, cero resultados, cero avance.

A la semana optamos por la segunda solución. Nos dividimos el trabajo.

Un centro se dedicaba a aprender e investigar sobre las versiones más modernas de las tecnologías y su integración, para después preparar la formación al otro centro y acometer la migración del proyecto a las nuevas versiones (arreglando la línea base en el camino).

El otro centro se dedicaba a sustituir partes de la arquitectura. Es decir queda fuera de la cadena de producción de código, pasando a trabajar en otra cadenas de montaje independiente (arquitectura). Cuando arreglemos el problema volverán a nuestra cadena para desarrollar pruebas desde cero.

Fallo de Kanban? Fallo en nuestra aplicación de Kanban? Nuestra respuesta es un atajo?

Creo que no, no y no. Creo que es un fallo en la gestión del proyecto, nunca debimos ir tan lejos sin conocimientos más avanzados en las tecnologías involucradas. Si hubiésemos abordado en primer lugar la (auto)formación no nos hubiésemos encontrado en esta situación que nos ha hecho perder al menos una semana de trabajo de 4 personas. Con la segunda solución retrasamos la salida de esta incómoda situación, pero al menos no desperdiciamos trabajo.

Hace algún tiempo os recomendé una página (Kanban and Scrum – making the most of both) para profundizar en Kanban, en Scrum, en metodologías ágiles y en cómo adaptar estas metodologías a las necesidades de tu proyecto u organización.

Si necesitas material para comenzar con Scrum, te recomiendo:

• Scrum and XP from the Trenches, libro de distribución gratuita en InfoQ y al que podéis contribuir voluntariamente comprando la versión impresa.
• Si queréis recursos en español, consultad Flexibilidad con Scrum primero y luego Scrum Manager Getión de Proyectos, ambos libros de distribución gratuita escritos por Juan Palacio (y el segundo también por Cristina Ruata) aunque podéis contribuir voluntariamente.

Ahora que ya dominamos la teoría de Kanban y Scrum, me gustaría resaltar tres puntos del enlace que nos ocupa (Kanban and Scrum – making the most of both).

Por un lado me he encontrado con la mejor definición de lo que es Gestionar un equipo (válida para cualquier disciplina): gestionar es ajustar una serie de parámetros para conseguir los objetivos previamente marcados (alcance, plazo, coste y calidad) y mejorar progresivamente el rendimiento del equipo.

Una imagen vale más que mil palabras:

Por otro lado una reflexión muy interesante sobre las organizaciones, de cómo practican la multitarea con sus proyectos. El departamento comercial suele tener unos incentivos muy fuertes para atraer y arrancar proyectos, pero no para acabarlos y entregarlos. Debido a que la prioridad es no dejar un cliente sin atender, los proyectos se arrancan inmediatamente asignando recursos que con el tiempo van saltando de proyecto en proyecto. Este enfoque es sustancialmente más lento que enfocarse primero en un proyecto hasta acabarlo, para luego pasar a otro y así sucesivamente: aunque los clientes esperen se entrega antes y con mejor calidad.

Esta imagen también es muy explicativa, pero la demostración que podemos ver en el recomendable video de la sesión que acompaña el enlace que nos ocupa definitivamente aclaratorio.

Finalmente me pareció muy interesenta modelo de niveles de aprendizaje : el concepto budista de Shu – Ha – Ri (defiende, rompre, abandona).

• Primero sigue todas las normas y principios, y los va siguiendo paso a paso mientras experimenta la disciplina, por ejemplo con acrónimos y rutinas.
• Cuando domines las normas, explora las excepciones, rompe las normas para adaptarlas a caso a caso.
• Finalmente podrás olvidarte de las normas, poco a poco, habrás interiorizado las disciplinas y la disciplina fluirá naturalmente (Tao).

Me viene a la mente la enooooorme decepción que siento por la comunidad ágil en España, salvo contadas y muy honrosas excepciones, abunda el “hype”, abunda personas en el estado Shu que se creen maestros divinos volviendo a la inquisición con una total falta de respeto. Seguro que cuando uno de ellos dice con total seriedad en una reunión que “no haremos más documentación ya que es una pérdida de tiempo, el código se debe autodocumentar” se podría pensar que como lo dice automáticamente se encuentra en en la fase Ri, o que como está rompiendo las normas al menos se haya en la fase Ha, pero no es el caso: no hacen más que repetir frases que han oído a terceros aplicándolas a un contexto erróneo (creo que aún todos los clientes no tienen la certificación en Java, y creo que el código tampoco vale de mucho a la hora de hacer un contrato) deshonrándose a sí mismos, a su empresa, a la profesión y al movimiento ágil. Y como este ejemplo, otros mil.

Me resulta increíble no haber escrito nunca nada de Kanban, supongo que los dos últimos años han sido una locura con Siniestros. He seguido algunas cosillas, tenía mi tablero en scrumy. Pero ahora con la distancia veo que tendría que haber seguido más al pie de la letra este sistema y haberlo integrado (perdón, quería decir impuesto) en el día a día del cliente, y de hecho recomendaría a mis ex's su implantación en especial en el llamado proyecto de la muerte.

Kanban, que en japonés significa "tablero visual", es un sistema visual para controlar y coordinar una cadena de montaje que se comenzó a utilizar en Japón a finales de los 40 para optimizar la implementación de metodologías de producción como Lean Manufacturing y Just in Time (JIT).

Su gran virtud es la sencillez, implementarlo y mantenerlo consume muy poco esfuerzo por lo que el seguimiento se simplifica. Además al ser visual permite detectar cuellos de botella muy fácilmente, cuellos que podremos solucionar mejorando ese proceso o aumentando la capacidad de trabajo en esa etapa.

Creo que Kanban es la mejor forma de trabajar en equipo en una cadena de montaje, y al fin y al cabo el software es una cadena de montaje (en la que primero se toman requisitos, luego se piensa qué hacer y cómo, luego se hace, luego se valida) en la que se trabaja en equipo, aunque le pese a los héroes ágiles standalone o yomeloguisotodo-yomelocomotodomenoselmantenimiento.

En pocas palabras, se parte de un repositorio de tareas (o backlog) y el objetivo es entregarlas todas. Para ello se divide un tablero en etapas sucesivas de la cadena de montaje, en las que el trabajo entra a la izquierda y se va propagando hacia la derecha. Cada columna o etapa de trabajo tiene un límite de trabajo concurrente que se puede procesar (WIP, work in process)… Pero espera, está explicado muy bien en navegápolis, y si te defiendes con el inglés en crip.se en este pdf (me pido Cartman!).

Y una imagen vale más que mil palabras, en este artículo, también en crip.se, podéis encontrar una tira de cómic que lo explica perfectamente:

Resulta muy natural complementar Scrum con Kanban, ya que no siempre resulta posible disponer de un equipo para mantenimiento y otro para desarrollo, o realizar iteraciones o retrospectivas. La principal diferencia entre amboses que Kanban limita el WIP por estado en flujo de trabajo y Scrum limita el WIP poriteración.

Personalmente prefiero completar el tablero con una fila superior para representar tareas periódicas, como reuniones diarias/semanales de seguimiento, retrospectivas cada 1 ó 2 semanas, cierres de mes o trimestres, previsiones de cargar de trabajo del mes o trimestre siguientes, auditorías seguridad o performance o calidad (SLAs), cursos o tiempos para investigación…

Dudas? Para saber más, Kanban and Scrum – making the most of both.