---
asset_id: PLB-EL-WORX-FlujoKanban-v01
version: v01
tipo: PLB — Playbook (contexto operativo)
proyecto: WORX — Modelo Operativo
owner: Victor Heredia / EmpowerLabs
fecha_creacion: 2026-04-18
estado: v01 — referencia consolidada
referencia_cruzada: MPB-EL-WORX-ModeloOperativo-v01 §4, §5
posicion: Lado Kanban del Dual Cadence. Complementario al Playbook de Sprint (por redactar).
---

# Playbook — Flujo Continuo Kanban en WORX
## Contexto operativo del lado Kanban del Dual Cadence

---

## INTRODUCCIÓN

### Por qué este Playbook existe

El modelo WORX opera bajo un **Dual Cadence**: flujo continuo Kanban + pulso sincronizado Sprint. Ambas modalidades conviven y se activan según la naturaleza del trabajo. El MPB referencia Kanban en varias secciones como la mecánica subyacente de los NEXT, los Tableros Personales y los Dashboards de Portafolio, pero no detalla sus principios ni su implementación específica dentro de WORX.

Este Playbook cierra esa brecha. Define qué es Kanban, cómo se materializa en el XDoc, qué WIP limits sugerir, y cómo se distingue el Kanban-en-WORX del Kanban tradicional que opera en apps como Jira, Trello o Asana.

### Audiencia

- Colaboradores que operarán bajo WORX y necesitan entender la mecánica del flujo.
- Runners y Sponsors que diseñan flujos de trabajo en sus XDocs.
- Consultores DO y líderes de transformación que implementan WORX en organizaciones.
- Futuros MePBs organizacionales que deriven del MPB — este Playbook es insumo común.

### Lo que este Playbook no es

No es una introducción genérica a Kanban. No es un manual de Jira o herramientas similares. No es un tratado Lean. Es un documento operativo que traduce los principios canónicos de Kanban al modelo WORX, con foco en lo que un trabajador necesita saber para operar con precisión.

---

## 1. ESENCIA DE KANBAN

### 1.1 Origen

Kanban nació en el sistema de producción de Toyota en los años 40 como mecanismo de señalización visual para coordinar el flujo de materiales entre estaciones. El principio: cada estación jala trabajo cuando está lista, no se le empuja. Esto elimina acumulación innecesaria, reduce desperdicio y hace visible cualquier estancamiento.

La traducción al trabajo del conocimiento llegó cuatro décadas después, formalizada por David Anderson en los 2000. El mismo principio: el equipo jala trabajo del backlog según capacidad; el flujo se visualiza; los cuellos de botella se ven y se atienden.

### 1.2 Los 5 principios canónicos

1. **Visualizar el flujo.** Todo el trabajo debe estar visible en algún lugar común. Si algo no está visible, no existe operativamente.
2. **Limitar el trabajo en progreso (WIP).** Hay un máximo de cosas que pueden estar abiertas a la vez. Menos, no más.
3. **Gestionar el flujo.** El objetivo es que el trabajo avance continuamente de un estado al siguiente, sin acumulación.
4. **Hacer las políticas explícitas.** Las reglas del flujo deben estar escritas: qué significa cada estado, cuándo algo pasa de un estado al siguiente, qué es un bloqueo.
5. **Mejorar continuamente.** El sistema se ajusta con base en la evidencia operativa, no con base en opiniones.

### 1.3 Qué NO es Kanban

- No es un tablero con post-its. El tablero es la vista, no el sistema.
- No es ausencia de planificación. Es planificación continua en lugar de planificación por sprint.
- No es trabajo sin estructura. Es trabajo con estructura de flujo, no de tiempo.
- No es sinónimo de agilidad. Es una disciplina de flujo; puede ser ágil o rígida según cómo se implemente.

### 1.4 Kanban vs Sprint (resumen)

| Dimensión | Kanban (flujo continuo) | Sprint (pulso sincronizado) |
|-----------|------------------------|----------------------------|
| Unidad de tiempo | Continuo | Ciclos fijos (1-4 semanas) |
| Unidad de planificación | Por item | Por sprint |
| Compromiso | WIP limit | Sprint goal |
| Cadencia | Emergente | Rítmica |
| Ideal para | Trabajo continuo, soporte, operación | Proyectos con objetivos acotados |
| Reunión principal | Daily + Retro ocasional | Planning + Review + Retro |

**En WORX ambos coexisten** (ver §6). La elección depende del XDoc, no de una decisión organizacional global.

---

## 2. MECÁNICA DEL FLUJO CONTINUO

### 2.1 Estados del flujo

