Perdonad que empiece este artículo con una “frikada”. Cuando era pequeño, una de mis series favoritas era Bola de Dragón. Dos de sus personajes principales eran Goku y Vegeta. A pesar de que son grandes guerreros, en un par de momentos de la serie, tienen que fusionar sus cuerpos para poder vencer a un enemigo mucho más fuerte. Con el típico lema “uno más uno es mucho más que dos”, unen sus cuerpos de dos maneras diferentes. En la primera, lo llamaron “Vegeto” y en la segunda, “Gogeta” (si unimos los nombres). Este símil me recuerda mucho a Scrum con Kanban, vamos a estudiar dos maneras diferentes de unirlos y cómo la visión “scrumban” quizás sea la peor de todas.
http://www.quiengana.com/2008/09/quien-gana-gogeta-o-vegetto.html
ScrumBan lo que solemos encontrarnos
En muchos equipos acaban por tener lo que se conoce como ScrumBan. Básicamente se resume en tener un tablero con un carril de incidencias. De esta manera, tenemos un desarrollo que circula por el camino “normal”, mientras que tenemos un camino rápido para gestionar las urgencias. Dado que no sabemos cuántas incidencias vamos a tener, reservamos un 80% de la capacidad del equipo.
Este modelo es un clásico, pero refleja el desconocimiento tanto de Scrum como de Kanban. Lo primero que Kanban necesita es de una serie de prácticas, y muchas de ellas no las estamos cumpliendo. Kanban no es un gestionador de incidencias, es un método para gestionar y mejorar flujos de trabajo. Además, Scrum no se basa en estimaciones por lo que no podemos saber qué es “el 80% de la capacidad”. Sí, muchos equipos usan el 80% de los puntos de historia habituales que solemos hacer, sin embargo, cada Sprint es único y las tareas siempre sufren variaciones, realmente no lo sabemos.
Si se quiere leer más sobre scrumban, hay un artículo de Jerónimo Palacios que lo explica muy bien.
Kanbanizar Scrum
Cuando hablamos de unir ambos mundos, una de las opciones es “Kanbanizar Scrum”. Recordemos que Kanban es poco disruptivo en su implantación: comienza por lo que haces ahora y gestiona el flujo para mejorar las ineficiencias.
Podemos seguir unos pasos parecidos a estos:
- Primero, visualizaremos el trabajo que hemos previsto en el Sprint. Ideal sería que lo viéramos de manera física pero, si no se puede, lo haremos virtualmente.
- Explicitaremos las políticas del equipo, seguramente tendremos ya una Definition of Done heredada de Scrum por lo que podremos hacerlo fácilmente.
- Gestionaremos el flujo de manera activa gracias a la autoorganización del Development Team y al Scrum Master resolviendo impedimentos.
- Dispondremos de FeedbackLoops que pueden ser nuestros eventos Scrum (aunque habría que añadir conversaciones referentes al servicio que prestamos y a nuestro flujo).
- Mejoraremos en base a la experiencia y a las facilidades que nos proporcionará la retrospectiva. Recordemos que Scrum y Kanban buscan en la experiencia la manera de aplicar mejoras en nuestro equipo.
- Añadiremos límites WIP: quizás sea lo más difícil porque hay que introducir un cambio de mentalidad de “push” a “pull”. Esto supone que si tenemos la columna “Test” llena, no tratemos de hacer más cosas, sino que tratemos de liberarla. Puede que introducir WIP Limit sea lo más difícil, pero es lo que más beneficios tiene porque ayuda a nuestra capacidad de entregar dentro del Sprint.
Evidentemente, introducir Kanban tiene que buscar la mejora del flujo de trabajo durante nuestro Sprint para poder entregar. Esta Kanbanización ayuda a poner foco, a evitar que cojamos más trabajo del que podamos asumir o a no dejar las pruebas tan al final que se acaben por no realizar.
Una vez kanbanizamos el sistema, podemos empezar a trabajar con métricas como el leadtime, lo que nos permite empezar a ganar predictibilidad y reducir nuestra inversión en estimaciones.
Scrumizar Kanban
Este camino es quizás más raro pero es viable. Dado que las personas entienden de manera regular el concepto Scrum o Kanban, muchas veces escuchamos la frase “Scrum para el proyecto y Kanban para el mantenimiento”. Por eso, el camino más habitual es cambiar a Kanban cuando estamos “en producción”.
Aún así, si tenemos un sistema Kanbanizado, podemos aplicar Scrum. Para ello, podemos seguir alguno de los siguientes pasos:
- Introducir los roles de Scrum de manera natural. Kanban no prescribe roles, pero sí es cierto que se observa la figura del Service Delivery Manager y del Service Request Manager. El primero podría ser nuestro Scrum Master, cambiando quizás parte de su manera de liderar, pero podría ser bastante natural. El segundo sería nuestro Product Owner, además ya dispondría quizás de un Kanban para el Upstream, por lo que podría llegar a funcionar mejor que un Product Owner que partiera de cero de Scrum. En cuanto al Development Team,, tenemos la dificultad de que nuestro sistema no sea “end-to-end” y no entreguemos cosas terminadas.
- No introducir los artefactos porque seguramente nuestro sistema Kanban tenga ya el Sprint Backlog y el Product Backlog recogidos, y el incremento sea lo que vamos terminando. De hecho, Kanban reacciona muy bien ante r diferentes tipos de clases de servicio que nos ayuden a la priorización.
- Introducir los eventos es lo que presenta mayor dificultad , aunque realmente ya hay feedback loops en Kanban. Los eventos nos marcan una pauta y por tanto, al introducirlos, debemos tener cuidado. Nuestra Sprint Planning podría completar a nuestro Replenishment, nuestras Daily sería similar y el Service Delivery Planning sería nuestra Review. Realmente habrá que hacer pequeños ajustes sobre quién se responsabiliza del evento, pero deberían funcionar de manera natural porque comparten objetivos.
Introducir Scrum en un Sistema Kanban es viable, pero hay que tener cuidado. Puede que nuestro sistema tenga una entrega mayor a treinta días, y eso técnicamente no cumpliría Scrum. Puede ser, pues podemos usar Scrum como una palanca que nos permita mejorar eso precisamente.
Una reflexión personal, a medida que más aprendo de Scrum y de Kanban más me doy cuenta de que acaban proponiendo cosas muy parecidas. Su puesta en escena parece diferente, pero realmente ambas son formas de “lidiar” con un mundo complejo e impredecible.
¿Cómo unes Scrum con Kanban en tus equipos?
