Ágil y Scrum, ¿cuál es la diferencia? — Fundamentos prácticos para equipos de desarrollo

Introducción

Este artículo organiza la relación entre Ágil y Scrum y resume el conocimiento mínimo necesario para trabajar de forma efectiva en el campo. Está dirigido a quienes están a punto de unirse a un equipo o desean actualizar los conocimientos adquiridos de forma autodidacta.

¿Qué es Ágil?

En una palabra

Ágil (Agile) no es una metodología específica, sino una "forma de pensar" y un "conjunto de valores" para el desarrollo de software. Su punto de partida es el "Manifiesto Ágil" (Agile Manifesto), publicado en 2001 por 17 desarrolladores de software que se reunieron.

Los cuatro valores

El Manifiesto Ágil expresa que se valora más el lado derecho que el izquierdo.

Un punto importante: no se dice que "el lado izquierdo no tiene valor". Ambos lados tienen valor, pero se le da mayor importancia al lado derecho: esa es la postura de Ágil.

12 principios (extracto)

Detrás del manifiesto hay 12 principios. No es necesario memorizar todos, pero aquí están los tres citados con mayor frecuencia:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al período de tiempo más corto posible.

"Entregar software funcional en ciclos cortos" y "Dar la bienvenida al cambio": estos dos puntos pueden considerarse el núcleo de Ágil.

¿Qué es Scrum?

Su relación con Ágil

Aquí es precisamente donde suele haber confusión. En forma de diagrama:

Ágil (mentalidad / valores)
├── Scrum (framework) ← el más extendido
├── XP (Extreme Programming)
├── Kanban
└── Otros...

En otras palabras, Scrum es uno de los frameworks concretos para practicar Ágil. Ágil ≠ Scrum, y la relación correcta es Scrum ⊂ Ágil.

El 3-5-3 de Scrum

Scrum está compuesto por "3 Responsabilidades (Accountabilities), 5 Eventos y 3 Artefactos". En la versión 2020, el término "roles" fue reemplazado por "responsabilidades", y cada artefacto recibió un compromiso (Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done).

Las 3 Responsabilidades

• Product Owner (PO): Responsable de maximizar el valor del producto. Decide las prioridades sobre qué construir.
• Scrum Master (SM): Apoya el correcto funcionamiento de Scrum. Es el coach del equipo y la persona que elimina impedimentos.
• Developers: Las personas que realmente construyen el producto. Ingenieros, diseñadores, QA, etc.

Los 5 Eventos

Los 3 Artefactos

• Product Backlog: Una lista priorizada de todo lo que se quiere hacer. Gestionado por el PO.
• Sprint Backlog: La lista de trabajo para el Sprint actual. Gestionado por los Developers.
• Increment: El producto funcional completado en el Sprint.

El ciclo de Sprint

[Planning] → [Desarrollo + Daily × N días] → [Review] → [Retro] → Siguiente Sprint

Repetir este ciclo en un período fijo es el ritmo fundamental de Scrum.

Profundizando en Scrum con ejemplos concretos

Desde aquí, exploramos en detalle las partes que son difíciles de entender solo con explicaciones abstractas, usando un producto ficticio como ejemplo.

Profundizando en las Responsabilidades

Product Owner (PO) — El día de María

El trabajo del PO suele describirse como "decidir prioridades", pero en la realidad es mucho más desordenado. Este es un día típico de María, la PO del equipo FitLog:

• Mañana: Revisa los datos de uso del último release, identifica las pantallas con alta tasa de abandono. Organiza las solicitudes que llegaron del equipo de Customer Success.
• Tarde: Se reúne con los stakeholders (marketing, dirección) para alinear los objetivos de negocio del Q3 con el Product Goal.
• Entremedias: Responde inmediatamente a preguntas de los developers como "Esta especificación — ¿esta implementación sería más liviana, qué te parece?"
• Semanalmente: Refina el backlog y concreta los criterios de aceptación de los elementos prioritarios.

