Lo que vimos hoy y dónde profundizar después

El número de canales de comunicación crece cuadráticamente con el tamaño del equipo: n × (n − 1) / 2. Pasar de 5 a 10 personas no duplica la complejidad: la cuadruplica.

Equipos grandes no son lentos por incompetencia: son lentos por matemática. La solución no es exigir más esfuerzo, es partir el equipo o reducir interdependencias.

Agile no es un método, es un conjunto de valores y principios recogidos en el Manifiesto Ágil (2001). Por debajo de ese paraguas viven Scrum, Kanban, XP, Lean, etc.

Si no entendéis los principios, cualquier marco se convierte en burocracia disfrazada de agilidad ("hacemos dailies, somos ágiles" → no necesariamente).

Waterfall = predecir todo al inicio y ejecutar en cascada. Agile = aceptar que no lo sabemos todo y trabajar en ciclos cortos que nos dan información para corregir.

No es que uno sea mejor que otro en abstracto — cada uno encaja en un tipo de problema. Waterfall funciona cuando el problema es conocido y estable (construir un puente). Agile funciona cuando hay incertidumbre (construir un producto digital).

Alcance, tiempo y coste están conectados — no puedes mover uno sin afectar a los otros dos. La calidad queda en el centro y es lo que sufre cuando se intenta engañar al triángulo.

Sirve para tener conversaciones honestas con stakeholders. "Si añadimos esto, ¿qué quitamos, cuánto retrasamos o cuánto más cuesta?".

Marco para entregar valor en iteraciones cortas (sprints). Tres roles (Product Owner, Scrum Master, Equipo), cinco eventos (Sprint, Planning, Daily, Review, Retro) y tres artefactos (Product Backlog, Sprint Backlog, Incremento).

Es el marco más extendido del mundo. Conocerlo bien — incluso si no lo usan tal cual — les da un vocabulario común con la industria.

Sistema pull de gestión visual del trabajo. Tres principios mínimos: visualizar el flujo, limitar el WIP y gestionar el flujo. No prescribe roles ni eventos: se monta encima de lo que ya tienen.

Es el método menos intrusivo para empezar a mejorar. Ideal cuando el trabajo no encaja en sprints (soporte, operaciones, multi-proyecto).

WIP es el trabajo empezado y no terminado. Limitar el WIP es contraintuitivo pero brutal: cuanto menos trabajo en paralelo, más rápido terminas cada cosa.

Filosofía japonesa de mejora constante y en pequeños pasos. No buscar la revolución; buscar el 1% diario. Acumulado, es lo que separa a una organización buena de una excelente.

Es la base cultural sobre la que se sostienen las retrospectivas. Sin mentalidad Kaizen, las retros son teatro.

Para entender un problema, ve al sitio donde ocurre el trabajo real. No al despacho del jefe, no al PowerPoint del informe: al sitio donde se produce el valor o donde se atasca.

Casi todas las decisiones de gestión malas vienen de tomarlas lejos del Gemba. Les ahorra horas de reuniones inútiles.

El ciclo Plan-Do-Check-Act (Deming/Shewhart) es la columna vertebral de Agile, Kaizen, Scrum y casi todo lo demás. Planificar → hacer → mirar qué pasó → ajustar → repetir.

Si hacen solo plan + do, son cascada. Si añaden check + act (retrospectivas), se vuelven ágiles.

Espacio estructurado para que el equipo mire hacia atrás y mejore su forma de trabajar. Es el momento del "check + act" del PDCA.

Es el único ritual que cambia el sistema. El resto solo ejecuta dentro del sistema.

Por eso los sprints son cortos. Por eso ponemos timeboxes a las reuniones. Por eso una tarea con plazo de 2 semanas tarda 2 semanas — aunque podría haberse hecho en 3 días.

Dos acuerdos escritos del equipo. Cada uno responde a una pregunta distinta — y juntos eliminan el 80% de las discusiones del tipo "esto no está terminado".

Marco para conectar la estrategia con la ejecución. Cada Objetivo describe a dónde queremos llegar (cualitativo, inspirador) y cada Resultado Clave mide si estamos llegando (cuantitativo, verificable).

Sin OKRs (o algo equivalente), los equipos están ocupados pero no necesariamente alineados. Con OKRs, cualquier persona puede responder sin dudarlo: "esto que estoy haciendo, ¿a qué objetivo contribuye?".

De Eliyahu Goldratt. La idea: el sistema solo es tan rápido como su cuello de botella. Optimizar cualquier otro punto no acelera el conjunto. Identificar el cuello de botella → explotarlo → subordinar todo lo demás a él.