Si llevas más de un año programando, ya pasaste por alguna versión de esto: una daily de 25 minutos donde tres personas leen su Jira en voz alta, una sprint planning de dos horas donde se vota con cartas de póker, una retro que produce ocho action items que nadie va a hacer, y un tablero con 47 tareas marcadas “en progreso”. A eso le llamamos Agile, y luego nos preguntamos por qué nadie quiere ir a la junta.
Spoiler: eso no es Agile. Es teatro de Agile. Y para empeorarlo, los autores originales del manifiesto llevan 20 años diciéndolo y nadie les hace caso.
Vamos a hablar de lo que sí sirve.
Lo que dijo el manifiesto (el de verdad, no el de tu PMO)
Del 11 al 13 de febrero de 2001, 17 personas se juntaron en The Lodge at Snowbird, una estación de esquí en Utah, y escribieron un documento de 68 palabras. Los 17 nombres están listados en agilemanifesto.org/history.html e incluyen a Kent Beck (XP, JUnit, TDD), Ward Cunningham (el inventor de la wiki), Martin Fowler, Robert C. Martin, Andy Hunt, Dave Thomas, Jeff Sutherland y Ken Schwaber (los dos co-creadores de Scrum), entre otros. Todos eran programadores. Ninguno era Agile coach.
El documento dice cuatro cosas:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.”
(Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. Valoramos: a las personas y sus interacciones sobre los procesos y las herramientas; el software que funciona sobre la documentación exhaustiva; la colaboración con el cliente sobre la negociación contractual; y responder al cambio sobre seguir un plan.)
Hay una frase final que casi nadie lee y que cambia todo:
“That is, while there is value in the items on the right, we value the items on the left more.”
(Es decir, aunque hay valor en lo de la derecha, valoramos más lo de la izquierda.)
Léelo otra vez. No dice “ignora los procesos”. Dice “cuando tengas que elegir, prioriza personas, software funcionando, colaboración real y adaptarte al cambio”. Es una jerarquía, no una negación.
Lo que pasó después es bien conocido y un poco trágico: el manifiesto fue secuestrado por la industria de la consultoría. Allen Holub —que lleva décadas haciendo software y otra década en charlas y LinkedIn criticando lo que la industria hizo con Agile— ha sostenido en repetidas ocasiones que la mayoría de lo que hoy se vende como Agile horrorizaría a quienes firmaron el manifiesto. Y hasta Andy Hunt, uno de los 17 firmantes, escribió en mayo de 2015 un ensayo titulado “The Failure of Agile”. Cuando los autores del manifiesto dicen que su propio movimiento fracasó, vale la pena escuchar.
Dato útil de citar en una junta: el manifiesto está en agilemanifesto.org y son tres pantallas. Te toma menos leerlo entero que esperar tu turno en la próxima daily.
Los 12 principios, en cristiano
Detrás del manifiesto hay 12 principios, y de esos 12 hay tres que importan más que el resto si eres ingeniero:
“Working software is the primary measure of progress.”
(El software que funciona es la medida principal del progreso.)
Traducción: tu sprint no se mide en story points completados. Se mide en si hay algo en producción que no estaba el lunes. Si terminaste 47 puntos pero no sacaste nada, no avanzaste.
“Continuous attention to technical excellence and good design enhances agility.”
(La atención continua a la excelencia técnica y al buen diseño aumenta la agilidad.)
Traducción: deuda técnica te quita velocidad. Es contraintuitivo en el corto plazo —“vamos rápido, ya refactorizamos después”— y devastador en el mediano. Cualquier metodología que te empuje a acumular deuda para “cumplir con el sprint” no es ágil; es una hipoteca.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
(A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, y ajusta su comportamiento.)
Traducción: las retros existen. Pero —y esto se les olvida a muchos— el principio dice “adjusts its behavior”, no “produce action items”. Una retro sin cambio de comportamiento es terapia grupal cara.
Scrum: qué es realmente y de dónde sale
Aquí hay un detalle histórico que casi nadie sabe: Scrum no nació en TI. Vino de un paper de enero de 1986 en Harvard Business Review llamado “The New New Product Development Game”, escrito por Hirotaka Takeuchi e Ikujiro Nonaka. Ese paper estudiaba cómo equipos de Honda, Canon y Fuji-Xerox desarrollaban productos físicos —cámaras, impresoras, autos— y notaron que los equipos exitosos no trabajaban en cadena (“primero diseño, luego ingeniería, luego producción”) sino en bloque, como un scrum de rugby donde todos empujan juntos. De ahí el nombre.
Jeff Sutherland y Ken Schwaber tomaron esa idea en los 90 y la convirtieron en un framework para software, formalizado en la Scrum Guide (la versión vigente es la de 2020, 14 páginas en total, gratis en scrumguides.org). Si nunca la has leído entera, te tomará 25 minutos y vas a descubrir que la mitad de lo que tu empresa llama “Scrum” no está ahí.
Lo que la guía sí dice, en una línea cada uno:
| Elemento | Qué dice realmente la guía |
|---|---|
| Sprint | Iteración de máximo un mes (no obligatoriamente dos semanas) |
| Daily Scrum | 15 minutos, para el equipo de desarrollo, no es status report al PM |
| Sprint Planning | Decidir qué se hace y cómo, no votar Fibonacci durante dos horas |
| Sprint Review | Mostrar lo terminado a stakeholders, recibir feedback |
| Retro | Reflexionar y comprometer una mejora concreta para el próximo sprint |
| Definition of Done | Qué significa “terminado” en esta organización |
Lo que la guía no dice:
- No menciona story points. Para nada.
- No menciona Jira ni ninguna herramienta.
- No exige sprints de dos semanas.
- No exige velocity tracking.
- No exige burndown charts.
- No menciona sprint commitment en el sentido contractual.
Todo eso es decoración que se añadió en los 2000s, principalmente por consultoras que necesitaban algo que vender. Si tu Scrum-Master no ha leído la guía oficial, no es tu Scrum-Master, es tu project manager con el título cambiado.
Por qué la mayoría de los Scrums son disfuncionales
Hay un patrón muy específico que se repite en empresas que “implementaron Scrum”:
- Se contrata un Agile coach o se manda gente a una certificación.
- Se imponen las ceremonias completas: daily, planning, review, retro.
- Se compra Jira.
- No se cambia ninguno de los problemas estructurales reales —jerarquía, presión por fechas, falta de calidad técnica, micromanagement disfrazado.
- Tres meses después, el equipo está más cansado y produce lo mismo, pero ahora con tableros bonitos.
A esto Martin Fowler lo bautizó en su keynote en Agile Australia 2018 —titulada “The State of Agile Software in 2018”— con un nombre brutal: “Faux Agile” o, más conocido, “Agile Industrial Complex”. La idea es que la industria de la consultoría ágil creó productos —certificaciones, frameworks como SAFe, herramientas— que tienen muy poca relación con los principios originales y mucha relación con vender más servicios.
Tres síntomas de que estás en Faux Agile:
- La daily se siente como reportar al jefe, no como coordinarte con tu equipo.
- Los sprints terminan con carry-over crónico (más del 30% de tickets que pasan al siguiente sprint).
- Las retros producen los mismos action items cada quince días y nadie los implementa.
Si dijiste sí a los tres, no estás haciendo Agile. Estás haciendo waterfall en pedacitos de dos semanas, lo cual es lo peor de los dos mundos.
Lo que sí funciona, ordenado por ROI
Después de hacer esto durante 10+ años en distintos equipos —startups, consultoría, productos a medida— estos son los patrones que de verdad mueven la aguja, sin ceremonias.
1. WIP limits — límites de trabajo en paralelo
De Kanban, no de Scrum, pero el más útil de todos. La regla: cada persona tiene máximo 1 (a veces 2) tareas activas simultáneas. Si vas a empezar algo nuevo, primero terminas o pausas explícitamente algo.
¿Por qué? Porque cambiar de contexto cuesta caro. Gerald Weinberg, en Quality Software Management, Vol. 1: Systems Thinking (Dorset House, 1992), tabuló de forma muy citada el costo del cambio de contexto: con 2 proyectos en paralelo cada uno recibe ~40% de tu atención (no 50%) por la “pérdida” del cambio; con 3 proyectos cada uno baja a ~20%; con 5 proyectos cada uno se queda con ~5%. Es una estimación, pero la dirección es clara: si tu Jira muestra 7 tickets In Progress asignados a la misma persona, esa persona está produciendo, en el mejor escenario, el equivalente a media persona.
El truco es resaltar visualmente los límites en cada columna. Cuando una columna está llena, el equipo entero ayuda a vaciarla antes de mover algo nuevo. Eso es swarming, y es la práctica más anti-individualista que vas a adoptar — y por mucho la más efectiva.
2. Slicing vertical — rebanar tickets, no estimarlos
La mayoría del tiempo perdido en sprint planning se pierde estimando. Y la mayoría de las estimaciones son malas porque el ticket está mal definido. Si no puedes estimar algo, no es un problema de estimación; es un problema de claridad.
La solución es vertical slicing: cortar cada historia en rebanadas que de extremo a extremo entreguen algo. No “primero el back, luego el front, luego QA”. Sino “feature X, versión mínima, atravesando todas las capas, esta semana”.
Ejemplo concreto, sacado de un proyecto real:
Historia original (mala): “Implementar exportación de reportes a Excel”. Estimada en 13 puntos. Lleva 4 sprints sin entregar.
Historia rebanada (buena):
- “Botón que descarga un Excel con sólo el ID y nombre del cliente, una sola hoja, sin filtros” — 1 día.
- “Añadir 3 columnas más” — 1 día.
- “Permitir filtrar por fecha” — 2 días.
- “Permitir múltiples hojas por sucursal” — 3 días.
Cada rebanada se puede mandar a producción sola. Cada una resuelve un problema real. Y entre la primera y la última, probablemente descubres que las últimas dos no las necesita nadie, lo cual te ahorra una semana.
La idea, parafraseada de Allen Holub (charlas y posts varios sobre no estimates): si puedes rebanarlo lo suficientemente pequeño, no necesitas estimarlo. La estimación existe para gestionar la incertidumbre; rebanar fino es una forma más barata de bajar la incertidumbre.
3. Definition of Done explícita y sin negociación
La Definition of Done (DoD) es lo único de Scrum que prácticamente todos los equipos de alto rendimiento adoptan, incluso los que no se llaman Scrum. Es una lista corta —de 5 a 10 criterios— que toda historia debe cumplir para considerarse terminada.
Una DoD de muestra para un equipo que sabe lo que hace:
- Tests unitarios para el camino feliz y al menos un edge case.
- PR aprobado por al menos un humano que no es el autor.
- Pipeline de CI verde.
- Documentación actualizada (README, API docs, runbook si aplica).
- Probado en staging con datos parecidos a producción.
- Mergeado a main y desplegado.
Lo importante de la DoD no es la lista. Es que no se negocia para “cumplir el sprint”. Si no cumple la DoD, no está hecho. Punto. Si tu PM te empuja a marcar como hecho algo que no cumple la DoD para que se vea bien en el burndown, ese es exactamente el momento donde debes parar y decir no. Esa decisión sostenida en el tiempo es la diferencia entre un equipo que entrega y uno que se ahoga en deuda técnica.
4. Pull > push
Sutil pero importante. En push, alguien (PM, líder, Scrum-Master) asigna tickets a las personas. En pull, el equipo tiene un backlog priorizado y cada persona toma el siguiente ticket cuando termina el actual.
Pull funciona mejor porque:
- La persona que toma el ticket lo entiende; nadie agarra algo que no entiende.
- Si el backlog está bien priorizado, todo lo importante se hace primero.
- Distribuye carga automáticamente — el rápido toma más, el lento se concentra.
- Elimina al middle-manager humano que decide quién hace qué.
¿Cuándo push es necesario? Cuando hay especialización extrema o cuando hay un deadline externo y necesitas a la persona específica. El resto del tiempo, pull.
Las ceremonias, una por una: qué conservar y qué tirar
Daily Stand-up — conservar, pero podarla
La daily debería durar 5–10 minutos, no 25. La regla es simple: si lleva más, no es daily, es status meeting.
Patrón que funciona en equipos chicos:
Cada quien dice una sola cosa: “estoy con [esto]; bloqueado por [esto] o nada”. No qué hiciste ayer (eso está en los commits y en el tablero). No qué vas a hacer hoy (eso lo decides solo). Solo: dónde estás, y dónde estás atorado.
Si llevas más de 7 personas en la daily, la daily ya está muerta. Divide el equipo o cambia a un canal asíncrono (Slack/Discord con un thread diario funciona mejor que muchas dailies).
Sprint Planning — conservar, pero ligera
Una hora máximo. Tres preguntas:
- ¿Qué tickets están listos para tomarse este sprint? (Filtro: Definition of Ready cumplida.)
- ¿Hay algún riesgo o dependencia oculta?
- ¿Necesitamos un spike —investigación de máximo 2 días— para algún ticket que no entendemos?
No estimar en planning. Eso se hace antes, en backlog refinement, y se hace en grupos pequeños (2–3 personas), no en pleno. El planning es para comprometerse con el sprint, no para descubrir el trabajo.
Backlog Refinement — conservar, hacer diario
La práctica más infravalorada. Es la sesión donde 2–3 personas (típicamente un dev, el PM y un líder técnico) toman tickets crudos del backlog y los refinan hasta que cumplen la Definition of Ready —están claros, tienen criterios de aceptación, y son rebanables.
Si lo haces 30 minutos al día, tu sprint planning dura 20 minutos en vez de 2 horas. Garantizado.
Sprint Review — conservar, sólo si hay algo que mostrar
La review existe para mostrar el trabajo a stakeholders externos. Si tu sprint no produjo nada que enseñar, no hagas review — analiza por qué no produjiste, eso es más valioso. Reviews fantasmas donde el equipo “se autoevalúa” no aportan nada.
Para productos internos sin stakeholders externos: skip. Reemplaza con un changelog público en Slack/email.
Retro — conservar, con condición
Una retro sin owner ni deadline en cada action item es una sesión de quejas con minutas bonitas. La regla:
Cada action item de una retro tiene: nombre del responsable, fecha límite y criterio claro de “hecho”. Máximo 2 items por retro. Más de 2, nadie hace ninguno.
Si tu equipo sale de la retro con 8 acciones y nadie asignado, no perdiste tiempo: lo donaste.
Story Point Poker — conservar opcionalmente, no más de 15 minutos
Si tu equipo lo disfruta y se hace rápido, fine. Si lleva 2 horas y produce números que nadie usa para nada útil después, mátalo. Reemplazo: clasificar en tres cubetas — S (un día o menos), M (de 2–4 días), L (necesita rebanarse antes de tomarse). Suficiente para planear.
Burndown Charts — tirar
Es una métrica de vanidad. Te dice cuánto trabajo está pendiente, no si ese trabajo es valioso, ni si está bien hecho, ni si va a llegar a producción. Reemplazo: un cumulative flow diagram (CFD) que muestra cuánto tiempo tarda algo en pasar por cada columna del tablero. Eso sí te dice dónde está el cuello de botella.
Velocity como métrica de desempeño — tirar
Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.” En cuanto velocity se vuelve la métrica que evalúa al equipo, el equipo infla los puntos. Sin excepción. Y si los infla, deja de servir para planear.
Velocity se puede usar internamente, en privado, como referencia histórica para no comprometerse a 80 puntos cuando históricamente has hecho 35. Pero nunca como meta, y nunca pública entre equipos.
La alternativa: Kanban / continuous flow
Para muchos equipos —especialmente los de ops, plataforma, mantenimiento o cualquier producto donde el trabajo llega de forma impredecible—, Scrum es la herramienta equivocada. Lo correcto es Kanban con continuous flow.
La diferencia clave: en Sprint, el ciclo de planeación es fijo (2 semanas). En Flow, el ciclo es continuo — cada vez que algo se termina, se empieza lo siguiente.
¿Cuándo usar cuál?
| Contexto | Mejor opción |
|---|---|
| Producto nuevo con roadmap claro y stakeholders externos | Scrum |
| Equipo de plataforma / SRE / ops | Kanban |
| Mantenimiento de producto maduro | Kanban |
| Startup pre-product-market-fit | Kanban con revisiones cada 2 semanas |
| Empresa grande con múltiples equipos coordinados | Scrum (con cuidado) |
| Consultoría con cliente externo y entregables fijos | Scrum |
| Equipo de 2–3 personas | Ninguno; reuniones cuando hagan falta |
Si tu equipo tiene menos de 4 personas, probablemente no necesitas un framework. Necesitas un canal de Slack, un tablero simple y una llamada cuando algo se atore. Aplicar Scrum a un equipo de tres es como ponerle uniforme corporativo a tu hermano.
La regla de las dos pizzas
Jeff Bezos popularizó esta regla en Amazon: si un equipo no se puede alimentar con dos pizzas, es demasiado grande. La traducción a software: 8 personas o menos por equipo, idealmente 5–7.
Hay management research bien establecido detrás de eso. Brooks’ Law —del libro The Mythical Man-Month de Frederick P. Brooks Jr. (1975, Addison-Wesley)— dice literalmente: “Adding manpower to a late software project makes it later” (añadir gente a un proyecto de software retrasado, lo retrasa más). La razón es que el costo de comunicación crece de forma cuadrática (n × (n-1) / 2 canales posibles). Cuando pasas de 7 a 14 personas, no duplicas la productividad: la divides por la coordinación.
Si tu equipo crece más allá de 8, divide. Si tu empresa tiene un equipo de 20 personas operando como un solo scrum, tu Scrum no es el problema; tu estructura organizacional sí lo es.
Los frameworks que se llaman Agile pero son lo contrario
Hay tres palabras que cuando aparecen en un job description deberían encender un foquito:
SAFe (Scaled Agile Framework). Inventado en 2011 por Dean Leffingwell. Es lo que pasa cuando tomas Scrum, le añades 4 capas de gobernanza, Program Increments de 10 semanas, Release Trains y un cuerpo de documentación tan extenso que requiere certificaciones para entenderlo. Varios firmantes del manifiesto —incluido Ron Jeffries en su post “SAFe — Good but not Good Enough”— han argumentado que SAFe en la práctica recrea las jerarquías y rituales que Agile vino a reemplazar. Si trabajas en una empresa que adoptó SAFe sin masticar críticamente cada pieza, hay buenas probabilidades de que lo que estás haciendo no se parezca al manifiesto.
Agile metrics dashboards. Cualquier sistema que mida velocity entre equipos, calcule “puntos por persona por sprint” o pretenda comparar productividad entre squads. Eso ya no es Agile; es taylorismo con UI.
Scrum certifications a granel. Si tu Scrum-Master sacó su CSM en un curso de fin de semana, no tiene 10 años de experiencia. La certificación no es mala en sí, pero no sustituye haber visto fracasar y aprender. Pregúntale qué hizo cuando el último sprint se cayó por una outage de 3 días. Si te recita el manual, corre.
El playbook pragmático
Si tuviera que reducir todo este post a una receta para un equipo de 4–8 ingenieros que arranca un proyecto nuevo:
| Práctica | Cadencia | Tiempo |
|---|---|---|
| Tablero con WIP limits visibles | Continuo | — |
| Daily de blockers | Diario | 5–10 min |
| Backlog refinement (2–3 personas) | Diario o cada 2 días | 30 min |
| Demo de lo terminado a stakeholders | Cada 1–2 semanas | 30 min |
| Retro con max 2 action items con owner | Cada 2 semanas | 45 min |
| Definition of Done aplicada sin excepción | Continuo | — |
| Pair / mob programming en piezas críticas | Cuando aplique | — |
| Deploy a producción | Diario o cuando esté listo | — |
Si haces eso —solo eso— vas a entregar más, con menos burnout, que el 80% de los equipos que se dicen Agile. No vas a necesitar SAFe, ni un Agile coach, ni Jira con 17 customizaciones. Necesitas disciplina técnica, claridad de prioridades y un equipo que se respete.
La idea que vale guardar
Dave Farley —co-autor de Continuous Delivery (Addison-Wesley, 2010), uno de los libros que de verdad cambió cómo se entrega software— ha defendido en charlas y en su canal de YouTube una idea que podemos resumir así, parafraseándolo:
Agile no es un proceso. Es el reconocimiento de que no sabes todo desde el inicio, y quieres descubrirlo lo más rápido y barato posible.
Eso es. No son las dailies. No es Jira. No es la velocity. Es entregar pedazos chicos de software funcionando, ver qué pasa, y ajustar. Si lo que haces hoy te ayuda a reducir el costo de equivocarte, estás haciendo Agile. Si no, estás haciendo otra cosa con un nombre prestado.
Lecturas que sí valen la pena
- The Agile Manifesto y los 12 principios (agilemanifesto.org + history) — 68 palabras. Léelo entero.
- The Scrum Guide 2020 (scrumguides.org) — 14 páginas. La fuente oficial, gratis, en español también.
- Takeuchi & Nonaka (1986), “The New New Product Development Game” — el paper de HBR que originó la idea de Scrum.
- Frederick P. Brooks Jr. (1975, ed. aniv. 1995), The Mythical Man-Month — Brooks’ Law y por qué los equipos grandes entregan menos.
- Jez Humble & Dave Farley (2010), Continuous Delivery (Addison-Wesley) — el contrapeso técnico al Agile manageril. Acompaña con el canal de YouTube de Farley.
- Martin Fowler (2018), “The State of Agile Software in 2018” — el ensayo donde introduce “Faux Agile” y “Agile Industrial Complex”.
- Andy Hunt (2015), “The Failure of Agile” — el firmante #4 del manifiesto admitiendo lo que pasó.
- Esther Derby & Diana Larsen (2006), Agile Retrospectives: Making Good Teams Great (Pragmatic Bookshelf) — el manual práctico de retros que sí cambian comportamiento.
- Mike Cohn (2004), User Stories Applied (Addison-Wesley) — sigue siendo la mejor referencia para escribir historias bien rebanadas.
- Allen Holub — sus charlas en YouTube y su feed son la mejor fuente continua de crítica al Agile industrializado.
Y si te quedas con una sola idea de todo este post: el manifiesto cabe en 68 palabras y los 12 principios en una página. Cualquier metodología que requiera 700 páginas de manual para “implementar Agile” es exactamente lo que Agile vino a reemplazar.