Scrum si se mezcla con Kanban

Siguiendo con mi lista de libros a leer por autor esta vez le tocó el turno a este libro ya clásico:

Libro escribo en el 2010

Definitivamente recomiendo las primeras cincuenta páginas del libro pues contienen un resumen de la esencia misma de Scrum en comparación con la de kanban. La segunda parte del libro contiene un caso de estudio del cual aprendí poco, pero fue gratificante leer que una viaja amiga Linda Cook es referenciada por un reporte de experiencia que ella escribió.

En las cincuenta primera paginas Kniberg describe muy fiel a su estilo los puntos en común y diferencias entre Scrum y Kanban, de esa descripción me quedo con lo siguiente:

  • Kanban tiene tres principios fundamentales que representan la simplicidad de su enfoque, a saber: visualizar el flujo de trabajo, limitar la cantidad de trabajo en proceso y medir el tiempo de ciclo. A través de la visualización del flujo se pueden detectar las actividad que contribuyen valor, las colas y tiempos reales de operación. Con esas entradas se intenta definir empíricamente el límite de cantidad de trabajo en proceso que a su vez tendrá un impacto directo en el tiempo de ciclo.
  • Kanban es una herramienta poderosa más no un marco de trabajo como lo es Scrum. El no ser prescriptiva y simple la convierte en un buen candidato para usarse en complemento (o reemplazo) de Scrum. Desde luego si se decide complementar Scrum con Kanban o viceversa el objetivo siempre debe ser permanecer dentro del paraguas filosófico de la agilidad y el pensamiento Lean.
  • Un tablero kanban es ciertamente más prolijo y detallado que un tablero Scrum e invita a cosas como por ejemplo que exista uno solo compartido por multiples equipos. Al igual que en Scrum, un tablero en kanban se presta a la experimentación y evolución a medida que el equipo decide irle haciendo adaptaciones.
  • Kanban enfatiza más el trabajo con piezas pequeñas y de tamaño similar lo cual en esencia facilita el flujo. Al no tener un concepto de Product Backlog que debe estar priorizado abre la puerta para mayor agilidad y trabajo de forma pull y no push.
  • En Scrum el trabajo en progreso es limitado por unidades de tiempo como la duración del Sprint, la jornada laboral o la estimación de una historia. En Kanban por el contrario el trabajo en progreso es limitado por el estado del flujo de trabajo. Esta diferencia conceptual fundamental hace que kanban incentive de mejor manera el flujo constante.

En resumidas cuantos puedo decir que vale la pena leer el libro y aun más vale la pena experimentar con kanban.