Fue en 2012 cuando publiqué esta entrada hablando sobre este libro. Y desde entonces cada cierto tiempo lo repaso.

5 años me sigue pareciendo un ebook espléndido, conciso y preciso, con partes como:

Scrum en pocas palabras Kanban en pocas palabras
Divide tu organización en equipos pequeños, interdisciplinarios y auto-organizados. 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.

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. 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.
Divide el tiempo en iteraciones cortas de longitud fija (generalmente de 1 a 4 semanas), con código potencialmente entregable y demostrado después de cada iteración. Mide el lead time (tiempo medio para completar un elemento, a veces llamado "tiempo de ciclo"), optimiza el proceso para que el lead time sea tan pequeño y predecible como sea posible.
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.

O:

Comparando:

No te limites:

Importante:

SEMEJANZAS SCRUM Y KANBAN:

· Ambos son Lean y Ágiles.

· Ambos emplean sistemas de planificación "pull".

· Ambos establecen límites WIP.

· 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)

DIFERENCIAS ENTRE SCRUM Y KANBAN:

SCRUM KANBAN
Las iteraciones deben ser de tiempo fijo. El tiempo fijo en las iteraciones es opcional. La cadencia puede variar en función del plan del producto y la mejora del proceso. Pueden estar marcadas por la previsión de los eventos en lugar de tener un tiempo pre-fijado.
El equipo asume un compromiso de trabajo por iteración El compromiso es opcional.
La métrica por defecto para la planificación y la mejora del proceso es la Velocidad. La métrica por defecto para la planificación y la mejora del proceso es el Lead Time (tiempo de entrega o tiempo medio que tarda una petición en salir del ciclo)
Los equipos deben ser multifuncionales. Los equipos pueden ser multifuncionales o especializados.
Las funcionalidades deben dividirse en partes que puedan completarse en un sprint. No hay ninguna prescripción en cuanto al tamaño de las divisiones
Deben emplearse gráficos Burndown. No se prescriben diagramas de seguimiento concretos.
Se emplea una limitación WIP indirecta (por sprint). Se emplea una limitación WIP directa (marcada por el estado del trabajo).
Se deben realizar estimaciones. Las estimaciones son opcionales.
No se pueden añadir tareas en medio de una iteración. Siempre que haya capacidad disponible, se pueden añadir tareas.
La pila del sprint pertenece a un equipo determinado. Varios equipos o personas pueden compartir la misma pizarra Kanban
Se prescriben 3 roles (PP/SM/Equipo). No hay roles prescritos.
En cada sprint se limpia el tablero de seguimiento. El tablero Kanban es persistente
La pila del producto debe estar priorizada. La priorización es opcional.

Especialmente interesante es la parte II del libro en la que se analiza un caso de estudio, en el que se explica cómo superar las complejidades de una organización J.

(Seguro que los que me conocéis ya habéis adivinado con qué modelo comulgo más :D).