Sistemas Pull vs. Push
Comprender el cambio fundamental de asignar trabajo a jalar trabajo.
1Push: Asignación Tradicional de Trabajo
En un sistema push, el trabajo se asigna a las personas. Un gerente o sistema decide quién hace qué y cuándo.
Características del push:
- Una autoridad central hace las asignaciones
- El trabajo se empuja a las colas frente a los trabajadores
- Los trabajadores procesan lo que llega a su cola
- La sobrecarga es invisible hasta que hay crisis
Problemas con push:
- No toma en cuenta la capacidad real
- Crea sobrecargas locales
- No hay ciclo de retroalimentación hacia la fuente de demanda
- Fomenta iniciar en lugar de terminar
2Pull: El Modelo de Kanban
En un sistema pull, los trabajadores toman el siguiente elemento cuando tienen capacidad. El trabajo es "jalado" a través del sistema por la demanda descendente.
Características del pull:
- Los trabajadores autoseleccionan el siguiente elemento según prioridad
- Los límites WIP previenen la sobrecarga
- La capacidad gobierna el ritmo
- La demanda se suaviza naturalmente
Cómo funciona:
- El desarrollador termina una tarea, creando capacidad
- El desarrollador mira la columna "Listo" y jala el siguiente elemento prioritario
- Esto crea capacidad en "Listo" que se repone
- La señal se propaga hacia arriba, limitando la entrada de nuevo trabajo
El cambio clave: nada comienza hasta que algo termina. Esto es lo que los límites WIP hacen cumplir.
Los sistemas pull se autorregulan. Cuando la capacidad disminuye (alguien enfermo, problema difícil), el sistema automáticamente reduce la entrada. Los sistemas push crean acumulaciones.
3El Mecanismo de Señal
En las fábricas de Toyota, las tarjetas kanban físicas creaban la señal: "Usé esta pieza, envía más."
En el trabajo de conocimiento, la señal es: espacio en la siguiente columna.
Cuando la columna de Revisión de Código tiene capacidad (WIP no al límite), señala que Desarrollo puede terminar algo y moverlo.
Cuando la columna de Revisión de Código está llena (al límite WIP), señala que Desarrollo debería ayudar con revisiones o no iniciar nuevo trabajo de desarrollo.
Por esto los límites WIP son esenciales—sin ellos, no hay señal. El trabajo simplemente se acumula.
4Implementar Pull en la Práctica
Hacer que pull funcione:
-
Prioridades claras: Al jalar, ¿qué sigue? ¿FIFO dentro de clase? ¿Lo más impactante? Los equipos necesitan criterios compartidos.
-
Capacidad visible: El tablero muestra cuándo existe capacidad (columna debajo del límite WIP).
-
Acuerdo del equipo: Todos jalan; nadie empuja. Los gerentes no asignan—pueden resaltar prioridades, pero los trabajadores jalan.
-
Seguridad psicológica: Jalar requiere agencia. Si las personas temen elegir mal, esperarán asignaciones.
El rol de los product owners/gerentes:
- Establecer prioridades (qué debe jalarse primero)
- Proteger el backlog (qué entra al sistema)
- No asignar trabajo a individuos
Transición de push a pull:
- Comenzar haciendo las asignaciones visibles, no eliminándolas
- Gradualmente cambiar a autoselección
- Entrenar a los gerentes para que dejen de asignar
- Celebrar jalones exitosos
El desarrollador termina una funcionalidad. Mira la columna 'Listo para Dev'. Hay tres elementos. Jala el de arriba (prioridad más alta, según acuerdo del equipo). Mueve la tarjeta a 'En Dev'. Todo el equipo puede ver que esto sucedió.
El equipo dice hacer Kanban. Pero el líder del equipo envía mensajes directos a los desarrolladores diciendo 'trabaja en X después'. El tablero muestra pull, pero la realidad es push. Las señales están rotas.
- Los sistemas push asignan trabajo; los sistemas pull hacen que los trabajadores tomen trabajo
- Los límites WIP crean la señal que habilita el pull
- El pull se autorregula—cuando la capacidad baja, la entrada se reduce
- La transición de push a pull es cultural, no solo mecánica