El punto clave es que el PO carga tanto el "valor para el usuario" como el "valor de negocio". Para tener una base para decidir "¿Feature A o Feature B, cuál primero?", necesita dominar la investigación de usuarios, el análisis de datos y las reuniones de dirección.

Scrum Master (SM) — Ejemplos de intervenciones de Carlos

El SM suele verse como un "facilitador de reuniones", pero su esencia es ser un coach que hace emerger la autonomía del equipo. Lo que Carlos, el SM del equipo FitLog, realmente hace:

• Nota que el Developer A dice cada día en el Daily Scrum "Ayer también estuve investigando este bug", y le contacta en una 1:1: "¿Estás bloqueado? ¿Necesitas ayuda?"
• Observa que hay siempre una discrepancia en la "interpretación de la especificación" entre PO y developers, y lleva este problema a la Retro.
• Detiene las solicitudes directas de otros departamentos ("¡Necesitamos ayuda urgente!") a los developers y refuerza la regla: "Las solicitudes van por el PO."
• Propone revisar el formato de los eventos Scrum cuando el equipo ya está rodado (ej: cambiar el formato del Daily Scrum).

El SM es un rol que parece no hacer nada, pero en realidad está modelando continuamente el entorno del equipo. "El SM parece desocupado últimamente" puede ser una buena señal de que el equipo está empezando a funcionar de forma autónoma.

Developers — ¿Qué significa "auto-gestionado"?

En el Scrum Guide 2020, todo el equipo Scrum se describe como auto-gestionado (self-managing). En los Developers específicamente, la autogestión se manifiesta de estas formas concretas:

• "Qué" hacer en el Sprint se decide en consulta con el PO, pero "cómo" implementarlo lo deciden los Developers.
• Las tareas no son asignadas desde arriba; los Developers las toman ellos mismos.
• Las estimaciones las hacen los Developers (no el PO ni el manager).
• Los Developers son responsables de mantener los estándares de calidad (Definition of Done).

Cuando Diego, developer iOS, nota "Esta API responde lento y perjudica la UX", consulta directamente con Javier, developer Backend, para mejorarlo — este tipo de colaboración horizontal que surge naturalmente es la marca de un equipo Scrum sano.

Profundizando en los Eventos

Sprint Planning — Ejemplo real de cómo se desarrolla

El Sprint Planning de 2 semanas del equipo FitLog se desarrolla así (aproximadamente 4 horas):

Parte 1: ¿Por qué es valioso este Sprint? (Establecer el Sprint Goal)

PO María: "Quiero que nuestro objetivo para este Sprint sea: 'Los usuarios pueden ver el progreso de su entrenamiento de los últimos 30 días mediante un gráfico.' La investigación del mes pasado mostró que los usuarios con mayor retención usan más la función de gráficos."

El Sprint Goal se expresa mejor como un estado a alcanzar, no como una lista de funcionalidades.

Parte 2: ¿Qué se puede lograr en este Sprint? (Selección de elementos del Backlog)

Para los elementos prioritarios presentados por el PO, los developers estiman con Planning Poker y seleccionan una cantidad que se ajusta a su capacidad.

Parte 3: ¿Cómo se completará el trabajo seleccionado? (Desglose de tareas)

Los developers desglosan los elementos de backlog seleccionados en tareas concretas.

Developer Diego: "Desglosando el elemento 'Pantalla de visualización de gráfico', obtenemos 4 tareas: diseño de API, implementación iOS, implementación Android y pruebas E2E. Sin terminar el diseño de API no podemos paralelizar, así que Javier debería concentrarse en eso el primer día."

Daily Scrum — Bueno vs Malo

❌ Daily malo (se convierte en reporte de estado)

"Ayer trabajé en la implementación de la API. Hoy escribiré pruebas. Sin bloqueos."
"Avancé en la implementación de la pantalla. Hoy continúo."
…… (15 minutos monótonos)

Esto es un reporte de estado, no inspección y adaptación.

✅ Daily bueno (inspección y adaptación)

