La semana pasada publiqué un artículo un tanto indendiario que ha suscitado dudas entre mis alumnos de esta semana. Hoy voy a intentar introducir la mejor manera de usar Kanban en equipos Scrum.
En primer lugar, explicar que para este artículo me voy a centrar en Kanban, tal y cómo está originalmente concebido, no en el método Kanban. Para ello, voy a basarme en la guía que publicamos hace unos meses en Scrum.org: “Professional Scrum with Kanban“.
Amplificando Scrum, no modificándolo
Kanban, tal y como lo definimos en la guía, es una estrategia para maximizar el flujo de valor hacia los stakeholders a través de un proceso visual que utiliza un sistema pull con una limitación del trabajo en curso (WIP).
Scrum sigue aplicando en su totalidad. Lo que hacemos es añadir un sistema visual para gestionar el trabajo, limitar el trabajo en curso para crear un sistema que balancea demanda y capacidad, y por último, gestionamos el trabajo dentro de ese sistema.
Utilizamos cuatro prácticas:
- Visualización del flujo de trabajo
- Limitar el WIP.
- Gestión activa del trabajo en curso.
- Inspección y adaptación de la definición de Workflow.
Empecemos por el final
Definición de Workflow
Optimizar el flujo de trabajo requiere que tengamos uno. Por eso es importante que el equipo Scrum determine cual es su workflow y eso requiere de los siguientes elementos:
- Puntos definidos entre los cuales se inicia y se completa el trabajo, potencialmente con estados intermedios de completado del trabajo.
- Una definición de cuales son las unidades de trabajo que fluyen por ese sistema que aportan valor al cliente, que pueden ser Product Backlog Ítems
- Una definición de los estados intermedios por los cuales fluye el trabajo, de los cuales al menos uno debe ser un estado activo de trabajo
- Políticas explícitas sobre como fluyen el trabajo a través de los estados (que pueden incluir contenido de la Definition of Done)
- Una definición de como se va a limitar el trabajo en curso
- Una determinación de expectative de nivel de servicio fijada (Service Level Expectation, SLE) que comunique una previsión de cuanto se debería esperar para ver trabajo completado.
Puede que los estados definidos en el flujo no coincidan con los estados definidos en el Sprint Backlog. Aunque pueda ser ventajoso que sean iguales, no necesariamente tienen que gestionar. La definición de Workflow no sustituye al Sprint Backlog.
En la práctica, esto es muy similar a lo que ya vienen haciendo muchos equipos Scrum: Utilizar Kanban con limitación de WIP para mejorar el foco y de esa manera optimizar el flujo de valor hacia los clientes. Lo mejor es cuando además lo podemos combinar con métricas de flujo que potencialmente pueden llegar a eliminar la necesidad de estimaciones.
Métricas básicas de Flow
Una vez que tenemos un sistema pull, es muy sencillo obtener métricas de flow que ayuden tanto a mejorar la previsibilidad, como a incrementar la capacidad de foco y maximizar el valor ofrecido al cliente. Las cuatro métricas básicas que un equipo que utilice Scrum con Kanban debería medir son:
- WIP: El número de elementos que hemos empezado pero no hemos terminado (de acuerdo a la definición de “Workflow” del equipo Scrum)
- Cycle time: El tiempo que pasa entre que un elemento empieza y acaba.
- Work Item Age: El tiempo que ha pasado entre que empezó un elemento y el momento actual.
- Throughput: El número de elementos terminados por unidad de tiempo. Esta medida es una cuenta exacta mientras que las dos anteriores no tienen por qué serlo.
Eventos de Scrum basados en Flow
Una vez que tenemos una definición de workflow con sus elementos y las métricas básicas, entonces podemos empezar a utilizarlos como artefactos de transparencia dentro del equipo Scrum, lo que finalmente conlleva a mejorar el flujo de valor hacia el cliente.
Me dejo la descripción de los eventos para otra semana.