9º Encuentro Agile-Madrid. Kanban

Ayer se celebró la 9ª reunión del grupo local de Madrid en las oficinas de 11870.com. El tema de la reunión era Kanban, un tema que, particularmente, me resultaba muy interesante (en mi empresa soy "Kanban-master" de un equipo). A la llamada acudimos 10 caras conocidas (todos eramos "habituales" de las reuniones, aunque yo falté a las dos últimas...) dispuestos a aprender y compartir experiencias.

La reunión comenzó con una charla de Agustín Yagüe sobre los fundamentos de Kanban (Aquí tenéis la página de la reunión. Están las transparencias de la presentación y las lecturas recomendadas. De estas, yo recomiendo ésta. Muy buen artículo. Además, José Manuel Beas ha colgado el vídeo de la presentación aquí). Normalmente no empezamos así las reuniones pero la verdad es que estuvo bien comenzar con una pequeña introducción sobre el tema porque nos hizo adoptar un vocabulario común (el expresado en la presentación). Además, la gente que no conocía Kanban pudo entender por lo menos de que se iba a discutir en la reunión.

Después de la presentación, Agustín preparó un pequeño ejercicio práctico en el que los asistentes simulábamos un proceso guiado mediante Kanban. La verdad es que fue muy divertido y bastante instructivo.

Lo que me llevo sobre Kanban de la reunión es lo siguiente:

• Kanban es un sistema pull, es decir, no se hace nada hasta que te lo pida la siguiente fase (y la fase final es el cliente que demanda un producto).
• Kanban está basado en señales. En el caso del desarrollo de software esas señales son los post-it con las tareas a realizar y los movimientos de dichos post-it que, al dejar un hueco indican la posibilidad de crear algo.
• Los pilares de Kanban son limitar el trabajo en progreso (evitar la sobreproducción, es decir, no hacer más de lo que el cliente pida) y la mejora continua del proceso (cualquiera de los miembros del equipo es capaz de descubrir posibles mejoras en el proceso).
• Kanban necesita un workflow para funcionar. Dicho workflow puede ser tan simple o tan complicado como se quiera (Desde el típico ToDo-Doing-Done hasta flujos complejos).
• Kanban dice que los equipos deben ser multidisciplinares ya que, cuando una de las fases se convierte en un cuello de botella, las personas bloqueadas por dicha fase deben hacer todo lo posible por desbloquearla (Ayudando a la persona que está en dicha fase). Sin embargo, el basarse en un workflow implica cierto grado de especialidad (Tú vas a estar más tiempo en la fase a la que pertenezcas y menos en las otras, ya que en las otras solo estarás si las cosas van mal).
• Que Kanban sea capaz de modelar flujos complejos puede llevarnos a pensar en desarrollo "waterfall" con equipos específicos para cada taréa. Si bien Kanban te permite modelar un proyecto a la "waterfall" no hay que olvidar que Kanban es simplemente una herramienta y que depende del que la usa.
• Kanban, al limitar el trabajo en progreso de forma explícita evita el multi-tasking en los miembros del equipo, no como Scrum en el que es el propio equipo el que se autogestiona y decide si hace o no multi-tasking (aunque está claro que es una mala práctica hacerlo ;) ).

Lo que me llevo del nuevo formato de la reunión, ya que no pude quedarme a la retrospectiva es:

• Empezar con una introducción/presentación me parece muy buena idea, aunque quizás debería haber sido algo más corta. Ayuda a que todos los asistentes sepan de que se está hablando.
• Aunque nos vamos de hora (yo me fuí a las diez menos veinte y todavía quedaba la retro) me quedo con ganas de más :D
• Me perdí las cañas :(