Developer Diego: "La librería de renderizado de gráficos es más pesada de lo esperado. Para alcanzar el Sprint Goal, quiero considerar cambiar a otra librería. Necesito 2 horas de investigación adicional después del Planning."
Developer Javier: "Entonces puedo adelantar mi implementación de API un día y venir a apoyarte."
Developer Diego: "Entonces trabajemos los detalles entre los dos en 30 minutos después de esto."

El verdadero propósito es un espacio para replantear cómo actuar hoy en relación al Sprint Goal.

Sprint Review — Más que solo una demo

Un malentendido frecuente sobre la Review es "demo del producto funcionando y listo". Una Review real es un espacio de diálogo con los stakeholders.

• Los Developers demuestran el Increment funcionando
• Los stakeholders lo prueban y dan feedback
• Se comparte información externa: "Las condiciones del mercado cambiaron", "La reacción de los usuarios objetivo fue diferente a lo esperado"
• En base a esto, el Product Backlog se ajusta para lo que sigue

Por lo tanto, la Review sirve no solo como "inspección del pasado" sino también como "input para la planificación futura".

Sprint Retrospective — Consejos para evitar el ritual vacío

Las Retros suelen verse como "se hace con KPT (Keep/Problem/Try)", pero cualquier formato sirve. Cambiar el formato según la situación del equipo es útil, pero eso es un medio, no un fin.

Variaciones que el equipo FitLog está probando:

Y limitar los Try a uno solo y empezar a trabajar en él al inicio del siguiente Sprint. "Hagamos todo" equivale a no hacer nada.

Profundizando en los Artefactos

Product Backlog — La granularidad correcta de los elementos

Los Product Backlog Items (PBIs) suelen escribirse en formato de User Story:

Como [qué tipo de usuario]
Quiero [hacer qué]
Para que [por qué quiero hacerlo]

Buen ejemplo de PBI para FitLog:

Título: Mostrar gráfico del progreso de entrenamiento de los últimos 30 días

Como usuario que practica jogging regularmente, quiero ver un gráfico de mi distancia recorrida en los últimos 30 días, porque quiero mantener mi motivación visualizando mis esfuerzos.

Criterios de aceptación:

• Se añade una pestaña "Progreso" a la pantalla principal
• La distancia diaria de los últimos 30 días se muestra como gráfico de líneas
• Los días sin datos aparecen en blanco en el gráfico
• Tocar el gráfico navega a la pantalla de detalle de ese día

❌ Mal ejemplo de PBI: "Implementar la función de gráfico" ← No está claro para quién ni con qué propósito

Los PBIs deberían satisfacer idealmente el principio INVEST (Independent / Negotiable / Valuable / Estimable / Small / Testable).

Sprint Backlog — Conexión con el Product Goal

El Sprint Backlog no es una "lista de tareas"; es un plan compuesto de tres elementos:

1. Sprint Goal (por qué): El estado a alcanzar en este Sprint
2. PBIs seleccionados (qué): Elementos elegidos del Product Backlog
3. Plan de ejecución (cómo): Desglose de tareas y enfoque

Sprint Goal: Los usuarios pueden consultar su progreso de entrenamiento de los últimos 30 días mediante un gráfico
├─ PBI 1: Pantalla de visualización del gráfico de progreso [8 pt]
│   ├─ Tarea: Diseño del endpoint API
│   ├─ Tarea: Implementación iOS
│   ├─ Tarea: Implementación Android
│   └─ Tarea: Pruebas E2E
├─ PBI 2: Navegar al detalle al tocar el gráfico [3 pt]
│   └─ ...
└─ PBI 3: Mejora de la visualización con datos vacíos [2 pt]
    └─ ...

Increment — La "Definition of Done (DoD)"

El Increment se describe como "producto funcionando", pero qué cuenta como terminado debe ser claramente definido por el equipo. Esta es la Definition of Done (DoD).

Ejemplo de DoD del equipo FitLog:

• Code review con al menos 2 Approvals
• Cobertura de pruebas unitarias del 80% o más
• Pruebas E2E pasadas
• Verificación de accesibilidad completada (VoiceOver / TalkBack)
• PM ha verificado los criterios de aceptación y ha dado OK
• Borrador de release notes creado

