KANBAN vs SCRUM

Quería compartir con  ustedes una breve comparación entre dos metodologías que están de moda estos últimos años. Ambas son ágiles, pero existen fundamentalistas de ambos lados, que dice que una es mejor que la otra. Entonces, ¿Cuál se adecuará mejor a tus proyectos? ¿Cuál es la tendencia mundial?

Antes que nada voy a hacer un breve repaso de ambas, para luego revisar las similitudes y diferencias para que podamos entender cuál es la mejor metodología:

Scrum en pocas palabras

• Divide tu organización en equipos pequeños, multidisciplinarios y auto-organizados.  
• Divide  el  trabajo  en  una  lista  de  entregables  pequeños  y concretos.  Ordena  la  lista  por  orden  de  prioridad  y  estima  el esfuerzo relativo de cada elemento. 
• Divide  el  tiempo  en  iteraciones  cortas  de  longitud  fija (entre 1  y  4  semanas),  con  código  potencialmente entregable y demostrado después de cada iteración. 
• Optimiza  el  plan  de  entregas  y  actualiza  las  prioridades  en colaboración  con  el  cliente,  basada  en  los  conocimientos adquiridos  mediante  la  inspección  del  entregable  después  de cada iteración.
• Optimiza  el  proceso  teniendo  una  retrospectiva  después  de cada iteración.

 Así  en  lugar  de  un  grupo  numeroso  pasando  mucho  tiempo construyendo  algo  grande,  tenemos  un  equipo  menor  pasando  un tiempo  más  corto  construyendo  algo  menor.  Pero  integrando  con regularidad para ver el conjunto.

Kanban en pocas palabras

• Visualiza el flujo de trabajo
• Divide  el  trabajo  en  bloques,  escribe  cada elemento en una tarjeta y ponlo en el muro.
• Utiliza columnas con nombre para ilustrar dónde está cada elemento en el flujo de trabajo.
• Limita  el  WIP  (Work  in  Progress,  trabajo  en  curso)  - asigna  límites  concretos  a  cuántos  elementos  pueden  estar  en progreso en cada estado del flujo de trabajo.
• Mide  el  lead  time  (tiempo  medio  para  completar  un elemento, "tiempo  de  ciclo"),  optimiza  el proceso  para  que  el  lead  time  sea  tan  pequeño  y  predecible como sea posible.

Kanban deja casi todo abierto. Las únicas normas son Visualiza tu Flujo de  trabajo  y  Limita  tu  WIP  (Work  In  Progress,  Trabajo  en  curso).  

¿En qué se parecen?

• Ambos son Lean y Ágiles:
• Tanto  Scrum  como  Kanban  son  sistemas  de  planificación  tipo "Pull", principio de gestión de inventario 'Just In Time' (JIT) propio de Lean. Esto significa que el equipo elige cuándo y cuánto trabajo acometer.  Ellos  (los  componentes  del  equipo)  "tiran"  del  trabajo cuando  están  listos,  en  contraposición  a  que  desde  el  exterior  se "empuje" al equipo a hacerlo. Al igual que una impresora tira de la siguiente página solo cuando esta lista para imprimir en ella (aunque tenga hojas de papel en la bandeja).
• Scrum y Kanban se basan en procesos de optimización continuos y empíricos, que se corresponden con el principio Kaizen de Lean.
• Scrum y Kanban dan más importancia a la respuesta al cambio que  al  seguimiento  de  un  plan  (aunque  Kanban  permite, típicamente,  una  respuesta  más  rápida  que  Scrum).  Uno  de  los cuatro principios del manifiesto ágil.  
• Ambos establecen límites WIP, Kanban lo limita por flujo de trabajo, Scrum por iteración (capacity).
• En ambos la visibilidad del proceso es la base de su mejora.
• Ambos tienen como objetivo la entrega temprana y frecuente de software.
• Ambos trabajan con equipos auto-organizados.
• Ambos necesitan la división del trabajo en partes.
• Ambos revisan y mejoran de forma continua el plan del producto en base a datos empíricos (velocidad / tiempo de entrega)

¿En qué se diferencian?

