Está probado que cuanto más trabajo en progreso tenga una persona o un equipo, mayor es el tiempo que se emplea en cerrar las tareas. Por un lado, si estamos haciendo varias tareas a la vez y las entregamos a la vez, el tiempo de entrega será la suma del tiempo de hacer las dos tareas. Sin embargo, si trabajamos en las tareas en orden secuencial, la primera tarea será entregada antes, y el tiempo medio de entrega también será más bajo.
Además realizar varias tareas a la vez puede provocar ineficiencias que no ocurren cuando se trabaja en una única tarea. Una de estas ineficiencias se da cuando hacemos cambios de contexto entre las tareas, está demostrado que nuestro cerebro necesita un tiempo de adaptación al contexto de la nueva tarea, y este tiempo no es productivo, es ineficiente. Hay veces que nos quedamos bloqueados con una tarea y decidimos saltar a otra tarea, para no perder el flow y ver si nos llega la iluminación que nos desbloquee. Esto puede ser una buena aproximación en algunos casos, pero siendo conscientes de que ahora tendremos dos contextos que mantener en la cabeza.
Cuando trabajamos en equipo este problema sigue existiendo e incluso se puede ver potenciado. Por ejemplo, si estamos programando dos tareas en dos ramas diferentes, y el equipo hace cambios en el código, tendremos dos ramas que actualizar. Si además, nuestro código se compila, es posible que tengamos que recompilar cada vez que cambiemos de rama, sumando tiempo no productivo. Si calculamos este tiempo y lo multiplicamos por el número de desarrolladores de nuestro equipo, el tiempo perdido al mes facilmente puede llegar al orden de jornadas de trabajo.
En Scrum, por ejemplo, el trabajo en progreso (o WIP, en inglés) se limita fijando el scope del Sprint y protegiendolo de inyecciones. Si el Sprint es de dos semanas, sabemos que durante esas dos semanas, si todo va bien, no habrá nuevo trabajo inyectado. El problema es que dos semanas de trabajo es ya de por si demasiado si no gestionamos bien el WIP. Scrum no prescribe prácticas para limitar el WIP dentro de un Sprint, nada impide que un desarrollador trabaje en varias tareas en paralelo. Además en el tablero del sprint backlog no es tan evidente ver cuanto trabajo en progreso hay en cada momento. Es por ello, que desde hace algún tiempo las herramientas tipo Jira o Clickup incluyen visualizaciones de tablero kanban para los sprints de Scrum. Utilizar estos tableros es muy recomendable porque dan buena visibilidad del WIP y de los cuellos de botella que van apareciendo dentro del sprint, en tiempo real, sin tener que esperar al final.
Pero los tableros kanban no son el único mecanismo disponible para mejorar el flujo de trabajo dentro de un sprint. Lo ideal es incorporar toda la metodología Kanban, que a través de la visualización del flujo de trabajo y la limitación del WIP, hace que el equipo tome consciencia y se haga owner de la cadena de producción. Esto le permite trabajar en desatascar rápidamente los cuellos de botella tan pronto se produzcan, y tener un feeling muy bueno de cómo está funcionando el flujo de trabajo, de cara a poder revisarlo y mejorarlo de forma continua.
Cuando Kanban se combina con Scrum, tenemos lo que se denomina como Scrumban, que permite mantener las ceremonias y el trabajo por sprints de Scrum con la observabilidad y mejora del flujo de trabajo de Kanban. Si ves que el Scrum en tu equipo está dando rendimientos decrecientes y mediocres, considerar Scrumban puede ser una buena alternativa para cambiar la tendencia.