Cualquier cosa que no satisfaga la DoD se considera "incompleta" y se lleva al siguiente Sprint. Entregar 5 funcionalidades al 100% es mejor que acumular 10 funcionalidades al 80%: esa es la mentalidad Scrum.

Velocidad (Velocity) — Medir la "velocidad" del equipo

Si has leído hasta aquí, quizás te preguntas: "¿Qué era ese [8 pt] junto a los PBIs?" Esto lleva al tema de la Velocidad (Velocity), que es importante para operar Scrum en la práctica.

Definición

La velocidad es el tamaño total de los elementos de backlog que un equipo completa por Sprint. Generalmente se define como:

Velocidad = Suma de los Story Points de los PBIs que satisficieron la Definition of Done en ese Sprint

Puntos importantes:

• Solo se cuentan los PBIs completados (80% hecho = 0)
• La unidad son generalmente los Story Points (SP) (no horas)
• Se mide por Sprint; a menudo se observa como una media móvil de varios Sprints

¿Qué son los Story Points?

Los Story Points representan el tamaño relativo del trabajo. En lugar de valores absolutos como "días-persona" u "horas", se estima comparando con una tarea de referencia: "¿Qué tan grande es esto en comparación con esa tarea base?"

La escala comúnmente usada es la sucesión de Fibonacci (1, 2, 3, 5, 8, 13, 21...). Los intervalos crecientes reflejan que "las tareas más grandes tienen más incertidumbre y las distinciones finas no tienen sentido".

Referencia de estimación del equipo FitLog:

Ejemplo: Evolución de la velocidad del equipo FitLog

Veamos los resultados del equipo FitLog en los últimos 6 Sprints:

Sprint 1: 18 pt (PBIs completados: 5 + 5 + 3 + 3 + 2)
Sprint 2: 22 pt (PBIs completados: 8 + 5 + 5 + 2 + 2)
Sprint 3: 25 pt (PBIs completados: 8 + 8 + 5 + 3 + 1)
Sprint 4: 23 pt
Sprint 5: 26 pt
Sprint 6: 24 pt
─────────────────────
Media de los últimos 3 Sprints: 24,3 pt ← velocidad actual

Esto nos dice que el equipo puede manejar aproximadamente 24 puntos por Sprint.

Cómo usar la velocidad

Una vez que la velocidad se estabiliza, se puede usar de las siguientes formas:

1. Entender la capacidad en el Sprint Planning

PO María: "Los PBIs candidatos para el próximo Sprint suman 32 puntos."
Developer Diego: "Con una media reciente de 24 puntos, es realista asumir los primeros 26 puntos (8+8+5+3+2)."

En lugar de "lo resolveremos con esfuerzo", esto permite un acuerdo basado en evidencia.

2. Predecir planes de release

Si todo el Product Backlog es de 180 puntos y la velocidad es de 24 puntos, la estimación es 180 ÷ 24 = aproximadamente 7,5 Sprints para terminar.

Con esto, se puede explicar a los stakeholders de forma fundamentada: "Probablemente podemos lanzar a finales del Q3."

3. Mejora continua de la precisión de estimaciones

Cuando se ven discrepancias como "estimado en 5 puntos, pero el esfuerzo real fue de 10 puntos", se convierte en material para la discusión en la Retro.

Anti-patrones comunes

La velocidad es útil, pero cuando se usa incorrectamente, puede destruir un equipo.

❌ Anti-patrón 1: Convertir la velocidad en un KPI

"Este mes la velocidad tiene que ser más alta que el mes pasado", "Tener menos velocidad que el otro equipo significa que estáis holgazaneando" — esta es la peor forma de usarla.

La velocidad es un valor relativo propio de cada equipo, y compararla entre equipos carece de sentido. Además, presionar al equipo para "aumentar la velocidad" solo hace que inflen las estimaciones — la productividad real no cambia (incluso disminuye).

❌ Anti-patrón 2: Story Points = Tiempo