Un item Kanban recorre estados hasta completarse. El número exacto depende del tipo de trabajo, pero el esquema canónico es:

```
Backlog → To Do → In Progress → Review → Done
```

Cada estado es una columna en la vista Kanban tradicional. El item avanza de izquierda a derecha. No retrocede excepto por bloqueo explícito.

### 2.2 WIP limits

El WIP (Work In Progress) es la cantidad de items simultáneamente en estado activo (In Progress, Review). El WIP limit es el máximo permitido.

**Por qué importa:** sin WIP limit, los items se acumulan en In Progress y nada se termina. El throughput (items completados por unidad de tiempo) cae. La Ley de Little lo formaliza: *Lead Time = WIP ÷ Throughput*. Menos WIP con el mismo throughput da menor lead time — se entrega más rápido.

**Regla general:** menos es más. Un WIP limit apretado fuerza al equipo a cerrar antes de abrir, y hace visibles los bloqueos.

### 2.3 Pull system

El colaborador *jala* trabajo al siguiente estado cuando tiene capacidad; nadie se lo empuja. Esto es lo opuesto al modelo push, donde la carga se asigna sin considerar capacidad disponible.

**Implicación cultural:** el Pull system requiere confianza. Asume que el colaborador es responsable de gestionar su capacidad y jalar trabajo cuando corresponde. Rompe el modelo de "asignación jerárquica" y lo sustituye por "disponibilidad visible".

### 2.4 Bloqueos visibles

Cuando un item no puede avanzar por causa externa (esperando input, decisión, dependencia), se marca como bloqueado. El bloqueo queda visible en el tablero y se escala al responsable.

**Principio:** un bloqueo invisible es un bloqueo que no se resolverá. Por eso Kanban exige hacer explícito todo lo que detiene el flujo.

### 2.5 Métricas del flujo

- **Cycle Time:** tiempo desde que un item entra a In Progress hasta que sale a Done.
- **Lead Time:** tiempo desde que un item entra al Backlog hasta Done.
- **Throughput:** items completados por unidad de tiempo (semana, mes).
- **Blocked Time:** tiempo acumulado en estado bloqueado.

Estas métricas se observan, no se gaman. Su función es diagnóstica: cuando suben, hay un problema que atender.

---

## 3. KANBAN EN WORX — CÓMO SE MATERIALIZA

El Kanban en WORX no es una app ni un tablero que alguien mantiene. Es una **vista emergente** generada por SherpaX a partir del estado del vault. El flujo es real, no representativo.

### 3.1 El NEXT es la unidad Kanban

Cada NEXT dentro de un XDoc es un item Kanban. El formato canónico ya está definido en el MPB §4.4.4:

```
NEXT[@Persona] — acción — deadline — contexto → estado
```

El `@Persona` es el owner de la tarjeta. La `acción` es el trabajo. El `contexto` es lo que le permite a otro leer el NEXT y entender por qué existe sin tener que preguntar.

### 3.2 Los 4 estados canónicos del NEXT = los estados del flujo

WORX usa un esquema de 4 estados que mapea directo a Kanban canónico:

| Estado NEXT en WORX | Estado Kanban equivalente | Significado |
|--------------------|---------------------------|-------------|
| `abierto` | To Do | Listo para ser jalado. Tiene contexto suficiente y asignado. |
| `en progreso` | In Progress | Alguien lo está trabajando activamente. Cuenta para el WIP limit. |
| `blocked por NEXT#N` | Blocked | No puede avanzar por dependencia. Debe tener causa visible. |
| `done` | Done | Completado, cerrado con entrada de CHANGELOG que lo referencia. |

No hay estado "Review" separado. Si una revisión es parte del flujo, se modela como NEXT propio: `NEXT[@Revisor] — revisar entregable X → abierto`.

### 3.3 El Tablero Personal = vista Kanban personal

Una de las 3 vistas del Morning Check (MPB §5). SherpaX agrega, de todos los XDocs del vault, los NEXTs donde yo soy `@Persona`, agrupados por estado. Es mi Kanban Board personal, generado bajo demanda, siempre al día.

```
Mi Tablero Personal (generado por SherpaX)
════════════════════════════════════════════

abierto                en progreso          blocked
────────────           ───────────          ────────
□ NEXT#7 CLI-Acme       ▣ NEXT#2 PRY-X       ▲ NEXT#5 CLI-Zeta
□ NEXT#3 PRY-X          ▣ NEXT#4 INT-Ops        ↳ bloqueado por
□ NEXT#9 INT-Ops                                 NEXT#6 (@Victor)
```

No hay base de datos separada, no hay app que mantener. Es una proyección del vault.

