Simyl
simylflow
Inicio del curso
Módulo 1: Por Qué Importa el Proceso
Lección 3 de 3
10 min

La Metodología Es la Capa Superior

Por qué este curso no elige Scrum o Kanban — todavía.

1La Pila

Las prácticas de entrega de software forman una pila con tres capas, y la mayoría de los equipos intentan adoptarlas en el orden equivocado.

Capa 1: Fundamentos. Control de código fuente, rastreo de trabajo, comunicación de intención, hábitos de estimación y trazabilidad. Estas son las prácticas que este curso cubre. Son agnósticas de metodología — un equipo Scrum y un equipo Kanban ambos las necesitan, y se ven casi idénticas en ambos contextos.

Capa 2: Metodología. Scrum, Kanban, XP o un híbrido. Aquí es donde eliges una cadencia (sprints o flujo continuo), defines roles (o explícitamente eliges no hacerlo) y adoptas ceremonias (standups, retrospectivas, sesiones de planificación). La metodología le da a un equipo ritmo y estructura — pero asume que los fundamentos ya están en su lugar.

Capa 3: Escalamiento. SAFe, LeSS, Lean Portfolio Management o patrones de coordinación hechos en casa. Esta capa solo importa cuando múltiples equipos necesitan coordinar la entrega. Asume que tanto los fundamentos como la metodología están funcionando a nivel de equipo.

La pila importa porque cada capa depende de la que está debajo. Un equipo ejecutando Scrum sin un rastreo de trabajo sólido pasará la mitad de cada reunión de planificación de sprint redescubriendo qué está en curso. Una organización adoptando SAFe sin retrospectivas funcionales a nivel de equipo escalará la disfunción, no la entrega.

La mayoría de las "transformaciones ágiles" fallan porque comienzan en la Capa 2 o la Capa 3. Compran una herramienta, contratan un coach, renombran reuniones — y luego se preguntan por qué la velocidad no mejora. La respuesta es casi siempre la misma: los fundamentos no estaban ahí.

2Por Qué la Metodología Viene Después

Cada metodología asume que ya tienes lo básico. Scrum asume que puedes rastrear trabajo en un backlog, hacer commit de código a un repositorio compartido y estimar esfuerzo con suficiente consistencia para planificar un sprint. Kanban asume que puedes visualizar elementos de trabajo, medir el tiempo de ciclo y rastrear un ticket desde la solicitud hasta la entrega. XP asume que puedes escribir pruebas, revisar código y desplegar frecuentemente.

Ninguna de estas suposiciones se declara en las guías de metodología, porque los autores las consideraron obvias. Pero para muchos equipos, no son obvias — son aspiracionales. Y cuando un equipo adopta una metodología sin los fundamentos, la metodología se convierte en teatro: las ceremonias suceden, los artefactos existen, pero los resultados no cambian.

Has visto esto. El equipo que ejecuta planificación de sprint pero no puede responder "¿a qué nos comprometimos el sprint pasado?" porque los tickets no se actualizaron. El equipo que hace standups diarios pero no puede compartir progreso porque la mitad del trabajo no está rastreado. El equipo que realiza retrospectivas pero no puede actuar sobre los insights porque no hay sistema para asignar y dar seguimiento a elementos de acción.

La solución no es abandonar la metodología. La solución es hacer bien los fundamentos primero, luego agregar la metodología encima. Ese es el orden que este curso sigue: Los Módulos 2–4 cubren los fundamentos (control de código fuente, tickets, estimación), y el Módulo 5 te ayuda a elegir qué metodología — si alguna — adoptar una vez que la base es sólida.

Conclusiones clave
  • Este curso enseña la capa debajo de Scrum/Kanban/XP
  • Adoptar una metodología antes de lo básico es "teatro ágil"
  • El Módulo 5 te ayudará a elegir una metodología una vez que hayas internalizado lo básico

Ejercicios prácticos