Indice de contenidos
Prácticas Kanban para un equipo Scrum
Un equipo Scrum no está limitado a la guía Scrum únicamente. Según su madurez en el uso de Scrum puede ver más allá del marco de trabajo Scrum, en concreto, introducir por ejemplo las siguientes prácticas del método Kanban :
- Definir el flujo de trabajo y visualizarlo
- Limitar el trabajo en curso o en progreso ( WIP-LIMIT )
- Gestionar activamente los elementos en curso
- Inspeccionar y adaptar el flujo de trabajo
Hagamos un repaso rápido sobre estas prácticas
Definir el flujo de trabajo y visibilizarlo
Una de las grande ventajas de visualizar el trabajo en un equipo Scrum es asegurarse de ver el flujo de los PBIs (Product Backlog Items) desde la identificación de la necesidad hasta el punto de DONE, pasando por los estados o etapas que el PBI tome viajando por el flujo de trabajo( refinamiento, análisis, diseño, codificación, pruebas, despliegue, etc). Como puedes ver, no estamos hablando sólo de lo que ocurre en un Sprint, sino vamos más allá y obtenemos una visión holística sobre todo el producto y los estados por donde los Items deben de pasar.
Limitar el trabajo en curso WIP-Limit
Esta es una de las prácticas que quizás más clave de Kanban y como su nombre indica, hablamos de limitar el trabajo en curso. Esta práctica pretende reducir y estabilizar el WIP (work in progress). Esto mejora la gestión del flujo, nos da predictibilidad, y fomenta la creación de un sistema Kanban basado en pull y no push. En otras palabras, cuando hablamos de WIP Limit, hablamos de comenzar a cerrar trabajo antes de empezar un nuevo trabajo. Piensa en una columna de DEV, imagina que tienes el WIP Limit a 5 y tienes ya 5 Items en curso, la idea es, hasta que no termines trabajo en la columna DEV no puedes coger más trabajo. Desde mi humilde punto de vista y experiencia, es fácil decir y muy complicado hacer y respetar
¿Quién debe definir el WIP Limit?
Queda claro que el Sprint Backlog es propiedad de los Desarrolladores, por lo que tendría sentido que fueran dueños de su flujo de trabajo del Sprint Backlog y específicamente de los límites del WIP. ¿Y qué pasaría si tenemos en el flujo un estado de verify/accepted por el Product Owner? o simplemente, el equipo decide meter en el flujo de trabajo el refinamiento. Esto hace que se amplíe el contexto. La respuesta no es blanco o negro, sino que es depende del contexto y la situacion.
¿Deberían cambiarse los límites del WIP si hay elementos urgentes?
Una de las cosas muy claras con el WIP Limit, es que cuando se crea hay que respetarlo. Pero hay varias preguntas que plantearse:
Al margen de Kanban ¿El equipo debe introducir este elemento en el Sprint Backlog?
Si estamos en nuestro límite del WIP, ¿debemos de aumentarlo y coger este elemento?
¿Hay alguna forma para gestionar este tipo de elementos de trabajo?
Vamos allá, desde mi punto de vista, si el equipo decide al final añadir un nuevo elemento al Sprint Backlog, hay que ver si los elementos que tenemos en curso, son suficientemente pequeños, si es el caso, el tema es facil, en poco tiempo terminaremos algún Ítem y podemos ponernos con el nuevo. El problema viene cuando los Ítems son muy grandes…
Para resolver esto, no debemos de aumentar el WIP Limit, sino debemos ir un poco más allá y tomar nota de esta situación y debatirla más adelante en la retrospectiva.
¿Cómo deben los equipos Scrum limitar su WIP?
Bien, nos ha quedado claro el WIP Limit, pero, ¿Por dónde empiezo para limitarlo? ¿Qué pongo de WIP Limit? no es fácil responder a estas preguntas la verdad. Primero decirte que hay muchas formas de limitar el WIP:
- Por persona (me suena a PROTO-KANBAN)
- Limitar el WIP por carril
- Limitar el WIP por todo el tablero
- Limitar el WIP por columna/estado
- Limitar el WIP por tiempo (5 elementos por semana)
- etc.
Teniendo en cuenta todos estos criterios seguro que puedes encontrar ese equilibrio para definir tu WIP Limit ideal. y como sugerencia, toma nota del throughput por sprint y el paso de los elementos por los estados del flujo de trabajo, estos datos te permitirá: primero impulsar el empirismo y segundo tener datos para poder debatir y ajustar el WIP Limit.
Gestionar activamente los elementos en curso
Para poder gestionar los Items en el sprint podemos tener en cuenta lo siguiente:
- Asegurarnos que tenemos un ritmo sostenible y un equilibrio entre capacidad y demanda, que se traduce más o menos que el ritmo de entrada y salido de los ítems es similar o equilibrado.
- Velar para que la edad o el tiempo que un ítem esté en curso no supere nuestras expectativas de terminación, finalización o nuestro cycle time medio
- Revisar por ejemplo durante el Daily los PBIs bloqueados o en espera, así como los SLE (Service Level Expectation) creados por el equipo. Y lo más importante crear un plan de acción para ello.
Inspeccionar y adaptar el flujo de trabajo
¡Ojo! al usar Kanban por un equipo Scrum no hay que eliminar eventos ni artefactos de Scrum. El marco de trabajo se mantiene igual y se aprovechan sus eventos existentes para inspeccionar y adaptar en este caso el flujo de trabajo, así maximizamos la entrega de valor del equipo. Para ello el Scrum Team podría adoptar ciertos elementos a la hora de inspeccionar y adaptar su flujo de trabajo, como:
- Sus políticas explícitas de visualización, por ejemplo, los estados del flujo de trabajo, los tipos de trabajo, etc.
- Sus políticas explícitas de cómo trabajar, por ejemplo, ajustar los límites de WIP, SLE, etc
Espero que te haya resultado útil. Si tienes cualquier pregunta, no dudes en escribirme, estaré encantado de poder ayudar.
