Por qué los sistemas pull crean visibilidad y responsabilidad que los sistemas push ocultan.
Los sistemas push inician el trabajo basándose en pronósticos o cronogramas. Un gerente asigna trabajo. Se planifica un sprint. El trabajo entra al sistema haya o no capacidad.
Los sistemas pull inician el trabajo basándose en capacidad y demanda. El trabajo solo entra cuando un paso posterior señala que está listo. Nada se empuja—se jala a través del sistema.
El origen en Toyota: En un sistema push, las partes se fabrican basándose en pronósticos y se empujan hacia adelante. En el sistema pull de Toyota, los procesos posteriores envían una señal (tarjeta kanban) cuando necesitan partes. Las partes se producen solo cuando se señalan.
En software:
Las matemáticas son contraintuitivas: menos elementos a la vez, más elementos terminados.
La Diferencia de Visibilidad
Los sistemas push ocultan problemas. La pila de trabajo sin terminar se acumula invisiblemente. Los sistemas pull revelan problemas. Cuando no puedes jalar trabajo nuevo porque estás bloqueado, el bloqueo es visible. Esta visibilidad fuerza la resolución.
En un sistema push, los problemas quedan enterrados.
El equipo tiene 15 elementos en progreso. Tres están bloqueados esperando decisiones de arquitectura. Pero el trabajo continúa en los otros 12. Los bloqueos son invisibles entre la actividad.
Al final del sprint, esos 3 elementos siguen bloqueados. Ahora es una crisis. "¿Por qué nadie mencionó esto?" Porque el sistema no lo forzó.
Los sistemas push también ocultan problemas de capacidad. Si empujas más trabajo del que puedes manejar, el exceso simplemente se acumula. El tiempo de entrega crece, pero desde afuera, "todos están trabajando duro".
Los sistemas push optimizan para iniciar. Los sistemas pull optimizan para terminar.
Pensamiento push: "¡Iniciamos 20 elementos este sprint!" (Pero terminamos 8.) Pensamiento pull: "Terminamos 15 elementos este sprint". (E iniciamos 15.)
¿Cuál preferirían tus clientes?
El equipo se compromete a 20 historias basándose en velocidad. A mitad del sprint, tres historias están bloqueadas por una dependencia. El trabajo continúa en otras. Al final del sprint: 8 completas, 12 parcialmente terminadas. Los 3 elementos bloqueados siguen bloqueados.
El límite de WIP es 3. Un desarrollador jala una historia pero está bloqueada por una dependencia. No pueden jalar nada nuevo—se alcanzó el límite. El bloqueo es inmediatamente visible. El equipo se agrupa para resolverlo. El tiempo de entrega se mantiene corto.
Los sistemas pull son más difíciles de manipular que los sistemas push.
En un sistema push, puedes parecer productivo mientras acumulas deuda. "¡Estoy trabajando en 8 cosas!" (Ninguna terminada.) "¡Completé 50 puntos de historia!" (Pero la mitad están atascados en revisión.)
En un sistema pull, el único trabajo válido es el trabajo terminado. No puedes iniciar algo nuevo hasta que algo termine. Manipular es más difícil porque el sistema fuerza la finalización.
Esta responsabilidad se extiende a problemas de bloqueo:
Los sistemas pull alinean incentivos con resultados. El sistema recompensa terminar, no iniciar. Recompensa desbloquear, no trabajar alrededor de bloqueos. Recompensa rendimiento, no ocupación.
Esto es incómodo para algunos equipos. Los sistemas push te permiten sentirte productivo incluso cuando no estás entregando. Los sistemas pull hacen visible la brecha. Eso es una característica, no un error.
Pull Requiere Valentía
Los sistemas pull sacan a la superficie problemas que los sistemas push ocultan. Algunas organizaciones adoptan pull y luego lo abandonan porque 'está exponiendo demasiados problemas'. Esos problemas siempre existieron—pull solo los hizo visibles. El objetivo es arreglarlos, no volver a ocultarlos.