Como alinearse a la Ley del Flujo 1

Serie Kanban Maturity Model parte 3

La primera ley, es «Es mandatorio proteger a los equipos de la sobrecarga». ¿Cómo nos alineamos a esta ley del Flujo 1?

Hace casi 13 años conversé con un amigo:
– Me podrías ayudar indicándome cómo proteger a un equipo de la sobrecarga
– Claro Iván, en contextos complejos el equipo define su capacidad en puntos de historia
– Pero, los puntos de historia son relativos a cada persona
– Si. Por ello en el Planning el equipo se pone de acuerdo cuánto «pesa» cada historia. Evitando comprometerse con algo superior a la velocidad en puntos de historia. En mi curso de Scrum (año 2009), el trainer dijo que el equipo se compromete con el promedio de velocidad en puntos de historia de los últimos 3 sprints.
– Pero el promedio tiene un porcentaje de probabilidad baja
– No es problema, así funciona

Hace poco conversé con otro amigo:
– Mira Iván, SAFe define la capacidad como la cantidad de puntos de historia y tiene una equivalencia en horas (jornadas de trabajo). Cada equipo tiene su capacidad en jornadas, de esa manera protegemos a los equipos de la sobrecarga
– Pero, es trabajo de conocimiento… No se puede emplear horas.
– SAFe es un framework con las mejores prácticas a nivel mundial, así funciona.

Lamento informarles que la cantidad de horas solo se puede usar para trabajo operativo (trabajo repetitivo que sigue un procedimiento y cuyo resultado es el mismo quienquiera que lo ejecute, por ejemplo: podar el césped), no se puede usar horas para trabajo de conocimiento (trabajo creativo donde cada pieza es diferente según la persona que lo realiza). Pídanle a dos desarrolladores hacer una misma historia de usuario, el código no será el mismo, el tiempo será distinto, el front end será diferente, eso significa que es Trabajo de conocimiento.

¿Qué usar?

En una experiencia muy reciente, teníamos un equipo sobrecargado en extremo. Aplicaban Sprints, pero, como el contexto es muy acido, entraban nuevos tickets a cada momento.

La solución que empleamos fue realizar un piloto de sistema pull.

Este equipo tiene 5 personas y se limitó el trabajo en progreso a solo dos historias de usuario. Ellos no pueden tomar una tercera historia, si no ha finalizado una de las 2 que está en curso. Simplemente su productividad se elevó increíblemente.

Dejaron de usar Sprints, por lo tanto, ahora la planificación consiste en ordenar la secuencia de las historias de usuario según criterios de negocio. El equipo toma la primera historia de la pila secuenciada solamente si ha finalizado algo previamente.

En la reunión diaria se hizo énfasis en «Finalizar por sobre comenzar», haciéndoles recordar que sobrecargar es la peor opción, y removiendo impedimentos rápidamente.

Recuerden que en este post estamos viendo como alinearnos a la ley número 1, lo cuál no es suficiente, es necesario alinearnos a la ley número 2 también. Ya en próximos posts veremos las siguientes leyes.