Scrum	Kanban
Iteraciones de tiempo fijo.	Sin iteraciones. La cadencia puede variar en funcion del plan de negocio y la mejora del proceso.
La métrica principal es la Velocidad (story points "done" por sprint).	La métrica principal es el Lead Time (tiempo medio que tarda una petición en salir del ciclo).
Equipos multifuncionales.	Sin restricciones, pueden ser multifuncionales o especializados.
El tamaño de las tareas no puede exceder la duración del sprint.	Sin restricciones, aunque se recomienda que todas sean de la misma longitud para tener mas previsibilidad.
Se utiliza el Burndown Chart como diagrama de seguimiento diario	No prescribe ninguno, aunque se recomienda el de Cumulative Flow Chart.
Se emplea una limitacion WIP indirecta (por sprint).	Se emplea una limitación WIP directa (por el estado del trabajo).
Se deben realizar estimaciones	Las estimaciones son opcionales.
No se pueden añadir tareas directamente en medio de una iteración. Hay que negociar con el dueño del Producto y el Equipo que se quita si se añade más trabajo. En general no está recomendado.	Siempre que haya capacidad disponible, se pueden añadir tareas.
El Backlog del sprint pertenece a un equipo determinado.	Varios equipos  pueden compartir la misma pizarra Kanban.
Se prescriben 3 roles (Product Owner, Scrum Master y Equipo).	No hay roles. Se pueden tener todos los roles que se considere necesario.
En cada sprint se limpia el sprint backlog.	El tablero de Kanban es persistente.
El Product Backlog debe estar priorizado.	La priorización es opcional, generalmente se priorizan los elementos próximos a desarrollarse.

¿Cuál es el mejor?

Todo depende del contexto en que lo uses. Por ejemplo, Scrum es lo ideal si se dan estas condiciones:

1. Posibilidad de tener una persona con suficiente tiempo de dedicación al rol de Product Owner (que tenga tiempo de tomar los requerimientos del cliente y escribir las historias de usuario; estar 100% disponible para el equipo de desarrollo; tiempo para mantener un Product Backlog priorizado y con suficientes historias de usuario detalladas para un sprint de trabajo; etc).
2. Scrum Master con disponibilidad 100% para el equipo, facilitando el trabajo de todos y quitando los impedimentos a tiempo.
3. Cantidad de trabajo suficiente de parte del cliente como para cubrir un sprint y que no queden tiempos muertos entre sprint y sprint.
4. Equipo de trabajo lo más auto-suficiente y auto-organizado posible, sin diferencias técnicas notables.
5. Los requerimientos son cambiantes, pero el cliente está más dispuesto a postponer el cambio a la siguiente iteración.
6. Estamos desarrollando un nuevo producto, lo cual implica un mínimos de trabajo suficiente para 3 meses y una mínima planificación de prioridades.

En cambio Kanban es más adecuado si por ejemplo:

1. La cantidad de trabajo de parte del cliente es muy fluctuante (a veces mucho, a veces no alcanza a la semana continua de trabajo) o la persona encargada de tomar los requerimientos al cliente (el PO en Scrum) tiene también otras asignaciones y su cadencia para llevar las peticiones al equipo de desarrollo es fluctuante.
2. El equipo de trabajo es demasiado especializado o con diferencias técnicas notables, donde se hace muy difícil la estimación del trabajo a realizar.
3. Los requerimientos son muy cambiantes o estamos en una fase de mantenimiento, donde el cambio debe llegar lo antes posible a producción y no podemos esperar a que termine un sprint.
4. Llevas múltiples productos al mismo tiempo. Kanban no discrimina entre productos, sino tareas en un flujo de trabajo.

Scrum es más restrictivo que  Kanban  ya  que  prescribe  cosas  como  iteraciones  y  equipos interdisciplinarios. Kanban está más cerca del "hace lo que quieras", si bien esto parece muy ágil, hay que tener en cuenta que la falta de límites también dificulta la gestión.

Si  haces  iteraciones  cada  vez  más  cortas, esencialmente te estás aproximando a Kanban. Una vez que se empieza a  hablar  de  hacer  durar  la  iteración  menos  de  una  semana,  se  debería considerar abandonar definitivamente las iteraciones a tiempo cerrado.

En cuanto a las reuniones diarias y las retrospectivas, recomiendo tenerlas en ambas metodologías.

¿Cuál es la tendencia?

Hasta el 2013, Scrum y sus variaciones (73%) siguen siendo las metodologías ágiles más populares. Kanban representa sólo el 5% aunque viene creciendo lentamente.

Final

Este tema da para hablar muchísimo más de lo que he puesto acá, si tenés alguna duda o algo para agregar no dudes en comentarlo. Tienes algún ejemplo o anécdota que quieras compartir?

Referencias

http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf