«¿Ustedes son ágiles o trabajan con PMBOK?» La pregunta se hace como si fueran dos equipos de fútbol, y no lo son. El PMBOK describe qué tiene que pasar en cualquier proyecto para que llegue a buen término. Lo ágil describe una forma de hacerlo pasar cuando el problema no se deja planear completo desde el primer día.
Este módulo aborda el lado del seminario que más se malentiende. Primero, qué es el agilismo de verdad: un manifiesto de cuatro valores y doce principios, no una herramienta. Después, cómo encaja con los cinco grupos de procesos del módulo 3. Y luego Scrum a fondo, con un ejemplo de principio a fin, más Kanban, XP y Lean para saber cuándo conviene cada uno.
De dónde sale
En febrero de 2001, diecisiete personas que venían desarrollando software con métodos livianos se reunieron en Snowbird, Utah, y firmaron un texto corto: el Manifiesto por el Desarrollo Ágil de Software. No inventaron nada ese fin de semana. Scrum ya existía, XP también, y la idea de equipos pequeños que trabajan como una unidad venía de un artículo de 1986 en la Harvard Business Review, «The New New Product Development Game», de Hirotaka Takeuchi e Ikujiro Nonaka, que comparaba los mejores equipos de desarrollo de producto con un equipo de rugby que avanza junto pasándose el balón.
Lo que hizo el manifiesto fue ponerle nombre común a todo eso y decir qué tenían en común.
Los cuatro valores
El manifiesto dice que, valorando lo de la derecha, se valora más lo de la izquierda:
| Se valora más | que |
|---|---|
| Individuos e interacciones | procesos y herramientas |
| Software funcionando | documentación extensiva |
| Colaboración con el cliente | negociación contractual |
| Respuesta ante el cambio | seguir un plan |
La frase que casi todo el mundo se salta es la última del manifiesto: «aunque valoramos los elementos de la derecha, valoramos más los de la izquierda». Lo ágil no dice que no haya plan, ni contrato, ni documentación. Dice qué gana cuando hay que escoger. Un equipo que usa el manifiesto para no documentar nada no es ágil; está leyendo la mitad del texto.
Fuera del software, «software funcionando» se lee como un resultado que alguien ya puede usar: un servicio que ya atiende, un proceso que ya corre, un informe que ya decide algo.
Los doce principios, agrupados
Los doce principios se entienden mejor en cuatro grupos que en lista:
Valor temprano y continuo.
- La prioridad es satisfacer al cliente con entregas tempranas y continuas de valor.
- Se acepta que los requisitos cambien, incluso tarde, y se usa ese cambio a favor del cliente.
- Se entrega con frecuencia, entre dos semanas y dos meses, prefiriendo el plazo más corto.
- Lo que funciona es la medida principal del avance.
Personas y colaboración. 5. Negocio y equipo trabajan juntos todos los días durante el proyecto. 6. Los proyectos se construyen con personas motivadas, a las que se da entorno, apoyo y confianza. 7. La conversación cara a cara es la forma más eficiente de transmitir información. 8. Las mejores soluciones salen de equipos que se organizan solos.
Ritmo y calidad. 9. El ritmo tiene que ser sostenible indefinidamente para todos. 10. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 11. La simplicidad —maximizar el trabajo que no se hace— es esencial.
Mejora. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo y ajusta su forma de trabajar.
El principio 11 es el más útil fuera del software y el menos aplicado: la pregunta ágil por excelencia no es «cómo hacemos esto más rápido» sino «qué de esto no hace falta hacer».
Del manifiesto a la práctica: tres capas
Mucha confusión viene de mezclar tres cosas distintas bajo la palabra «ágil»:
- La mentalidad son los valores y principios. No se instala; se practica o no.
- Los marcos de trabajo son reglas mínimas para vivir esa mentalidad: Scrum, Kanban, XP, Lean. Cada uno resuelve un problema distinto.
- Las prácticas son herramientas sueltas: un tablero, una historia de usuario, una retrospectiva. Se pueden usar sin marco y sin mentalidad.
El error más caro es comprar la tercera capa creyendo que se compró la primera: poner un tablero en la pared y llamar «sprint» a la reunión del lunes no cambia cómo se toman las decisiones.
Cómo conecta con el PMBOK
Aquí está la parte que más se discute, y la respuesta corta es: los grupos de procesos no desaparecen en un proyecto ágil. Se repiten, en miniatura, dentro de cada Sprint.
En un proyecto predictivo se recorren una vez y en orden: se inicia, se planea casi todo, se ejecuta, se controla contra la línea base y se cierra. En un proyecto ágil se inicia y se cierra una vez, pero la planeación, la ejecución y el monitoreo se vuelven un ciclo corto que se repite cada dos o cuatro semanas, y en cada vuelta se planea solo lo que ya se sabe.
La correspondencia, grupo por grupo, queda así:
| Grupo de procesos | En un proyecto predictivo | En Scrum |
|---|---|---|
| Inicio | Acta de constitución, interesados | Visión del producto, Objetivo del Producto, quién es el Product Owner |
| Planeación | Plan completo: alcance, EDT, cronograma, costos | Product Backlog ordenado y Sprint Planning al inicio de cada Sprint: planeación progresiva |
| Ejecución | Trabajo según el plan | El trabajo del Sprint, hecho por los Developers |
| Monitoreo y control | Desviaciones contra la línea base, control de cambios | Daily Scrum, Sprint Review y gráfica de trabajo restante; el cambio entra por el backlog, no por un comité |
| Cierre | Aceptación formal, lecciones aprendidas | Cada Incremento cumple la Definición de Terminado; la Sprint Retrospective es una lección aprendida cada dos semanas |
Qué dice el PMI hoy
El estándar también se movió en esa dirección. La sexta edición del PMBOK (2017) era una guía de procesos organizados en grupos y áreas de conocimiento; con ella está construido este seminario. La séptima (2021) pasó a principios y dominios de desempeño, y el detalle de los enfoques ágiles quedó en la Guía de Prácticas Ágiles, que el PMI hizo con la Agile Alliance.
La octava edición, publicada en noviembre de 2025, vuelve a traer procesos, presentados de forma no prescriptiva. Los organiza en cinco áreas de enfoque que corresponden a los mismos grupos de siempre —inicio, planeación, ejecución, monitoreo y control, y cierre— y los presenta como aplicables a enfoques predictivos, adaptativos e híbridos. Es decir, el propio estándar dejó de tratar «PMBOK» y «ágil» como opciones excluyentes.
PMBOK es una marca registrada del Project Management Institute, Inc. Este material es educativo y no está patrocinado ni avalado por el PMI.
Scrum a fondo
La Guía de Scrum, escrita por Ken Schwaber y Jeff Sutherland y actualizada por última vez en noviembre de 2020, lo define en una frase: «Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos». La guía oficial tiene menos de veinte páginas, y eso es parte del punto: Scrum es deliberadamente incompleto. Dice qué tiene que existir, no cómo hacer cada cosa.
Se apoya en tres pilares —transparencia, inspección y adaptación— y cinco valores: compromiso, foco, franqueza, respeto y coraje. Todo lo demás —roles, eventos y artefactos— existe para que esos tres pilares ocurran en la práctica.
Las tres responsabilidades
La guía de 2020 dejó de hablar de «roles» y habla de responsabilidades. Son tres, y juntas forman un Scrum Team que normalmente tiene diez personas o menos, sin jerarquías ni subequipos dentro:
- Product Owner. Responde por maximizar el valor del producto. Es dueño del Product Backlog: escribe el Objetivo del Producto, ordena qué va primero y lo mantiene visible. Es una persona, no un comité. Si cada gerente puede reordenar el backlog, no hay Product Owner.
- Scrum Master. Responde por que Scrum funcione como está definido: entrena al equipo, quita impedimentos y ayuda a la organización a entender el marco. No es el jefe del equipo ni el secretario de la reunión diaria.
- Developers. Las personas que construyen el incremento, sean programadoras, analistas, diseñadoras o abogadas. Arman el plan del Sprint, cumplen la Definición de Terminado y se ajustan entre ellas cada día.
En lenguaje del PMBOK, el Product Owner absorbe buena parte de lo que hacía el gerente de proyecto frente al alcance y los interesados, y el Scrum Master buena parte de lo que hacía frente al equipo. Por eso en Scrum no hay un «gerente de proyecto» como tal, aunque en organizaciones grandes suele seguir existiendo uno por encima, coordinando varios equipos.
Los cinco eventos
| Evento | Para qué | Duración máxima (Sprint de un mes) |
|---|---|---|
| Sprint | Contenedor de todo lo demás; produce al menos un incremento | Un mes o menos, siempre la misma |
| Sprint Planning | Por qué vale la pena el Sprint, qué se hará y cómo | 8 horas |
| Daily Scrum | Revisar el avance hacia el Objetivo del Sprint y ajustar el plan | 15 minutos |
| Sprint Review | Mostrar lo logrado a los interesados y decidir qué sigue | 4 horas |
| Sprint Retrospective | Revisar cómo se trabajó y escoger qué mejorar | 3 horas |
Dos detalles que separan el Scrum real del de fachada:
- El Daily Scrum no es un informe de estado para el jefe. Es de los Developers y para los Developers: quince minutos para ajustar el plan del día. Si alguien está tomando apuntes para reportar hacia arriba, ya no es un Daily Scrum.
- La Sprint Review no es una presentación. Es una sesión de trabajo con los interesados donde se ve el incremento funcionando y se decide qué cambia en el backlog.
Los tres artefactos y sus compromisos
Cada artefacto trae un compromiso que le da sentido:
- Product Backlog → Objetivo del Producto. La lista ordenada de todo lo que podría necesitar el producto, y el estado futuro al que apunta.
- Sprint Backlog → Objetivo del Sprint. Lo que se escogió para este Sprint, el plan para lograrlo y un solo objetivo que le da coherencia.
- Incremento → Definición de Terminado. Cada paso concreto hacia el Objetivo del Producto. Solo cuenta como incremento lo que cumple la Definición de Terminado; lo que está «casi listo» vuelve al Product Backlog.
El refinamiento del Product Backlog no es un evento, es una actividad continua: partir los elementos grandes en pequeños y precisarlos hasta que se puedan hacer dentro de un Sprint.
Un ejemplo completo
Para que se vea cómo encaja todo, un caso ficticio. Una cadena de panaderías con doce puntos de venta quiere que sus clientes empresariales —oficinas, colegios, hoteles— puedan hacer pedidos sin llamar por teléfono.
Inicio. El gerente comercial queda como Product Owner. El Objetivo del Producto: «Que un cliente empresarial pueda hacer, pagar y seguir su pedido sin llamar». Se arma un equipo de seis personas: dos desarrolladores, una diseñadora, una persona de operaciones de la planta, una de cartera y un Scrum Master. Sprints de dos semanas.
El Product Backlog inicial, ordenado por el Product Owner, en forma de historias de usuario:
| # | Historia | Tamaño |
|---|---|---|
| 1 | Como cliente empresarial, quiero ver el catálogo con precios de mi convenio, para pedir sin preguntar | 5 |
| 2 | Como cliente, quiero armar y enviar un pedido para el día siguiente, para no llamar | 8 |
| 3 | Como planta, quiero recibir los pedidos consolidados a las 6 p. m., para programar la producción | 5 |
| 4 | Como cliente, quiero pagar con transferencia o PSE, para no esperar la factura | 8 |
| 5 | Como cliente, quiero ver el estado de mi pedido, para saber cuándo llega | 3 |
| 6 | Como cartera, quiero bloquear pedidos de clientes con mora, para no ampliar la deuda | 5 |
| 7 | Como cliente, quiero repetir un pedido anterior con un clic | 3 |
El tamaño es relativo, no en horas: un 8 cuesta claramente más que un 5, y un 5 más que un 3. Sirve para ordenar y para saber cuánto cabe en un Sprint, no para controlar personas.
Sprint 1. En el Sprint Planning, el equipo y el Product Owner fijan el Objetivo del Sprint: «Un cliente piloto puede hacer un pedido real para el día siguiente». Para eso escogen las historias 1, 2 y 3 (18 puntos). La Definición de Terminado que acuerdan: probado con datos reales, revisado por operaciones y desplegado en el ambiente del piloto.
Durante el Sprint, el Daily Scrum detecta el día 4 que la planta no puede recibir un archivo: necesita el pedido impreso por ruta de reparto. Nadie escala nada a un comité: el equipo ajusta la historia 3 dentro del mismo Sprint, porque el Objetivo del Sprint no cambia.
Sprint Review. El cliente piloto hace un pedido real delante del equipo. Comentario inmediato: «necesito que el pedido lo apruebe mi jefe antes de enviarlo». Eso no estaba en el backlog. El Product Owner lo agrega como historia nueva y la pone por encima del pago, porque sin aprobación ninguna empresa grande va a usar la herramienta. Esa decisión es el agilismo en una línea: el plan cambió porque apareció información que no existía antes de mostrar algo funcionando.
Sprint Retrospective. El equipo nota que operaciones se enteró tarde del formato de la planta. Acuerdo concreto: la persona de la planta revisa cada historia que la toca antes de que entre al Sprint.
Qué habría pasado en predictivo. El equipo habría levantado requisitos un mes, construido tres meses y mostrado todo al final. La aprobación del jefe habría aparecido en la prueba de aceptación, como un cambio de alcance con costo y fecha. No porque el plan fuera malo, sino porque esa información no existía hasta que alguien usó el sistema.
Los otros marcos, y cuándo usar cada uno
| Marco | Qué resuelve y a qué ritmo | Úsalo cuando |
|---|---|---|
| Scrum | Construir un producto complejo con aprendizaje frecuente, en Sprints fijos de un mes o menos | Hay un producto, un dueño claro y requisitos que se van a descubrir |
| Kanban | Hacer fluir un trabajo que llega continuamente, sin iteraciones | El trabajo llega sin aviso: soporte, mantenimiento, solicitudes internas |
| XP | Calidad técnica del software bajo cambio constante, en iteraciones cortas | El riesgo está en el código: pruebas, integración, diseño |
| Lean | Eliminar desperdicio y acortar el tiempo de entrega en todo el flujo de valor | El problema es la espera, no la ejecución |
Kanban
La Guía de Kanban (versión de mayo de 2025) lo define como una estrategia para optimizar el flujo de valor a través de un proceso. Tiene tres prácticas: definir y visualizar el flujo de trabajo, gestionar activamente los elementos en el flujo, y mejorarlo. Y cuatro medidas mínimas: trabajo en curso, rendimiento (cuántos elementos se terminan por unidad de tiempo), edad del elemento (cuánto lleva abierto) y tiempo de ciclo (cuánto tardó de principio a fin).
La regla central es limitar el trabajo en curso: no se empieza algo nuevo hasta que hay capacidad libre. Suena obvio y es lo más difícil de sostener, porque todo el mundo quiere que «su» solicitud arranque ya.
Scrum o Kanban no es una pelea. Muchos equipos usan Scrum para el producto y Kanban para el soporte del mismo producto, y algunos meten un tablero con límites dentro del Sprint.
XP (Extreme Programming)
Propuesto por Kent Beck a finales de los noventa. Donde Scrum dice poco sobre cómo construir, XP es muy concreto: pruebas automáticas escritas antes del código, integración continua, programación en pareja, entregas pequeñas y diseño simple. Es el marco de la excelencia técnica del principio 10 del manifiesto. Muchos equipos Scrum de software toman sus prácticas de XP.
Lean
Viene del sistema de producción de Toyota y se trasladó al software y a los servicios. Su pregunta es dónde se pierde el tiempo entre que alguien pide algo y lo recibe: esperas, aprobaciones, reprocesos, trabajo que nadie pidió. Es la base de Kanban, y también la conexión natural con Lean Six Sigma, que trataremos en su propio módulo.
¿Y cuando son muchos equipos?
Cuando un producto necesita varios equipos Scrum coordinados aparecen los marcos de escalamiento: SAFe, LeSS, Disciplined Agile y otros. Son útiles en organizaciones grandes, pero conviene un aviso: escalar un marco no arregla equipos que todavía no funcionan solos. Primero un equipo que entregue cada Sprint; después la coordinación entre varios.
Dónde lo ágil no es la respuesta
Lo ágil sirve cuando el problema es descubrir qué construir. No sirve igual cuando:
- El alcance lo fija una norma o un tercero. Una obra con licencia, un cambio regulatorio con fecha y texto definidos, un contrato de precio fijo con entregables cerrados. Ahí se puede trabajar por incrementos, pero el alcance no se negocia Sprint a Sprint.
- El cambio es carísimo una vez hecho. Fundir una estructura, imprimir un tiraje o desplegar en un equipo que no se puede actualizar. El costo de equivocarse justifica planear más antes.
- No hay quién decida. Sin un Product Owner con autoridad real, el backlog se vuelve la lista de deseos de todos y los Sprints, una cola de pedidos.
- Nadie puede dedicarle tiempo al equipo. Un equipo ágil necesita estar dedicado. Gente repartida en cinco proyectos no hace Sprints; hace interrupciones.
Por eso el módulo 2 termina donde termina: en los proyectos serios la respuesta casi siempre es híbrida. El frente regulatorio se planea completo; el frente que el usuario tiene que descubrir se trabaja en Sprints.
Los errores que convierten Scrum en fachada
- Daily Scrum como informe de estado. Si el equipo le habla al jefe y no entre sí, es una reunión de seguimiento con otro nombre.
- Product Owner sin autoridad. Si cada prioridad tiene que pasar por un comité, el Product Owner es un mensajero.
- Sprints sin incremento. Si al final de un Sprint no hay nada que se pueda usar o mostrar, hubo dos semanas de trabajo, no un Sprint.
- Velocidad como meta. Los puntos sirven para que el equipo planee. Usarlos para comparar equipos o premiar personas hace que los puntos se inflen y dejen de servir.
- Saltarse la retrospectiva cuando hay afán. Es exactamente cuando más falta hace.
- Cambiar el Objetivo del Sprint a mitad de camino. El alcance del Sprint se puede ajustar; si el objetivo deja de tener sentido, lo que corresponde es cancelar el Sprint, no cambiarle la meta en silencio.
El reto del módulo
Toma un proyecto real —tuyo o de tu empresa— y escribe:
- El Objetivo del Producto en una frase.
- Las primeras diez historias de usuario, ordenadas.
- El Objetivo del primer Sprint y qué historias entran.
- La Definición de Terminado.
Si no puedes escribir el Objetivo del Producto en una frase, ese es el hallazgo: el problema no es el método, es que todavía no está claro qué se quiere lograr.
Dónde sigue
Este módulo cierra la parte de ciclos de vida y métodos del seminario. Los anteriores:
- Cómo nacen los proyectos — módulo 1: de la idea al caso de negocio aprobado.
- Cómo elegir el ciclo de vida de un proyecto — módulo 2: predictivo, iterativo, incremental, ágil e híbrido.
- Los cinco grupos de procesos y dónde entra la IA — módulo 3.
Y si quieres ver cómo se conecta Scrum con la estrategia, en OKR y KPI: uno lidera, el otro reporta está la capa de arriba: el OKR define el impacto del trimestre y Scrum lo ejecuta en Sprints.
Una nota sobre cómo se escribió esto
La estructura y los ejemplos salen de veinte años de experiencia profesional, más de quince en el sector financiero, y del seminario de Project Management. La redacción se trabajó con una herramienta de IA. Las definiciones, duraciones y reglas de Scrum se verificaron contra la Guía de Scrum de 2020; las de Kanban, contra la versión de mayo de 2025 de su guía; y la descripción de las ediciones del PMBOK, contra la página del PMI. El caso de la cadena de panaderías es ficticio, igual que los tableros y la gráfica de trabajo restante.
Fuentes
- Manifiesto por el Desarrollo Ágil de Software — Beck, K. y otros (2001)
- Principios del Manifiesto Ágil
- La Guía de Scrum, noviembre de 2020 (español latinoamericano) — Ken Schwaber y Jeff Sutherland, licencia CC BY-SA 4.0
- La Guía de Kanban, versión de mayo de 2025 — Orderly Disruption Limited y Daniel S. Vacanti, Inc.
- Guía del PMBOK, 8.ª edición (noviembre de 2025) — Project Management Institute
- Guía de Prácticas Ágiles — Project Management Institute y Agile Alliance
- Guía del PMBOK, 6.ª edición (2017) — Project Management Institute
- «The New New Product Development Game» — Hirotaka Takeuchi e Ikujiro Nonaka, Harvard Business Review, enero de 1986
- Extreme Programming Explained: Embrace Change — Kent Beck, Addison-Wesley (1999)
La serie en YouTube
Este tema tiene su lista de reproducción en el canal: los videos en orden, para verlos completos o retomarlos donde ibas.