En nuestro equipo de desarrollo llevamos algo más de un año trabajando con Scrum.  Y ahora, para los pedidos de cambio, arreglos de bugs, mantenimiento de aplicaciones productivas y todo aquello que no llega a una iteración de Scrum, estamos abordando el uso de Kanban.

Nos viene bien una comparación de ambas herramientas metodológicas. Nos basamos en una guia práctica Kanban vs. Scrum, de Henrik Kniberg.

Scrum en pocas palabras

• organiza el equipo en pequeños equipos autogestionados y multidisciplinarios
• organiza el trabajo en una lista de entregables pequeños y concretos
• organiza el tiempo en iteraciones cortas, con código demostrable, al terminar cada iteración
• optimiza la planificación de versiones y actualiza las prioridades en colaboración con el cliente
• optimiza el proceso en cada iteración

Kanban en pocas palabras

• visualiza el flujo de trabajo: al separar el trabajo en items, escribir cada item en una tarjeta de la pizarra Kanban y utilizar columnas que ilustran el estado de la tarjeta.
• limita el trabajo en progreso: es recomendable asignar explicitamente cuantos items podemos tener en cada estado, un estado es una columna de la pizarra de Kanban.
• mide el tiempo de iniciación de un item: con el objetivo de optimizar ese tiempo

Kanban vs Scrum en pocas palabras

• ambas son herramientas de procesos, pero Scrum es más prescriptivo que Kanban.

• Scrum prescribe roles y no así Kanban.
• Scrum está basado en iteraciones, en Kanban, eliges iterar si te sirve para cerrar una versión.
• en Scrum, se usa el backlog del sprint para visualizar las tareas, entonces, si un equipo tiene una velocidad promedio de 10, usualmente, no pondrá más de 10 puntos de historia en un sprint. En Scrum, el trabajo en progreso (WIP - work in progress) es limitado por la unidad de tiempo. En Kanban, el WIP es limitado por estados del flujo de trabajo.
• Ambos son empíricos, es decir, que necesitamos experimentar con el proceso y adaptarlo a nuestro contexto. Uno de los puntos a tratar, en Kanban, es el límite de trabajo en progreso (WIP), entonces, podemos experimentar comenzando con un límite de 1. O bien, si trabajamos en pareja y el equipo Kanban es de 4 personas, usualmente podemos tener 2 items en progreso.
• Scrum, en general, no hace cambios en medio de una iteración.  En el caso de Kanban, podemos agregar un nuevo item en alguna de las columnas, pero si estamos en el límite, tenemos que remover algún item de esa columna.
• En Scrum, cuando termina el sprint, los items se sacan de la pizarra y comienza un nuevo sprint. En Kanban, los items persisten hasta que estén terminados.
• En Scrum, se tiene un equipo con todos los conocimientos necesarios para completar los items de la iteración. En Kanban, no necesariamente hay un único equipo relacionado a un item.

• Ambos procesos están basados en el desarrollo incremental.
• En Scrum, los equipos estiman. En Kanban, lo decide el equipo.
• Ambos procesos trabajan simultaneamente sobre múltiples productos. En Scrum, con diferentes pizarras. En Kanban, se diferencian los productos en la pizarra.
• Ambos procesos están alineados con los principios y valores de "Lean" y el "Manifiesto Agil".
• Scrum prescribe priorizar el backlog, En Kanban, podemos elegir algún esquema de prioridades. Scrum prescribe reuniones diarias de no más de 15 minutos. En Kanban, los equipos las hacen de igual manera. Scrum prescribe el gráfico de trabajo restante, por cada iteración. En Kanban no es un gráfico que tenga que usarse.

Conclusión: ¡tener presente al WIP!

El WIP (Work In Progress - Trabajo en Progreso) es el punto fuerte de Kanban, entonces cerramos la comparación con este tema. Si muchos items permanecen mucho tiempo sin ser asignados, nos da la pauta que el límite de items seleccionados es demasiado alto.

Límite Kanban demasiado bajo => personas ociosas => baja productividad Límite Kanban demasiado alto => tareas ociosas => tiempo de iniciación desfasado