Guía de Kanban para Equipos Scrum de Scrum.org

Propósito

La perspectiva basada en flujo ( de Kanban puede potenciar y complementar el marco Scrum y sus implementaciones. Los equipos pueden añadir prácticas complementarias de Kanban tanto si están comenzando a usar Scrum como si lo han estado durante algún tiempo.

La Guía Kanban para Equipos Scrum es el resultado de la colaboración entre miembros de la comunidad de Scrum.org y líderes de la comunidad de Kanban. Juntos, están detrás de la Guía Kanban para Equipos Scrum. Ambos comparten la creencia de que los profesionales del desarrollo de producto se pueden beneficiar de la aplicación conjunta de Kanban y Scrum.

Relación con la Guía de Scrum

Esta guía no reemplaza ni modifica ninguna parte de La Guía Scrum. Está diseñada para mejorar y expandir las prácticas de Scrum. Por ello, La Guía Scrum aplica completamente.

Kanban (n):

Una estrategia para optimizar el flujo de valor a través de un proceso que utiliza un sistema visual de tipo pull con límite del trabajo en progreso.

Comprender y aplicar el marco Scrum

TEORÍA DE KANBAN Y SCRUM

Flujo y empirismo

El concepto de flujo es esencial para la definición de Kanban. El flujo es el movimiento del valor a través del sistema de desarrollo de producto. Kanban optimiza el flujo mediante la mejora general de la eficiencia, efectividad y predictibilidad del proceso.

Optimizar el flujo en un contexto Scrum requiere definir qué significa el flujo en Scrum. Scrum está basado en la teoría del control empírico de procesos, o empirismo. En el control empírico de procesos, es clave la frecuencia del ciclo de transparencia, inspección y adaptación, que también podemos describir como el tiempo de Ciclo (Cycle Time) mediante el bucle de retroalimentación (feedback loop).

Cuando las prácticas Kanban se aplican a Scrum, proporcionan foco en mejorar el flujo mediante el bucle de retroalimentación, optimizando tanto la transparencia como la frecuencia de la inspección y adaptación tanto para el producto como para el proceso.

Las cuatro métricas básicas del flujo que los Equipos Scrum deben usar son las siguientes:

  • Work in Progress (WIP, Trabajo en Progreso): El número de elementos de valor comenzados pero no finalizados. El equipo puede usar la métrica WIP para mejorar la transparencia sobre su avance hacia reducir su WIP y mejorar su flujo. Notar que la métrica WIP es diferente de las políticas que usa un Equipo Scrum para simular el WIP.

  • Tiempo de ciclo (Cycle Time): La cantidad de tiempo transcurrido desde que un ítem de valor entra y sale del flujo según el contexto definido.

  • Edad del ítem de flujo (Work Item Age): la cantidad de tiempo transcurrido desde que un elemento de valor ingresó al flujo hasta el momento actual. Solo se aplica a los ítems que están en progreso.

  • Tasa de salida (Throughput): El número de elementos de valor que salen del flujo en una unidad de tiempo.

La Ley de Little — La clave para gobernar el flujo

Un principio clave que gobierna la teoría del flujo es la Ley de Little, una directriz que establece la siguiente relación:

La Ley de Little revela que en general, para un proceso dado con un rendimiento dado, cuantos más elementos tengas en progreso simultáneamente (en promedio), más tiempo tomará completar cada uno de ellos

Si los tiempos de ciclo son demasiado largos, la primera acción que deberían considerar los Equipos Scrum es rebajar el WIP. La mayoría de los elementos restantes de Kanban se derivan de la relación entre el WIP y el Tiempo de Ciclo.

La Ley de Little también nos muestra cómo la teoría del flujo se basa en el empirismo al usar métricas del flujo y datos para crear transparencia en el flujo histórico y entonces usar esos datos para dar información a experimentos de inspección y adaptación del flujo.

Prácticas Kanban

Los Equipos Scrum pueden alcanzar la optimización del flujo usando las siguientes cuatro prácticas:

  • Visualización del Flujo
  • Limitar el Work in Progress (WIP)
  • Gestión activa de los elementos de valor en progreso
  • Inspeccionar y adaptar la Definición de Flujo del equipo

Definición de Flujo

La Definición del Flujo del Equipo Scrum permite las cuatro prácticas Kanban. Esta definición representa el entendimiento explícito de los miembros del Equipo Scrum respecto cuales son sus políticas para realizar las prácticas Kanban. Este entendimiento compartido mejora la transparencia y permite la autogestión.

Notar que el alcance de la Definición de Flujo puede extenderse más allá del Sprint y del Sprint Backlog. Por ejemplo, la Definición de Flujo de un Equipo Scrum puede abarcar flujo dentro y/o fuera del Sprint.

Crear y adaptar la Definición de Flujo es la responsabilidad de los roles relevantes del Equipo Scrum, tal y como se describe en la Guía Scrum. Nadie fuera del Equipo Scrum debería decir al Equipo Scrum como definir su Flujo.

Visualización del Flujo — el Tablero de Kanban

La visualización usando el tablero Kanban es la manera en la que el Equipo Scrum hace su flujo transparente. La configuración del tablero debería impulsar las conversaciones adecuadas en el momento adecuado y sugerir proactivamente oportunidades de mejora. La visualización debería incluir lo siguiente:

  • Puntos definidos en los cuales el Equipo Scrum considera que el trabajo ha comenzado y ha acabado.
  • Una definición de los elementos de valor – las unidades individuales de valor (para los interesados, conocimiento o mejora de procesos) que están fluyendo a través del sistema del Equipo Scrum (muy probablemente ítems del Product Backlog (PBIs)).
  • Una definición del flujo establece que los elementos de valor fluyen de inicio a fin (de los cuales debe haber al menos un estado activo).
  • Políticas explícitas respecto a cómo el trabajo fluye por cada estado (que puede incluir ítems de los Criterios de Terminado de un Equipo Scrum).
  • Políticas explícitas respecto a cómo fluye el trabajo por cada estado (que puede incluir ítems de los Criterios de Terminado de un Equipo Scrum y políticas para tomar los ítems entre estados o políticas pull).
  • Políticas para limitar el Work in Progress (WIP).

Limitar el Trabajo en Progreso (WIP)

El Trabajo en Progreso (WIP) se refiere a los elementos de valor que un Equipo Scrum ha comenzado pero no ha acabado todavía.

Los Equipos Scrum que usan Kanban deben limitar explícitamente el número de esos elementos de valor en progreso. Un Equipo Scrum puede limitar el WIP de la manera que crea mejor pero debería mantener ese límite una vez establecido.

El principal efecto de limitar el WIP es que crea un sistema pull (para tomar). Se denomina sistema pull porque el equipo toma un elemento solo cuando está claro que tiene la capacidad para hacerlo. Cuando el WIP cae bajo un límite definido es la señal para comenzar un nuevo trabajo. Notar que es lo opuesto a un sistema push (de empuje), que exige comenzar un trabajo en el momento que se solicita.

Limitar el WIP ayuda al flujo y mejora la capacidad de autogestión, foco, compromiso y colaboración del Equipo Scrum.

Gestión activa del Trabajo en Progreso

La limitación del WIP es necesaria para alcanzar el flujo, pero no es suficiente por sí misma. La tercer práctica para establecer el flujo es la gestión activa de los íelementos de valor en progreso. Dentro del Sprint, esta gestión puede tomar diferentes formas, entre las cuales las siguientes:

  • Asegurar que los elementos de valor solo se arrastran al Flujo a un ritmo parecido al que dejan el Flujo.
  • Asegurar que los elementos de valor no se dejan envejecer innecesariamente.
  • Responder rápido a elementos de valor bloqueados o en cola, así como aquellos que están superando los niveles esperados de Tiempo de Ciclo del equipo (ver Expectativa de Niveles de Servicio – SLE).

Expectativa de Niveles de Servicio (SLE)

Una Expectativa de Niveles de Servicio (SLE) pronostica cuánto debería tardar un ítem en fluir desde el principio al fin del flujo de un Equipo Scrum. El Equipo usa su SLE para encontrar problemas en el flujo activo y para inspeccionar y adaptar en casos de caer debajo de esas expectativas.

El SLE en sí mismo tiene dos partes: el rango de días transcurridos y una probabilidad asociada con ese periodo (p.e. el 85% de los elementos de valor deberían acabarse en ocho días o menos). El SLE debería basarse en el Tiempo de Ciclo histórico del Equipo Scrum, y una vez calculado, el Equipo Scrum debería hacerlo transparente. Si no se cuenta con datos históricos de Tiempo de Ciclo, el Equipo Scrum debería hacer su mejor estimación y entonces, inspeccionar y adaptar una vez que existen suficientes datos históricos para hacer un cálculo adecuado del SLE.

Inspeccionar y adaptar la Definición de  Flujo

El Equipo Scrum usa los eventos de Scrum para inspeccionar y adaptar su Definición de flujo, y de ese modo ayudar a mejorar el empirismo y optimizar el valor que entrega el Equipo Scrum.

La Definición de Flujo del Equipo Scrum debería adoptar los siguientes aspectos:

  • Políticas de visualización – por ejemplo, estados de Flujo – ya sea cambiando el Flujo actual o creando más transparencia en un área en la cual el equipo quiere inspeccionar y adaptar.
  • Políticas del flujo – estas pueden abordar directamente un impedimento. Por ejemplo, ajustar los límites de WIP y SLE o cambiar el tamaño del lote (con qué frecuencia los ítems se toman entre estados), pueden tener un impacto dramático.
Gestionar productos con agilidad

EVENTOS BASADOS EN FLUJO

  • Usar Kanban en un contexto Scrum no requiere ningún evento adicional a los que se indican en La Guía Scrum. En cambio, usar la perspectiva y métricas basadas en flujo en los eventos de Scrum fortalece el enfoque empírico de Scrum.

    El Sprint

    Las prácticas complementarias de Kanban no invalidan la necesidad del Sprint en Scrum. El Sprint y los eventos proporcionan oportunidades para la inspección y adaptación tanto para el producto como para el proceso. Un mito habitual es que los Equipos Scrum sólo pueden entregar valor una vez por Sprint. De hecho, estos deberían entregar como mínimo una vez por Sprint. Los equipos que usan Scrum con Kanban usan el Sprint y sus eventos como bucles de retroalimentación para la mejora cuando colaboran inspeccionando y adaptando su Definición de Flujo y las métricas.

    Las prácticas de Kanban pueden ayudar a los Equipos Scrum a mejorar el flujo y crear un entorno donde las decisiones se tomen justo a tiempo durante el Sprint basándose en la inspección y adaptación. En este entorno, los Equipos Scrum se basan en el Sprint Goal y en una colaboración estrecha dentro del equipo para optimizar el valor entregado en el Sprint.

    Sprint Planning

    Un evento Sprint Planning basado en el flujo utiliza las métricas de flujo como una ayuda para desarrollar el Sprint Backlog. Revisar la Tasa de salida histórica puede ayudar a un Equipo Scrum a entender su capacidad para el siguiente Sprint.

    Daily Scrum

    Un Daily Scrum basado en flujo lleva a los Desarrolladores a enfocarse en hacer todo lo posible para mantener consistente el flujo. Mientras que el objetivo del Daily Scrum permanece igual a la indicada en La Guía Scrum, el evento tiene lugar alrededor del tablero Kanban y se enfoca en dónde el flujo tiene problemas o requiere cambios y qué acciones pueden tomar los Desarrolladores para mejorarlo.

    Cosas adicionales a considerar durante un Daily Scrum basado en flujo incluyen las siguientes:

    • ¿Qué ítems de trabajo están bloqueados y qué se puede hacer para desbloquearlos?
    • ¿Qué ítems están fluyendo más lento de lo esperado? ¿Cuánto tiempo lleva en progreso el ítem de valor? ¿Qué elementos de valor han violado, o están a punto de hacerlo, su SLE y qué puede hacer el Equipo Scrum para completar ese trabajo?
    • ¿Hay algún factor no representado en el tablero que pueda impactar nuestra capacidad de completar el trabajo hoy?
    • ¿Hemos aprendido algo nuevo que pueda cambiar lo próximo en lo que el Equipo Scrum tenía planeado trabajar?
    • ¿Hemos sobrepasado nuestro límite de WIP? ¿Y qué podemos hacer para asegurar que completamos el trabajo en progreso?

    Sprint Review

    La Guía Scrum proporciona un esquema del Sprint Review. Inspeccionar las métricas de flujo de Kanban como parte de esa revisión puede crear oportunidades para nuevas conversaciones respecto a controlar el avance hacia el Product Goal. Revisar la Tasa de Salida puede proporcionar información adicional cuando el Product Owner comenta las fechas probables de  entrega.

    Sprint Retrospective

    Un Sprint Retrospective basado en flujo añade la inspección de las métricas y análisis del flujo para ayudar a determinar las mejoras que puede hacer el Equipo Scrum a sus procesos. El Equipo Scrum que usa Kanban también inspecciona y adapta su Definición de Flujo para optimizarlo en el siguiente Sprint. El uso del diagrama de flujo puede ser útil para visualizar el WIP del equipo, el Tiempo de Ciclo medio aproximado y la Tasa de salida aproximada.

    Además del Sprint Retrospective, el Equipo Scrum debería aprovechar las oportunidades de inspección y adaptación conforme aparecen durante el Sprint.

    Del mismo modo, pueden aparecer cambios a la Definición de flujo del Equipo Scrum en cualquier momento. Dado que estos cambios tienen un impacto material en cómo funciona el Equipo Scrum, los cambios realizados durante la cadencia regular del Sprint Retrospective reducirán la complejidad y mejorarán el foco, compromiso y transparencia.

    Incremento

    Scrum requiere que el equipo cree un Incremento valioso y usable (como mínimo) cada Sprint. El empirismo de Scrum fomenta la creación de múltiples incrementos valiosos durante el Sprint para permitir bucles de retroalimentación rápidos de inspección y adaptación. Kanban ayuda a gestionar el flujo de estos ciclos de retroalimentación de manera más explícita y permite al Equipo Scrum identificar cuellos de botella, restricciones e impedimentos para lograr una entrega más rápida y continua de valor. 

    Nota final

    Scrum no es un proceso ni una técnica. Es un marco de trabajo dentro del cual las personas pueden abordar problemas complejos adaptativos mientras entregan productos del máximo valor posible de manera productiva y creativa. Tal como La Guía Scrum indica, funciona bien como contenedor para otras técnicas, metodologías y prácticas.

    Las prácticas de optimización del flujo de Kanban proporcionan a los Equipos Scrum oportunidades adicionales de adaptar la cosa correcta, en el momento correcto, para entonces inspeccionar y adaptar según sea necesario. El hiperfoco de Kanban en la transparencia, visualización y flujo, maximiza el bucle de retroalimentación, el empirismo, y finalmente, la entrega de valor.

    Historia y reconocimientos

    El uso de Kanban en un contexto de trabajo creativo de conocimiento se originó principalmente en 2006 en un equipo en Corbis, una empresa de Seattle dedicada al licenciamiento de medios de comunicación. Estas prácticas se extendieron rápidamente para abarcar una comunidad grande, diversa e internacional que durante los años ha continuado mejorando y evolucionando el método.

    Esta guía ha sido desarrollada colaborativamente por Scrum.org, su comunidad de Professional Scrum Trainers, Steve Porter, Yuval Yeret, y Daniel Vacanti.

    Agradecemos especialmente a Glaudia Califano, Louis-Philippe Carignan, Charles Bradley, Jose Casal, Andy Hiles, Jesse Houwing, y Julia Wester por sus contribuciones. También estamos agradecidos a todos aquellos que han usado Kanban en el pasado y que contribuyeron a hacer de Kanban una estrategia lean-agile viable y exitosa.

    Información de la traducción

    Esta traducción ha sido realizada por:

    • Joel Francia H. | jfrancia@discoveryfast.com.

    Para mantener la consistencia con las traducciones de otras guías de Scrum.org, se han mantenido en inglés los siguientes términos: 

    • Términos generales: Kanban, Scrum, SLE, Product Goal, 
    • Eventos: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
    • Roles: Product Owner, Scrum Master
    • Artefactos: Product Backlog, Sprint Backlog, WIP

    El resto de los términos se ha traducido, aunque algunos términos que se encuentran habitualmente en inglés se han dejado (p. ej., pull)o

Curso de Professional con Kanban