Sistemas Pull vs. Push
Comprender el cambio fundamental de asignar trabajo a extraer 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 la crisis
Problemas con el push:
- No tiene en cuenta la capacidad real
- Crea sobrecargas locales
- No hay bucle de retroalimentación hacia la fuente de demanda
- Fomenta comenzar 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 "extraído" a través del sistema por la demanda descendente.
Características del pull:
- Los trabajadores autoseleccionan el siguiente elemento según la 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 extrae 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 las revisiones o no comenzar nuevo trabajo de desarrollo.
Por eso los límites WIP son esenciales—sin ellos, no hay señal. El trabajo simplemente se acumula.
4Implementando Pull en la Práctica
Haciendo que el pull funcione:
-
Prioridades claras: Al extraer, ¿qué sigue? ¿FIFO dentro de la clase? ¿Más impactante? Los equipos necesitan criterios compartidos.
-
Capacidad visible: El tablero muestra cuándo existe capacidad (columna por debajo del límite WIP).
-
Acuerdo del equipo: Todos extraen; nadie empuja. Los gerentes no asignan—pueden resaltar prioridades, pero los trabajadores extraen.
-
Seguridad psicológica: Extraer requiere agencia. Si las personas temen elegir mal, esperarán asignaciones.
El rol de los product owners/gerentes:
- Establecer prioridades (qué debe extraerse primero)
- Proteger el backlog (qué entra al sistema)
- No asignar trabajo a individuos
Transición de push a pull:
- Comenzar haciendo visibles las asignaciones, no eliminándolas
- Cambiar gradualmente a la autoselección
- Entrenar a los gerentes para que dejen de asignar
- Celebrar las extracciones exitosas
El desarrollador termina una funcionalidad. Mira la columna 'Listo para Dev'. Hay tres elementos. Extrae el primero (máxima prioridad, 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 el 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