Por varios meses trabajamos con Scrum y teníamos iteraciones de 2 semanas. Durante cada una, los devs (desarrolladores) tomaban las tarjetas que se les asignaban y tenían la duración del sprint para sacarla adelante.
Una de las cosas que pasaba era que los primeros días del sprint no teníamos avances concretos. De hecho el burndown chart mostraba eso: no disminuían las horas.
Para combatir esto empezamos a hacer planes de implementación. Estos son un comentario en la tarjeta que dice cómo llevar a cabo la tarea. Con esto los devs pueden partir trabajando desde el primer momento, eliminamos el tiempo dedicado a navegar por el código para definir el approach: ese trabajo viene hecho.
Le quitamos con esto la componente creativa al trabajo de desarrollo? No, porque son los mismos devs lo que hacen los planes, pero antes de que la tarjeta entre en el sprint.
Con este cambio eliminamos el tiempo “no productivo” del principio, pero afloró otro problema: los cambios de alcance.
En Scrum el sprint tiene desde el comienzo un alcance definido y no debe ser modificado. Qué pasa entonces cuando el área comercial o proyectos necesitan de nuestra ayuda? Estamos atados de manos porque ya tenemos las tareas priorizadas y comprometidas, por lo tanto no podemos realizar ajustes.
En un sistema Kanban por otro lado, el flujo de tareas es constante y el equipo toma tickets cuando se van desocupando. Permitiendo así realizar ajustes constantemente al backlog que nutre al dev. Cuando un dev termina su tarea toma la primera del backlog, que representa la siguiente tarea que se debe realizar.
Para solucionar el tema de la flexibilidad implementamos el sistema Kanban para la entrada de las tarjetas, de esta manera somos capaces de adaptarnos a las necesidades cambiantes del negocio, pero mantuvimos los sprints como forma de generar un corte en el trabajo y permitir detenernos cada 2 semanas.
Dentro de los cambios anteriores incorporamos también de Kanban el Work in Progress Limit pero con una modificación: lo implementamos por dev y no para todo el equipo (no me maten, es una etapa) y lo fijamos en 1 tarjeta. Tener varias tarjetas asignadas al mismo tiempo hace que la mente vaya de un lado a otro y pierde el foco de lo realmente importante: sacar tarjetas, no quemar horas. Está comprobado que si tenemos una sola tarea asignada y no podemos tomar otra hasta sacar la actual la mentalidad cambia hacia terminar mis tareas y no ir abriendo varias.
Otro aspecto positivo es que al tener sólo 1 ticket asignado a la vez me canso menos y por lo tanto es menos probable que termine quemado (burnout) al corto plazo.
Por estas razones ahora trabajamos con Scrumban que nos permite adaptarnos a nuestros stakeholders para dar solución a sus problemas pero también cuidando a los devs que no terminen estresados.