Comenzar a usar "1 punto = 4 horas" como conversión fija hace que los Story Points pierdan su sentido. Las ventajas de la estimación relativa (expresar incertidumbre, hacer la discusión más eficiente) se pierden, y degrada a una simple estimación de esfuerzo.

❌ Anti-patrón 3: Contar crédito parcial para PBIs incompletos

"Un PBI de 8 puntos está al 70%, así que contamos 5,6 puntos" — esto no debe hacerse. Los PBIs que no satisfacen la Definition of Done cuentan como 0 puntos.

Razón: La velocidad es una métrica para predecir "cuánto podemos completar en el próximo Sprint". Contar trabajo en progreso distorsiona la predicción.

❌ Anti-patrón 4: Confiar en los valores justo después de cambios en el equipo

Cuando los miembros entran o salen, o la pila tecnológica cambia, la velocidad se reinicia. Después de establecer una nueva configuración de equipo, la regla de oro es ejecutar primero 3-4 Sprints antes de recalcular la media.

La opción de no usar la velocidad

En los últimos años, cada vez más equipos "no siguen la velocidad". Las métricas alternativas incluyen:

• Throughput (Rendimiento): Número de PBIs completados (sin puntos, manteniendo la granularidad consistente y contando)
• Cycle Time (Tiempo de ciclo): Tiempo desde que se inicia un PBI hasta que se completa
• Lead Time (Tiempo de entrega): Tiempo desde que se crea un PBI hasta que se completa

Especialmente en combinación con Kanban, o para equipos maduros que desean reducir el costo de las estimaciones, estas métricas pueden ser más efectivas.

Glosario esencial

Scrum/Ágil tiene mucha terminología propia, y conocerla o no afecta significativamente la eficiencia de la comunicación dentro de un equipo. Profundizamos con ejemplos reales.

Planning Poker

Qué hace

El Planning Poker es una técnica donde todo el equipo estima los Story Points de los PBIs. En lugar de que un ingeniero experimentado decida "esto son 5 puntos", todos los miembros revelan sus cartas simultáneamente y llegan a un consenso.

¿Por qué el formato "Póker"?

Para prevenir el "efecto de anclaje", donde la gente se deja arrastrar por la opinión de la persona más vocal o con más experiencia. Si alguien dice primero "esto son 8 puntos, ¿verdad?", a los demás les resulta difícil decir "yo creo que son 3". Todos revelan sus cartas simultáneamente para evitar esto.

Cómo funciona (ejemplo del equipo FitLog)

Las cartas usan la sucesión de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, ?, ☕). "?" significa "no sé" y "☕" significa "necesito un descanso".

Paso 1: Explicar el PBI

PO María: "Siguiente: 'Enviar recordatorios mediante notificación push'. Si un usuario ha configurado una hora y no ha registrado entrenamiento ese día, enviarle una notificación."

Paso 2: Preguntas y respuestas

Developer Diego: "¿Se puede personalizar el mensaje de la notificación?"
PO María: "No, un mensaje fijo está bien."
Developer Javier: "¿Planeamos usar la infraestructura de notificaciones existente del servidor?"
PO María: "Sí, partiendo de la infraestructura existente."

Paso 3: Todos revelan sus cartas simultáneamente

Paso 4: Pedir a los valores extremos que expliquen

Valor más bajo, Javier: "Del lado BE, solo es añadir una llamada a la infraestructura de notificaciones existente, así que 3."
Valor más alto, Sofía: "Del lado Android, necesito implementar 3 cosas: guardar la configuración del usuario, un job periódico y el manejo de notificaciones. La última vez que hice algo similar me costó trabajo, por eso puse 13."

Paso 5: Re-votar después de la discusión

Después de la discusión, todos convergen hacia "8". Acuerdo final en 8 puntos.

Puntos clave

• No apresurarse a votar: Mostrar las cartas solo después de que las P&R hayan alineado los supuestos
• No culpar a quien diverge: La divergencia se debe a diferencias de información; compartirla es el objetivo
• No gastar demasiado tiempo: Apuntar a 5-10 minutos por PBI. Los PBIs sin acuerdo vuelven al Refinement.