### 3.4 El Dashboard de Portafolio = vista Kanban agregada

Vista del Sponsor/Owner que agrega los NEXTs de todos sus XDocs por estado. Permite detectar: XDocs con muchos NEXT abiertos sin avance, XDocs con WIP excedido, bloqueos persistentes.

### 3.5 Pull system operacionalizado

El Colaborador WORX jala trabajo de su Tablero Personal al Morning Check. El Sherpa propone qué jalar según: urgencia, dependencias desbloqueadas, capacidad restante. El Colaborador confirma.

**Lo que rompe el pull:** que el Sponsor o el Runner agreguen NEXTs masivamente sin considerar el WIP del Colaborador. Los contratos lo prohíben implícitamente, pero requiere disciplina cultural.

### 3.6 Bloqueos y escalamiento automático

El MPB §4.4.2.1 define dependencias del XDoc en la sección ESTADO con tres estados: `pendiente`, `satisfecha`, `crítica`. Una dependencia `crítica` se promueve automáticamente a Bloqueo. Un NEXT cuyo avance dependa de una dependencia crítica pasa a estado `blocked`.

Este mecanismo es Kanban puro: el bloqueo es visible, escalado por el sistema, no oculto en conversaciones laterales.

---

## 4. WIP LIMITS SUGERIDOS

Los WIP limits son el parámetro que más impacto tiene en la salud del flujo. Demasiado alto: acumulación y throughput bajo. Demasiado bajo: ansiedad y cuellos de botella por subutilización. Los siguientes son **puntos de partida sugeridos**; cada organización calibra contra su realidad.

### 4.1 Por persona (colaborador individual)

| Rol | NEXTs en `en progreso` simultáneos |
|-----|-----------------------------------|
| Colaborador estándar | **3** |
| Runner (tiene el balón) | **4** (3 propios + 1 de coordinación activa) |
| Owner/Sponsor | **5** (portafolio, más ligeros) |

**Regla de bolsillo:** si tu Tablero Personal tiene más de 3 items en `en progreso`, probablemente no estás avanzando ninguno — estás rotando atención. Cierra uno antes de abrir otro.

### 4.2 Por XDoc

| Tipo de XDoc | NEXTs simultáneos en `en progreso` |
|--------------|----------------------------------- |
| Proyecto activo | **5-7** |
| Cliente en delivery | **3-5** |
| Iniciativa estratégica | **2-4** (avance por hitos) |
| Decisión vinculante | **1** (está o no está tomada) |

### 4.3 Por equipo (grupo de colaboradores sobre un track común)

Fórmula sugerida: **WIP equipo = 1.5 × número de colaboradores activos**. Un equipo de 4 tiene WIP limit de 6. Esto fuerza colaboración (no todos pueden estar trabajando solos en paralelo) y deja capacidad para atender bloqueos.

### 4.4 Por Sponsor

| Tamaño portafolio | XDocs activos simultáneos |
|------------------|---------------------------|
| Sponsor operativo | **5-8** |
| Sponsor ejecutivo | **10-15** |
| Sponsor C-level | **15-25** (con Runner por XDoc) |

El Sponsor no se mide por NEXTs — se mide por XDocs bajo su responsabilidad. Exceder estos rangos deteriora la capacidad de actuar por excepción (ver Contrato del Owner/Sponsor, MPB §7).

### 4.5 Cómo calibrar

Los números anteriores son puntos de partida. Para calibrarlos contra la realidad de la organización:

1. **Observar sin intervenir durante 2-3 semanas.** Medir cycle time promedio, WIP promedio, bloqueos. Usar SherpaX para la medición.
2. **Ajustar WIP limit un nivel a la vez.** No cambiar todos los límites a la vez — se pierde la capacidad de aislar el efecto.
3. **Bajar antes que subir.** La mayoría de las organizaciones opera con WIP excesivo. Cuando haya duda, reducir.
4. **Retro de Ritmo mensual.** El WIP es tema fijo: ¿el límite actual es el correcto? (Ver MPB §5, Rituales mínimos.)

---

## 5. KANBAN TRADICIONAL vs KANBAN-EN-WORX

