Antes de bucear en los recursos, comprueba qué se te ha quedado de la sesión: recordar de forma activa fija mucho más que releer. No hay nota ni castigo, y si fallas te explico el porqué.
Repaso · Pregunta 1/6
Si un equipo pasa de 5 a 10 personas, ¿cómo crece el número de canales de comunicación?
Se duplica, igual que el tamaño del equipo.
Crece cuadráticamente: aproximadamente se cuadruplica.(respuesta)
Se mantiene igual si nadie cambia de rol.
Los canales siguen la fórmula n(n-1)/2. De 5 personas (10 canales) a 10 (45 canales): no se duplica, se cuadruplica. Por eso los equipos grandes son lentos por matemática, no por incompetencia.
Según la Ley de Little, si bajamos el WIP (trabajo en curso) manteniendo el throughput, ¿qué pasa con el tiempo de entrega?
Aumenta: hacer menos cosas a la vez nos ralentiza.
Baja: limitar el WIP acelera la entrega de cada cosa.(respuesta)
No cambia: el WIP no influye en la entrega.
Tiempo de entrega = WIP / Throughput. Si bajas el WIP y el throughput se mantiene, el tiempo de entrega baja. Menos trabajo en paralelo significa terminar antes cada tarea (recuerda el aforo del Jardín Imperial).
En un sistema pull (como Kanban), ¿cuándo coge el equipo trabajo nuevo?
Cuando alguien externo se lo empuja por demanda.
Solo cuando termina algo y tiene capacidad libre.(respuesta)
Al inicio del sprint, todo de golpe.
Pull significa tirar del trabajo: el equipo coge algo nuevo solo cuando termina lo anterior. Eso da foco, flujo y predictibilidad, frente al push que satura el sistema y deja todo a medias.
Un equipo planifica y ejecuta, pero nunca revisa qué pasó ni ajusta. En términos de PDCA, ¿qué les falta?
Nada: con Plan y Do ya son ágiles.
El Check y el Act: sin ellos siguen siendo cascada.(respuesta)
Más documentación en la fase de Plan.
Plan-Do-Check-Act es la columna vertebral de Agile, Scrum y Kaizen. Si solo haces Plan + Do eres cascada. El Check (mirar qué pasó) y el Act (ajustar), que viven en las retrospectivas, es lo que te vuelve ágil.
La Ley de Conway dice que las organizaciones diseñan sistemas que copian su estructura de comunicación. ¿Qué implica en la práctica?
Que para cambiar el producto, conviene cambiar la organización.(respuesta)
Que el software siempre acaba bien integrado por defecto.
Que la estructura de equipos no afecta al producto.
Si la empresa tiene 4 departamentos aislados, su software tendrá 4 módulos mal integrados. La "maniobra inversa de Conway" usa esto a favor: diseña los equipos según el producto que quieres obtener.
Según la Teoría de las Restricciones (Goldratt), ¿qué determina la velocidad de todo el sistema?
La suma de la velocidad de todas las etapas.
El cuello de botella: el sistema solo va tan rápido como su restricción.(respuesta)
La etapa más rápida, que arrastra a las demás.
El sistema es tan rápido como su cuello de botella. Optimizar cualquier otro punto no acelera el conjunto. El método: identificar la restricción, explotarla y subordinar todo lo demás a ella.
Capítulo 1
El terreno: comunicación y mindset
Antes de los marcos, el contexto: por qué los equipos se ralentizan, qué es Agile en realidad y cómo elegir entre planificar e iterar.
01
Nodos de comunicación en equipos
~3 min
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.
Simulador interactivo · Ley de Brooks
Mueve el slider y observa cómo crecen las conexiones.
225
Canales de comunicación
10
Complejidad relativa
200%
C(n) =n · (n − 1)2
Por qué importa
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.
Recursos
ConceptoLey de Brooks: "Adding manpower to a late software project makes it later." · de The Mythical Man-Month (Fred Brooks, 1975). Resumen.
ConceptoTwo-pizza teams (Amazon): si no pueden alimentar al equipo con dos pizzas,
es demasiado grande.
02
Agile, el paraguas
~2 min
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.
Por qué importa
Si no entendéis los principios, cualquier marco se convierte en burocracia disfrazada de
agilidad ("hacemos dailies, somos ágiles" → no necesariamente).
LecturaLos 12 principios · el Manifiesto sin los principios es la mitad del mensaje.
LibroAgile State of Mind, por Henrik Kniberg · corto, claro, con dibujos.
03
Waterfall vs Agile
~2 min
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.
Por qué importa
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.
Por qué importa
Sirve para tener conversaciones honestas con stakeholders. "Si añadimos
esto, ¿qué quitamos, cuánto retrasamos o cuánto más cuesta?".
Interactivo · Triángulo de hierro
Compara los dos enfoques. Lo que se fija, manda.
Fijo Variable
Cascada · predictivo
Los tres ejes fijos
En cascada se compromete TODO al inicio: alcance, tiempo y coste. Si algo se mueve, suele ser a costa de la calidad, porque los tres ejes están atados al plan original.
Riesgo: cualquier imprevisto empuja la calidad hacia abajo. Funciona solo cuando el problema es conocido y estable.
Los marcos que ordenan la ejecución: iterar en sprints (Scrum), visualizar y tirar del flujo (Kanban) y por qué limitar el trabajo en curso lo acelera todo.
05
Scrum
~3 min
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).
Por qué importa
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.
Interactivo · Mini Kanban
Pulsa una tarjeta para moverla. El sistema tira del trabajo, no lo empuja.
Por hacer4
En curso1 / 2
Hecho2
Brief inicial
Wireframes
①
Límite WIP 2 en "En curso": si está lleno, no se puede tirar más
trabajo.
②
Pull criteria: criterios de aceptación claros para pasar de columna. Una
tarjeta solo entra en "En curso" si tiene contexto, dependencias resueltas y dueño claro.
Solo pasa a "Hecho" si cumple la Definition of Done.
③
Sistema pull: la siguiente persona que termina algo, tira de la
próxima tarjeta. Nadie empuja trabajo hacia un equipo lleno.
Por qué importa
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.
Push
Empujar trabajo
Se mete trabajo al sistema por demanda externa. Resultado: todo a medias, nada terminado.
Pull
Tirar del trabajo
El equipo coge trabajo nuevo solo cuando termina algo. Resultado: foco,
flujo, predictibilidad.
El Jardín Imperial y el control del aforo
Los Jardines del Palacio Imperial de Tokio (Kōkyo Higashi Gyoen) tienen un sistema de aforo
elegante: al entrar, cada visitante recibe una placa numerada. Solo se
entregan tantas placas como personas se considera saludable que estén dentro a la vez. Cuando
alguien sale, devuelve la placa, y solo entonces puede entrar el siguiente.
Eso es limitar el WIP. Eso es un sistema pull. No se trata
de "echar a la gente" del jardín ni de empujarla a entrar: se trata de proteger la
experiencia de quienes ya están dentro y respetar la capacidad real del sistema.
El mismo principio aplica a sus equipos: si están saturados, no metan más trabajo. Esperen a
que devuelvan una "placa".
Ley de Little:Tiempo medio de entrega = WIP / Throughput. Bajar
el WIP acelera la entrega.
La cultura que sostiene todo lo anterior: mejorar a diario (Kaizen), ir a donde ocurre el trabajo (Gemba), el ciclo que lo articula (PDCA) y el evento que cambia el sistema (retrospectivas).
08
Kaizen· 改善 · mejora continua
~2 min
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.
Por qué importa
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.
Por qué importa
Casi todas las decisiones de gestión malas vienen de tomarlas lejos del Gemba. Les ahorra
horas de reuniones inútiles.
Planificar, ejecutar, inspeccionar y adaptar· ciclo PDCA
~2 min
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.
Por qué importa
Si hacen solo plan + do, son cascada. Si añaden check + act (retrospectivas), se vuelven
ágiles.
Para cerrar, las leyes y herramientas que dan criterio: por qué el trabajo se dilata (Parkinson), cómo la organización moldea el producto (Conway), qué significa «terminado» (DoD), cómo alinear la estrategia (OKRs) y dónde está el cuello de botella (TOC). De aquí en adelante, bonus: cosas que conviene conocer aunque no las vimos en clase.
12
Ley de Parkinson
~2 min
"El trabajo se expande hasta llenar el tiempo disponible para su realización."
Cyril Northcote Parkinson, 1955
Por qué importa
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.
"Las organizaciones diseñan sistemas que son copias de su estructura de comunicación."
Melvin Conway, 1968
Por qué importa
Si su empresa tiene 4 departamentos, su software tendrá 4 módulos mal integrados. Para
cambiar el producto, cambien la organización (Inverse Conway Maneuver).
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".
Criterios de aceptación
¿Qué tiene que cumplir esta tarea para considerarse aceptada?
Lista concreta y verificable, específica de cada tarea.
Formato "Dado / Cuando / Entonces" o checklist clara.
Acordada con el Product Owner antes de empezar.
Define el alcance funcional: qué debe hacer, no cómo.
Definition of Done
¿Está terminada para poder entregarla?
Código revisado y mergeado.
Tests automáticos pasando.
Documentación actualizada.
Validado en entorno de staging.
Cómo encajan: los criterios de aceptación son específicos de
cada tarea (¿hace lo que debe?), y la DoD es la puerta de salida común a todas
las tareas (¿está lista para entregarla?). Sin ambos, todo es opinión.
15
OKRs· Objectives & Key Results
~3 min
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).
Ejemplo aplicado
O
Objetivo
Ser la referencia formativa de Agile en Canarias
KR 1
Pasar de 2 a 6 universidades como cliente
26
KR 2
Subir el NPS de alumnos
4570
KR 3
Publicar piezas de contenido referenciadas por terceros
08
Por qué importa
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?".
Reglas de oro: 3–5 Objetivos como máximo, 3–5 KRs por Objetivo. Si un KR no se
puede medir con un número y una fecha, no es un KR. Revisión semanal o quincenal, no anual.
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.