Backlog Refinement

Qué hace

El Refinement es la actividad continua de mantenimiento del Product Backlog. Concretamente:

• Dividir PBIs demasiado grandes
• Concretar los criterios de aceptación de los PBIs prioritarios
• Eliminar PBIs obsoletos
• Estimar (a menudo se usa como sesión de Planning Poker)

Cuándo hacerlo

La Guía Scrum no lo define como un evento independiente, pero la mayoría de los equipos dedican 1-2 horas semanales. Muchos equipos lo programan alrededor de la mitad del Sprint.

Definition of Ready

Un concepto a veces discutido en contraste con la DoD en la práctica es la Definition of Ready. La idea es que cuando un PBI alcanza el estado Ready a través del Refinement, puede llevarse al Planning.

Ejemplo de definición de Ready del equipo FitLog:

• Escrita en formato User Story
• Tiene 3 o más criterios de aceptación
• Todos los miembros del equipo comprenden el contenido
• Dividida a 8 puntos o menos
• Si hay dependencias externas, se ha acordado con las partes involucradas

El principio INVEST (Profundización)

Las 6 cualidades que debería satisfacer un buen PBI. Veamos cada una con ejemplos.

Jerarquía de User Stories — Tema, Epic, Story, Tarea

El Product Backlog es una lista unidimensional, pero en la práctica suele pensarse en 4 niveles.

Tema: Mejorar el engagement del usuario
└─ Epic: Mecanismos para promover la continuidad del entrenamiento
   ├─ User Story: Puede ver el progreso de los últimos 30 días en gráfico [8 pt]
   │  ├─ Tarea: Implementación API
   │  ├─ Tarea: Implementación UI iOS
   │  └─ Tarea: Implementación UI Android
   ├─ User Story: Puede recibir notificaciones de recordatorio [8 pt]
   └─ User Story: Mostrar días consecutivos registrados [3 pt]

Los PBIs que aparecen en el Backlog son principalmente Epics y User Stories.

Burndown Chart / Burnup Chart

Burndown Chart

Un gráfico que visualiza el progreso del trabajo restante durante un Sprint. Se observa cómo se mueve el progreso real en relación con la línea ideal (una línea que disminuye de forma uniforme).

pt restantes
24┤●
22┤  ●
20┤    ●─ Línea ideal ────
18┤      ╲╲
16┤        ●(Real, ligeramente rezagado)
14┤          ●
12┤            ╲
 0┤──────────────●
    Día1 Día3 Día5 Día7 Día10

Si la curva real se mantiene constantemente por encima de la línea ideal → señal de que el Sprint Goal está en riesgo. Considerar actuar pronto (reducción de scope, solicitar ayuda).

Burnup Chart

Un gráfico que muestra el trabajo completado y el scope en líneas separadas. Es más fácil ver la situación que un Burndown cuando ocurren cambios en el scope, por lo que a menudo se usa para el seguimiento de planes de release.

MVP y MMP

MVP (Minimum Viable Product)

El producto mínimo necesario para validar una hipótesis. Un concepto popularizado por "The Lean Startup" de Eric Ries.

Ejemplo de MVP de FitLog: "Los usuarios abren la app, registran manualmente su distancia recorrida y pueden ver una lista de registros anteriores." Sin gráficos, notificaciones ni funciones sociales. Con esto se valida la hipótesis "¿La gente pagará por una app de seguimiento de entrenamiento?"

MMP (Minimum Marketable Product)

El producto mínimo que se puede vender en el mercado. Un paso más rico que el MVP. El MVP es para usuarios internos/limitados; el MMP es para el público general.

Timebox

Los eventos Scrum tienen límites de tiempo máximos. Esto es el timebox.

Efectos del timebox:

• Evita que las discusiones se dispersen: El tiempo limitado obliga a centrarse en lo esencial
• Evita que las reuniones se hinchen: Permitir extensiones lleva a un crecimiento infinito
• Terminar antes está bien: Si se logra el objetivo, puede ser más corto

Spike