| Dimensión | Kanban tradicional (Jira, Trello, Asana) | Kanban-en-WORX |
|-----------|------------------------------------------|----------------|
| **Unidad** | Tarjeta/ticket en una app dedicada | NEXT dentro del XDoc |
| **Persistencia** | Base de datos de la herramienta | Vault como fuente única de verdad |
| **Vista** | Tablero que se mantiene manualmente | Vista emergente generada por SherpaX bajo demanda |
| **Creación** | Formulario en la app | Línea de texto estructurada en NEXT del XDoc |
| **Contexto** | Descripción del ticket + comentarios | CONTEXTO y ESTADO del XDoc padre |
| **Cierre** | Click en "Done" / drag & drop | Entrada obligatoria en CHANGELOG que referencia el NEXT |
| **Bloqueos** | Label o campo custom | Promoción automática desde dependencia `crítica` en ESTADO |
| **Auditoría** | Log de eventos de la herramienta | CHANGELOG inmutable append-only + auditoría continua de SherpaX |
| **Personalización** | Workflows configurables, plugins | Estructura fija de 4 estados; personalización vive en el XDoc, no en el flujo |
| **Integración con otras apps** | Vía APIs, webhooks, plugins | Nativa — todo pasa por el vault; SherpaX orbita apps transaccionales |
| **Riesgo de fragmentación** | Alto — cada equipo configura su propio workflow | Bajo — el flujo canónico es el mismo para toda la organización |
| **Costo de cambio** | Migración de tickets + reconfiguración | Nulo — el vault no cambia, solo cambia la vista que SherpaX genera |
| **Rol de la IA** | Copiloto externo, no nativo | Nativo — SherpaX genera, alerta, propone promociones |
| **Fuente de verdad de estado** | La app | El XDoc (NEXT + CHANGELOG) |

**La diferencia nuclear:** en Kanban tradicional el tablero es el sistema; en WORX el tablero es una vista derivada. Esto tiene cuatro consecuencias prácticas:

1. Nadie "mantiene" el tablero. Si el vault está al día (vía Sherpa), el tablero está al día.
2. No hay conflicto entre "estado en la app" y "estado real" — son el mismo.
3. El tablero no es el lugar donde se trabaja. El XDoc es. El tablero solo lo muestra.
4. Migrar a otra herramienta no requiere migración de datos. Requiere una nueva vista.

---

## 6. POSICIÓN EN EL DUAL CADENCE

WORX no impone Kanban a toda la organización. Opera con **Dual Cadence**: flujo continuo Kanban + pulso sincronizado Sprint, según la naturaleza del trabajo.

### 6.1 Cuándo Kanban

- Trabajo continuo: soporte, operación, account management, research continuo.
- Prioridades cambiantes día a día.
- Equipos heterogéneos atendiendo múltiples fuentes de demanda.
- Procesos repetitivos con throughput constante.

### 6.2 Cuándo Sprint

- Proyectos con objetivo acotado y entregable definido.
- Trabajo que requiere coordinación intensiva en ventana corta.
- Desarrollo de producto con ciclos de release.
- Hitos vinculados a compromisos externos con fecha.

### 6.3 Cómo coexisten

Un mismo colaborador puede tener simultáneamente NEXTs de XDocs Kanban (operación) y NEXTs de XDocs Sprint (proyecto). Su Tablero Personal los muestra unificados por estado del flujo; no hay diferencia visual. La diferencia vive en la cadencia con la que el XDoc es revisado:

- **XDoc Kanban:** revisión diaria del Estado; WIP limit por XDoc; ritmo continuo.
- **XDoc Sprint:** Sprint Planning cada N días; revisión al cierre del sprint; ritmo pulsado.

El Dual Cadence se configura en el CONTEXTO del XDoc. No es decisión individual — es elección del Sponsor y Runner al crear el XDoc.

*(Nota: el lado Sprint del Dual Cadence está documentado en el Playbook correspondiente — por redactar.)*

---

## 7. PRINCIPIOS KANBAN TRADUCIDOS A LOS CONTRATOS WORX

Los 5 principios canónicos de Kanban ya están presentes en los 5 Contratos de WORX (MPB §7). Esta es la traducción explícita:

### 7.1 Visualizar el flujo → Morning Check

El Contrato del Colaborador punto 1 (*Morning Check antes de empezar a trabajar*) es Kanban: mi flujo es visible cada mañana vía Tablero Personal.

### 7.2 Limitar WIP → Disciplina del Colaborador

El Colaborador se autoimpone un WIP limit (3 items en `en progreso` sugerido). El Sherpa puede alertar cuando se excede: *"Ya tienes 4 NEXTs en progreso. ¿Cierras uno antes de abrir el siguiente?"*

### 7.3 Gestionar el flujo → Responsabilidad del Runner

El Contrato del Runner punto 1 (*sostener el Estado del doc al menos semanalmente*) es Kanban: el flujo se gestiona, no se observa pasivamente. El Runner detecta acumulación, redistribuye, desbloquea.

### 7.4 Políticas explícitas → Los 5 Contratos

