Dulce introducción al Kanban!!

Bueno, parece que SCRUM ha puesto la pica en Flandes y se ha convertido en una metodología ampliamente conocida y respetada. Pues ya está, no? ya tenemos metodología ágil para cualquier tipo de proyecto y para siempre…

Muy confiado tienes que ser para creerte eso…

En mi trabajo hemos desarrollado un producto aplicando SCRUM con unos resultados muy satisfactorios. Dicho producto, se ha comenzado a implantar y ahora entra un equipo de soporte a mantener la primera versión del mismo y comienza una nueva rama de desarrollo de la siguiente versión.

Estaba planteándome como organizar el equipo de soporte y no acababa de encajar SCRUM sobre la naturaleza de su trabajo (la verdad que esta y cualquier otra metodología…). Es muy difícil organizarse para planificar incluso un pequeño Sprint, puesto que no se conocen las tareas de antemano. Por lo tanto, llegué a la conclusión de que necesitamos para este tipo de proyectos (que no son pocos) algo todavía más adaptable que SCRUM…

Tomando un café con el gran (aunque javero) Jorge Prieto me comentó algo sobre Kanban y comencé a tirar del hilo para ver si me podía cuadrar eso que sonaba a pescado crudo…

Así que vamos a aprovechar este post para explicar que es eso de Kanban compararlo con SCRUM e identificar sus conflictos potenciales. Antes que meternos en harina vamos a dejar las cosas claras, haciendo un pequeño resumen de SCRUM y Kanban

SCRUM (en pocas palabras)

  • Divide su organización en pequeños equipos auto-organizados y multidisciplinares.
  • Divide el trabajo en una lista de pequeños elementos muy concretos.
  • Ordenar la lista por orden de prioridad y estimar el esfuerzo relativo de cada elemento.
  • Dividido en iteraciones cortas de longitud fija (normalmente con entrega o demostración después de cada iteración.)
  • Optimizar el plan de liberación y actualizar las prioridades en colaboración con el cliente, sobre la base de conocimientos adquiridos por la inspección de la entrega después de cada iteración.
  • Optimizar el proceso por tener una retrospectiva después de cada iteración.

Resumiendo el resumen:

Pasamos de “Muchas personas haciendo algo muy grande” a “Pocas personas haciendo cosas pequeñas que se integran con regularidad para ver el conjunto.”

Kanbas (en pocas palabras también)

  • Visualizar el flujo de trabajo
    Dividir el trabajo en trozos escribir cada uno de los elementos en una tarjeta y poner en la pared.
    Usar el nombre o columnas para ilustrar en que estado se encuentra cada elemento dentro del flujo de trabajo.
  • Límitar WIP (Work In Progress)
    Asignar límites explícitos obre cuantos elementos pueden estar en cada uno de los estados del flujo de trabajo.
  • Medir el tiempo
    Contar el tiempo promedio para completar un tema, a veces llamado “tiempo de ciclo” y, como es obvio, optimizar el proceso para que el tiempo tan pequeño y previsible como sea posible.

image

 

Podemos observar que Kanban es todavía menos prescriptivo que SCRUM.

Prescriptivo significa “reglas para seguir”. 100% prescriptivo implica que no tienes que usar el cerebro, ridículo verdad?…) y en este apartado vemos que SCRUM aporta mas reglas “out-of-the-box” como por ejemplo encajar en un tiempo los Sprints cosa que Kanban no hace.

Para hacernos una mejor composición podemos observar la escala de “prescriptividad” (toma ya!) de forma gráfica:

image

Como siempre podemos decir que la mejor opción es no limitarse a un herramienta en concreto. Probablemente la solución nuestros problemas se encuentre en una combinación de varias. Muchos equipo Kanban realizan una reunión diaria a primera hora (típica liturgia de SCRUM). Algunos equipos de SCRUM que he conocido, escriben su Backlog como Casos de Uso (típico de RUP) o limitan el tamaño de las colas (típico de Kanbas).

Así que como siempre “haz las cosas como mejor te funcionen”, ya os contaré el resultado de aplicar esta forma de trabajo con el equipo de soporte.

Para terminar os cito a Miyamoto Musashi que los japoneses algo saben de todo esto:

“No desarrolles ninguna dependencia de arma o escuela de lucha”

8 comentarios en “Dulce introducción al Kanban!!”

  1. Hola Andoni:

    Mi experiencia es que Kanban funciona muy bien en situaciones como las que comentas, para equipos de soporte o, como yo lo he usado, para equipos de diseñadores que dan servicio a varios equipos de desarrollo que usen Scrum. Es muy dificil integrar ese tipo de actividades compartidas entre equipos y muy especializadas en el mecanismo de sprints de Scrum.

    Buena introducción a Kanban y me ha encantado el gráfico de ‘prescriptibilidad’.

    ¡Un saludo!

  2. Precisamente el otro día estuvimos en mi empresa hablado de kanban y lean manufacturing, yo lo conocí en la mi primera empresa (aplicado a procesos productivos que no eran software); En comparación con scrum ¿Con cual creeis que se necesita más involucración del grupo de trabajo(siendo esta siempre importante)? yo creo que en kanban ,ya que, al estar más dividido el trabajo en scrum no afecta tan directamente al proceso general.

  3. Pues la verdad es que en cualquier metodología adaptativa los miembros del equipo tienen bastante libertad y por lo tanto bastante responsabilidad, por lo tanto deben estar involucrados en ambas.

    Si tenemos en cuenta que Kanban es menos prescriptiva que SCRUM pues podemos decir que sí, pero realmente la diferencia no me parece significativa.

  4. La verdad que muy buena tu explicación de Kanban, desde hace días que quería buscar un post que lo explicara bien pero no tenia tiempo y hoy encontre tu sitio buscando algo q nada se relaciona con esto.

    Muy bueno.

    Saludos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *