4 maneras de beneficiarte de Kanban y Scrum juntos

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:

  1. Puntos definidos entre los cuales se inicia y se completa el trabajo, potencialmente con estados intermedios de completado del trabajo.
  2. 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
  3. 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
  4. Políticas explícitas sobre como fluyen el trabajo a través de los estados (que pueden incluir contenido de la Definition of Done)
  5. Una definición de como se va a limitar el trabajo en curso
  6. 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.
Relacionado
De gestionar personas a gestionar trabajo

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.

Relacionado
No me llames SCRUM

Me dejo la descripción de los eventos para otra semana.

Avatar for Jerónimo Palacios Vela

Posted by Jerónimo Palacios Vela

Mi misión es ayudar a mejorar la profesión del desarrollo de software. Soy Professional Scrum Trainer de Scrum.org, Accredited Kanban Trainer de Lean Kanban y facilitador de LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby

  1. Avatar for Jerónimo Palacios Vela

    En mi experiencia, coincido que un equipo se puede beneficiar de ambas prácticas. Los equipos Scrum midiendo velocidad, se queda corto, y el Lead/cycle time enseguida sale como una métrica fundamental a nivel de negocio.
    Además, encuentro muy útil Kanban para organizar el “proceso oculto” de Scrum, toda la parte de refinado de features e historias, de inicio a fin, end2end. Ahí es dónde muchos equipos Scrum en mi experiencia se pierden, especialmente los inicios.

    Responder

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Para comentar debes aceptar nuestra política de privacidad

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This