Los 5 Contratos del MPB (Colaborador, Runner, Owner, Sponsor, Humano-IA) son las políticas explícitas del sistema. Nada queda implícito: qué significa cada rol, qué se compromete cada uno, qué puede y qué no puede hacer SherpaX.

### 7.5 Mejora continua → [LEARN] + Retro de Ritmo

El tag `[LEARN]` en CHANGELOG captura aprendizajes granulares. El ritual mensual Retro de Ritmo (MPB §5) los consolida en ajustes al sistema: WIP limits, políticas, protocolos.

---

## 8. PITFALLS — LO QUE ROMPE KANBAN EN WORX

Ocho fallas recurrentes que colapsan el modelo. Identificarlas temprano es parte de la salud operativa auditable por SherpaX.

1. **WIP limits sin respeto.** Si el colaborador abre sin cerrar, el tablero no refleja realidad. Cultura de "cerrar antes de abrir" es innegociable.

2. **NEXTs sin contexto.** Un NEXT que dice *"revisar documento"* sin más contexto no es operable. La línea debe contener lo mínimo que permita a otro humano o a un agente entenderlo sin abrir el XDoc.

3. **Estado `done` sin CHANGELOG.** Rompe la regla inviolable. Deja el flujo como espejismo: dice que algo se hizo pero no hay evidencia. SherpaX lo detecta y lo reporta.

4. **Bloqueos conversacionales fuera del XDoc.** Si el Colaborador dice *"estoy bloqueado"* por Slack o WhatsApp en lugar de marcar `blocked` + escribir en DISCUSSION + escalar al Runner, el bloqueo es invisible al sistema. La regla: todo bloqueo se declara en el XDoc.

5. **Tableros mantenidos a mano.** Alguien que exporta a Jira "para tener vista bonita". Es tiempo doble, y crea divergencia entre vault y app. El tablero es vista, no registro.

6. **WIP limit sin regla de entrada.** Bajar el WIP sin controlar qué entra al Backlog mueve el problema, no lo resuelve. El Sponsor filtra el ingreso (Contrato del Sponsor).

7. **Kanban impuesto donde Sprint funciona mejor.** Un proyecto con deadline fijo y alcance cerrado no es Kanban — es Sprint. Forzar flujo continuo ahí crea ansiedad y pérdida de cadencia. Dual Cadence existe por una razón.

8. **Métricas como vigilancia en lugar de diagnóstico.** Cycle time, throughput, WIP son diagnósticas. Usarlas para evaluar desempeño individual corrompe el sistema: la gente infla estados, esconde bloqueos, cierra NEXTs prematuramente. El contrato con el Corp Brain OS lo prohíbe implícitamente (datos agregados, no individuales para medición).

---

## CIERRE

Kanban en WORX no es una herramienta, ni un tablero, ni una metodología paralela. Es la **mecánica del flujo del NEXT**: la forma en que el trabajo atómico atraviesa sus cuatro estados canónicos dentro del XDoc, visible para quien lo ejecuta y para SherpaX, auditable contra el CHANGELOG, gobernada por WIP limits y contratos explícitos.

Lo que WORX aporta a Kanban no es una reinvención conceptual — los principios siguen siendo los de Anderson y Toyota. Lo que aporta es **la eliminación del tablero como artefacto separado**: el flujo vive en el vault, la vista emerge bajo demanda, y la fuente única de verdad es el XDoc. Este colapso entre sistema y vista es lo que vuelve al modelo sostenible a escala organizacional sin la fragmentación típica de apps de gestión.

El Dual Cadence (Kanban + Sprint) garantiza que la organización no se fuerce a una sola modalidad cuando la realidad operativa requiere ambas. La elección vive al nivel del XDoc, no al nivel organizacional.

---

## REFERENCIAS CRUZADAS

- **MPB-EL-WORX-ModeloOperativo-v01 §4** — Nivel 1: El XDoc (estructura, estados canónicos de NEXT, ciclo de cierre).
- **MPB-EL-WORX-ModeloOperativo-v01 §5** — Nivel 2: El Ritmo de Uso (Dual Cadence, Tablero Personal, Dashboard de Portafolio, rituales).
- **MPB-EL-WORX-ModeloOperativo-v01 §7** — Los 5 Contratos (Colaborador, Runner, Owner, Sponsor, Humano-IA).
- **PLB-EL-WORX-FlujoSprint-v01** — *(por redactar)* — Lado Sprint del Dual Cadence, complementario a este Playbook.

---

*PLB-EL-WORX-FlujoKanban-v01 · EmpowerLabs / WORX · 2026-04-18*
*Playbook del lado Kanban del Dual Cadence — contexto operativo para el MPB WORX*