Trabajo en timebox para investigar tecnología o resolver incertidumbre. Un término que viene de XP pero ampliamente utilizado en Scrum.

Cuándo usarlo:

• "No está claro si esto se puede lograr con la nueva biblioteca" → Validar en un timebox de 1 día
• "No se puede estimar el costo de refactoring de esta parte del código existente" → Investigar medio día
• "No está claro si la velocidad de respuesta de la API cumple los requisitos" → Crear un prototipo

El entregable de un spike es conocimiento, no código. El código escrito para la validación básicamente se descarta.

Límite WIP (Work In Progress Limit)

Una regla que limita el número de elementos en los que se trabaja simultáneamente. Proviene del Kanban pero cada vez más adoptada en equipos Scrum.

Ejemplo: "Máximo 3 elementos simultáneamente en la columna 'En Progreso'"

Efectos:

• Foco en la finalización: Terminar 3 elementos completamente aporta más valor que avanzar 5 a medias
• Los cuellos de botella se vuelven visibles: Donde se atasca se hace claro
• Reduce los costos del multitarea: El cambio de contexto reduce significativamente la productividad

Deuda Técnica (Technical Debt)

Un concepto acuñado por Ward Cunningham que usa la deuda como metáfora para el estado en que tendrás que pagar intereses (costos adicionales) más tarde porque tomaste un atajo a costa de la mantenibilidad futura.

Tipos:

• Deuda intencional: Implementado rápidamente sabiendo "primero el plazo, refactorizar después"
• Deuda no intencional: Surgida por falta de conocimiento o errores de diseño
• Deuda ambiental: Surgida relativamente a medida que las tecnologías circundantes envejecen (legacy)

Otros términos útiles a conocer

Malentendidos comunes y trampas

"No escribir documentación" es un error

Interpretando mal el "software funcionando sobre documentación exhaustiva" del Manifiesto Ágil, algunos equipos avanzan con cero documentación. La interpretación correcta es escribir la documentación necesaria para la operación.

"No planificar" también es un error

Abandonar la planificación escudándose en "respuesta al cambio" también es incorrecto. Scrum tiene planificación en múltiples niveles (Product Goal, Sprint Goal, plan diario). Ágil no significa no planificar, sino planificar de forma adaptativa.

El Daily Scrum se convierte en un reporte de estado

Un Daily Scrum convertido en reunión de reporte de progreso para el PM o la dirección ha perdido su propósito original. El Daily es un espacio de inspección y adaptación por los Developers, para los Developers.

La duración del Sprint cambia frecuentemente

Cambiar a "esta vez estamos ocupados, así que 3 semanas" o "probemos 1 semana" hace imposible medir la velocidad (velocidad del equipo). La duración del Sprint debería ser fija.

Casos donde Ágil/Scrum no encaja

No es una solución universal. En situaciones como las siguientes, otro enfoque puede ser más apropiado:

• Los requisitos están completamente fijos y los cambios apenas ocurren (ej: cumplimiento normativo)
• Áreas donde la seguridad es extremadamente crítica y las releases incrementales no están permitidas
• Cuando el equipo es extremadamente grande y los costos de coordinación superan los beneficios

Sin embargo, dado que existen métodos de escalado para Scrum a gran escala (LeSS, SAFe, etc.), es prematuro concluir inmediatamente "demasiado grande para esto."

Resumen

• Ágil es una mentalidad y conjunto de valores. El núcleo es "entregar software funcionando en ciclos cortos" y "dar la bienvenida al cambio".
• Scrum es un framework representativo para practicar Ágil.
• Scrum consta de "3 Responsabilidades, 5 Eventos y 3 Artefactos" y repite Sprints de duración fija.
• Copiar solo la forma lleva al ritual vacío. Entender los valores viene primero, el framework viene después.

El objetivo no es "hacer Scrum" sino "entregar continuamente productos valiosos". Pensar en el framework como una herramienta para ese propósito es, creo, la clave para una relación duradera con él.

Referencias

• Manifiesto por el Desarrollo Ágil de Software
• Guía Scrum 2020
• Jeff Sutherland, "Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo"