Hola, hoy quiero comentar acerca de una de las prácticas de Kanban. La práctica más subestimada de todas, pero, las que más beneficios trae. La más contra intuitiva y la que más me cuesta hacer partícipes a Jefes de proyecto, Product Owners o cualquier otro perfil responsable de administrar un producto o servicio. Hoy quiero hablar sobre limitar el trabajo en progreso y como te puede ayudar a mejorar la Gestión de Proyectos usando Kanban, ya sea que trabajes con PMI, CMMI, ISO o Agilidad.

Se cómo Leónidas y limita el trabajo en progreso

¿Se preguntaran, que tiene que ver esto con Kanban, gestionar proyectos o servicios? A Continuación, les comento mi apreciación.

Todos recordamos la película 300, basada en un hecho histórico. En la cual Leónidas el rey de Esparta hizo frente a miles de persas solo con 300 guerreros. Leónidas como cualquier otro líder le hubiera gustado tener más gente para poder hacer frente a la demanda que se aproximaba, pero solo podía contar con 300 personas. Tenía que usar la capacidad que tenía para atender la demanda. Como todo buen líder tenía que saber qué es lo que su equipo puede hacer y que no puede hacer. Lo que hizo después fue limitar el paso del enemigo, en este caso limitó el trabajo en progreso, de acuerdo con lo que su equipo podía hacer, es decir, balanceó la demanda contra la capacidad de su equipo. Haciendo un aparte, una característica que he encontrado en equipos es que no conocen realmente cuanto es su capacidad y solo aceptan y aceptan requerimientos o el entusiasmo les gana y pecan de optimistas. Así que, lo primero que debemos hacer es validar la capacidad de respuesta de nuestro equipo.

Volviendo a Leónidas, el no necesito saber exactamente cuántos persas tenía que liquidar, o cuantos eran, sino que, se preocupó en mantener el balance entre demanda y capacidad, si él hubiera optado por otra táctica y salir del pasaje donde estaban atrincherados, es decir, dejar de limitar el trabajo en progreso, las bajas de su equipo hubieran sido muy numerosas, lo cual hubiera disminuido su capacidad. Ahora, es algo con lo que también me he topado, equipos que han limitado su trabajo en progreso y después no lo respetan, es decir, pueden trabajar en 4 requerimientos a la vez, y luego deciden aceptar 1 o 2 requerimientos más porque es muy urgente. Esto hace que se rompa el balance entre demanda y capacidad, la consecuencia de esto es que disminuye el rendimiento y se hace evidente cuanto se entrega menos de lo que usualmente está acostumbrado el cliente.

Por otro lado, al limitar el paso de los persas, o el trabajo en progreso, el foco se concentró en un solo punto. Haciendo que el equipo enfocara todo su esfuerzo en ese punto, y que su rendimiento mejorara.

Ayuda a disminuir el multitasking por ende el desperdicio

Ahora quiero mencionar otros beneficios más de limitar el trabajo en progreso y como puede ayudar a gestionar mejor tú proyecto o servicio.

Hay mucho desperdicio cuando una persona está ocupada todo el día y haciendo muchas cosas a la vez. Por ejemplo, es común ver desarrolladores participar en más de un proyecto a la vez. He conocido desarrolladores que en la mañana trabajaban en el proyecto A y por la tarde trabajaban en el proyecto B. También me encontrado con casos de desarrolladores que estaban trabajando en 4 requerimientos al mismo tiempo. Desde un punto de vista tradicional, podríamos decir que no tiene tiempos muertos, que se está utilizando al máximo el tiempo del desarrollador, así que, ¿Dónde se encuentra el desperdicio en este caso? La respuesta está en el tiempo que se pierde al cambiar de tarea en tarea. Voy a citar otro ejemplo, recuerdo que cuando era desarrollador, una vez tenía que avanzar 3 requerimientos a la vez. Llamémoslos A, B y C. Comenzaba el día atendiendo el requerimiento A, y cuando estaba totalmente concentrado en A, tenía que dejarlo y volverá concentrarme en B y ya cuando estaba totalmente concentrado en B lo tenía que dejar y hacer lo mismo con C. El desperdicio se encuentra en el grado de concentración que pierdes al estar cambiando entre tareas. Esto afecta muchísimo si se trata de un trabajo intelectual o inclusive cuando trabajas con máquinas, porque cuando cambias de una actividad a otra se tiene que calibrar o configurar la máquina.

Lo que sucede es que siempre la demanda será mayor a la capacidad del equipo, y en el afán de querer atender muchos más requerimientos, porque queremos ofrecer un buen servicio al cliente, se satura las personas del equipo con muchas tareas a la vez, como lo que me pasaba a mi cuando era desarrollador. Era común escuchar a mis jefes decir: “Jonathan, hay mucho trabajo que avanzar, y tenemos que avanzar lo más que podamos”. El problema con el multitasking es que mantienes a las personas ocupadas, sin embargo, al final del día es muy probable que no cierren alguna tarea, y tengan que hacer horas extra para poder terminar. Si estás en un contexto así, y si esto se sigue manteniendo, es probable que tengas rotación de personal cada 3 meses, usualmente son a los desarrolladores sénior a quienes se carga con más trabajo y son ellos los primeros en renunciar, aumentarles el sueldo funciona las primeras veces, pero, eventualmente no encontrarán otra motivación y se marcharán. Y reemplazarlos con un perfil del mismo grado de experiencia será muy difícil, además de costoso.

En el siguiente gráfico, se muestra un estudio de cuanto se pierde al cambiar de un contexto a otro.

Si bien es cierto, el grafico está basado en proyectos y no tareas, estos números también aplican a tareas. Traten de ver en sus equipos como están asignadas las tareas y cuantas tareas tienen cada persona y encontraran que este cuadro calza con sus contextos. Pero volviendo a proyectos, y viendo el cuadro te invitaría a hacerte las siguientes preguntas:

¿Cuántos proyectos actualmente está desarrollando la empresa en la cual trabajas?, ¿De esos proyectos cuantos se están terminando en fecha?, ¿De los que se entregan en fecha como es la calidad de lo que se está entregando?, ¿Si estás manejando más de 2 o 3 proyectos, sientes que la realidad que vives se parece al gráfico, que no tienes el tiempo suficiente para gestionar los proyectos?

Una alternativa para atender este punto de dolor, si es que lo tienes, es limitar la cantidad de proyectos que estás llevando. Por ejemplo, si tienes 3 proyectos en paralelo (he conocido personas que llevan hasta más de 3) podrías llevar solo 2 y verás que puedes enfocar mejor tu tiempo en solo 2 proyectos que llevar 3 en paralelo. Usualmente cuando digo esto, me preguntan lo siguiente: “¿Jonathan, suena bonito todo eso, pero como consigo convencer a mi jefe para limitar el trabajo en progreso?”, y lo que les respondo es: Uno de los principios de Kanban nos dice que debemos desarrollar liderazgo en todos los niveles de la organización. En ese sentido, ya seas desarrollador, tester, Jefe de Proyectos, Scrum Master o cualquier otro rol, debemos mejorar nuestro nivel de persuasión o influencia, para convencer tanto a nuestro jefe como a los demás miembros de nuestro equipo en limitar el trabajo en progreso. Por mi parte, yo uso la simulación de Featureban para influenciar a las personas de limitar el trabajo en progreso, claro está, que previamente debo haberlos persuadido de hacer la simulación. Es decir, quieras o no, debes mejorar tu nivel de persuasión o influencia.

Reduce la dependencia entre personas

Cuando limitas el trabajo en progreso y concentras el foco en pocas cosas a la vez, estás permitiendo a las personas auto organizarse alrededor del trabajo.

Un ejemplo que recuerdo es cuando una vez estaba a cargo de un equipo, tuvimos un requerimiento, en el cual, 2 personas se pusieron a trabajar. Usualmente se podría pensar que 2 personas trabajando en un requerimiento seria innecesario o hasta un desperdicio. Pero, al tener 2 puntos de vista diferentes en un solo requerimiento la solución que emerge es mucho más enriquecida. Ahora, esto es más apropiado cuando un requerimiento es muy complejo. Personalmente, no lo usaría con un requerimiento que es muy simple, como el mantenimiento de una tabla.

Otro de los beneficios, es que ambas personas que participaron desarrollando ese requerimiento se quedan con el conocimiento y ya no tienes dependencia en una sola persona. Así también, cuando algún miembro del equipo se tenga que ir no será necesario invertir mucho tiempo para hacer traslados de información.

Otro ejemplo que recuerdo es cuando un desarrollador sénior se tenía que ir y solo él conocía los procesos core (principales) del negocio. Se había dispuesto que se haría la transferencia durante 3 semanas, el problema fue que no se encontró su reemplazo, era muy difícil encontrar alguien con su perfil. Mientras tanto, se fue haciendo a la transferencia de conocimiento a otros dos miembros del equipo. Finalmente, encontraron a la persona que podría reemplazarlo, pero, solo quedaban 4 días para hacer todo el traslado que se pretendía hacer. Como imaginarán fue un caos, su reemplazo no había podido asimilar toda la información, así que se les preguntó a los otros miembros del equipo. Pero ellos, no recordaban muy bien, a pesar de que se les había hecho el traslado, así que tuvieron que llamarlo, para arreglar la incidencia que había ocurrido, y luego agendar una nueva capacitación fuera de horas de oficina, hubo que pagarle por las horas de capacitación y la solución de la incidencia. Así que, limitar el trabajo en progreso fomenta la colaboración, también permite que se distribuya el conocimiento del negocio entre los miembros del equipo, y disminuye la dependencia que puede estar concentrada en una sola persona.

Agradecimientos

No queria irme sin agradecer a Ivan Gonzales, Diego Martin Perez, Armando Balbuena, Paul Ramos, Augusto Miyagi y Abraham Cervantes por el valioso feedback de este articulo.

Pensamientos Finales

La parte dificil de limitar el trabajo en progreso es determinar o establecer cuanto es la cantidad a limitar. Para esto necesitas experimentar o pilotear durante un tiempo la cantidad de trabajo en progreso a limitar, hasta encontrar el balance entre demanda y capacidad.

El método Kanban es bastante amplio, cuenta con principios, valores, prácticas, cadencias, métricas, STATIK, etc. Si bien es cierto, este artículo solo menciona la práctica de limitar el trabajo en progreso, tómenlo como punto de partida para comenzar en este camino de mejora continua, y que pueden comenzar a aplicar en sus proyectos o servicios, sin olvidar que hay más temas que ofrece el método Kanban para ayudarlos a mejorar.

Finalmente, no importa si gestionas proyectos o servicios, estoy seguro que el limitar el trabajo en progreso te traerá muchos más beneficios de los que he mencionado. Espero que hayan disfrutado leyendo este post.

Sección del cherry

En este post solo hemos tocado 1 práctica de las 6 que sugiere Kanban. Si te interesa saber acerca de las otras prácticas y como estas te ayudan a mejorar tu proyecto o servicio, este 23 de Noviembre estaré dictando un curso oficial, «Team Kanban Practitioner« de la Kanban University, en el cual veremos las prácticas de Kanban, los principios de gestión del cambio, diseño de tableros, proto – Kanban, una simulación del método Kanban, además, tendrás 2 horas de asesoría personalizada. Para más detalles visita el siguiente enlace: Certificación Oficial Team Kanban Practitioner