OPPA Kanban + Scrum Style

Recientemente alguien me hizo las siguientes preguntas:

1. ¿Cuáles son los principales inconvenientes de añadir las metodologías Kanban a Scrum?
2. ¿Podrías definir un tablero Scrum con las funcionalidades Kanban?
3. ¿Cómo introduces el concepto de WIP limit a un equipo Scrum?

A continuación mis respuestas:

1. ¿Cuáles son los principales inconvenientes de añadir las metodologías Kanban a Scrum?

Inicié mi respuesta comentando que no creo que Kanban deba llamarse “una metodología” de la misma forma que Scrum tampoco lo es.

Scrum por definición es un marco de trabajo (framework) y Kanban por definición es un método (que no es lo mismo que una metodología).

- No entiendo porque hoy en día a todo quieren llamarle metodología, no sé si piensan que la palabra suena cool, cuando creo que es todo lo contrario si no se conoce la real definición (disculpen, esto es para otra discusión).

Existe la idea de que Kanban y Scrum son dos cosas tan distintas que no pueden convivir, sin embargo, eso está muy lejos de la realidad.

Scrum al ser un marco de trabajo, sólo da una guía de qué es necesario HACER (las reuniones o ceremonias como se les conoce), TENER (los roles) y ENTREGAR (valor en forma de incrementos) para trabajar con Scrum, sin embargo en ningún lado de la guía oficial se menciona que no se puedan agregar prácticas, es más, la razón principal por la que se define como marco de trabajo y no como una metodología, es para dar esa flexibilidad y oportunidad a quién lo utilice de introducir las prácticas que mejor le beneficien en su proceso de entrega de valor.

Es por eso que un equipo que usa Scrum puede perfectamente introducir Kanban en su proceso como herramienta sin tener mayores inconvenientes, al contrario, utilizando un sistema Kanban (que no sólo es el tablero), pueden aumentar su efectividad en la entrega de valor y en la reducción de desperdicios (debido a la herencia que tiene Kanban de Lean).

Esto quiere decir que, si un equipo Scrum decide utilizar Kanban dentro de Scrum, puedes seguir llamándolo Scrum.

2. ¿Podrías definir un tablero Scrum con las funcionalidades Kanban?

- Pregunté, y con funcionalidades de Kanban se refería a WIP limits, políticas explicitas, etc.

A esta pregunta mi respuesta fue la siguiente: En la guía de Scrum no se menciona que el equipo Scrum debe trabajar de forma obligatoria con un tablero, no existe el concepto de tablero Scrum, lo que sí se menciona es que uno de los pilares de Scrum es la transparencia (que normalmente se promueve usando tableros físicos o digitales si son equipos distribuidos) por lo que la configuración de la herramienta de visualización y organización (llámese tablero) que decida utilizar el equipo, puede contener lo que permita que se llegue a tener esa transparencia, como por ejemplo, políticas explícitas, WIP limit, flujo de valor y demás elementos que forman parte del método Kanban.

Si es cierto que debido a que Scrum ya viene con sus propias reuniones prescritas (mínimas necesarias), a lo mejor no sea oportuno introducir las reuniones que propone el método Kanban, sin embargo, tampoco está prohibido hacerlo, va a depender del tiempo que tenga el equipo en cuestión para hacerlas y si realmente aportarían valor al flujo de trabajo, o si terminan realmente convirtiéndose en un desperdicio más que hay que eliminar.

3. ¿Cómo introduces el concepto de WIP limit a un equipo Scrum?

En referencia al WIP limit, el objetivo principal de Scrum es la entrega de valor al cliente, al menos al final del Sprint (porque se puede entregar continuamente durante el Sprint utilizando otros conceptos como integración continua, despliegue continuo, DevOps, todas compatibles con Scrum dado que es un marco de trabajo), de modo que un equipo Scrum lo bastante maduro y experimentado entiende que es más importante completar que empezar (a qué suena a Kanban), de aquí técnicas como Pair Programming, Swarming, Mob programming, promueven que el equipo se enfoque en completar las tareas más prioritarios, enfocando el esfuerzo de uno, dos o incluso todo el equipo en completarlas, lo mismo que sucede al limitar el WIP en Kanban.

En conclusión, Kanban y Scrum son herramientas de trabajo que se complementan y pueden convivir perfectamente, no son en lo más mínimo una alternativa el uno del otro, ambas tienen matices de Lean y de la Agilidad basándose en la auto organización de la gente alrededor del trabajo y no en la asignación de tareas, en la mejora del proceso, eliminación de desperdicios y la entrega de valor. Por sí solas, son maneras distintas de llegar a un mismo resultado pero requieren que el equipo y la organización cambie para poder adaptarse a ellas, no del modo contrario. Juntas proveen más herramientas al equipo para cumplir los objetivos esperados de la manera más eficiente.