Scrum apesta

Artículo original ↗ Discusión en Hacker News ↗

Scrum y el “Agile” con A mayúscula son ampliamente criticados aquí como marcos inflados y ritualizados que generan reuniones excesivas, métricas de culto cargo e incentivos distorsionados, mientras hacen poco para mejorar la entrega real de software. Muchos ingenieros informan que Scrum funciona mal para trabajos reactivos o de operaciones, organizaciones grandes y entornos con varios equipos, y argumentan que los problemas atribuidos a una “mala implementación” en realidad son estructurales. Alternativas como Kanban, la planificación incremental ligera, retrospectivas sólidas y procesos definidos por el equipo se ven como más eficaces cuando se combinan con liderazgo competente, confianza genuina y un enfoque en los resultados en lugar del teatro de procesos.

Scrum en teoría vs. realidad

  • Muchos comentaristas distinguen entre el Scrum “de libro” y lo que las empresas realmente hacen.
  • Opinión común: el marco es ligero sobre el papel, pero se convierte en una burocracia rígida y jerárquica, con certificaciones, jerga y herramientas (especialmente JIRA, SAFe).
  • Algunos sostienen que esta inversión viola el “individuos e interacciones sobre procesos y herramientas” del Manifiesto Ágil.

Sobrecarga de reuniones y pérdida de productividad

  • Hay informes repetidos de ingenieros con solo 3–4 horas/día (o menos) para trabajo real debido a ceremonias y reuniones de estado.
  • Los sprints, standups, grooming, la planificación PI y las reuniones de “todos” a menudo se acumulan, especialmente cuando las personas están en varios equipos.
  • Los intentos de limitar el tiempo de reuniones pueden simplemente mover las mismas discusiones a reuniones “fantasma” o al chat.

Story points, estimación y velocidad

  • Hay una frustración intensa con los story points: inflación, politización y su confusión con el tiempo, a pesar del mantra de que “puntos ≠ tiempo”.
  • Los equipos a menudo inflan estimaciones o hacen trampa con los gráficos de burndown para verse bien, distorsionando la planificación.
  • Algunos ven valor en los puntos para la planificación dentro del equipo; otros abogan por #noestimates o por simples recuentos de tareas/tallas de camiseta.

Dónde Scrum funciona vs. falla

  • Funciona mejor para: pequeños equipos de producto enfocados, consultoras que venden sprints o equipos con muchos perfiles junior que necesitan estructura.
  • A menudo falla para: Operaciones/DevOps, trabajo reactivo/de guardia, infraestructura, soporte, hardware y grandes organizaciones con cambios constantes de prioridades.
  • Los sprints se convierten de facto en plazos y fomentan dividir trabajo atómico en tickets artificiales y funciones a medio terminar detrás de flags.

Alternativas y adaptaciones

  • Muchos prefieren Kanban para operaciones y trabajo continuo de producto: flujo continuo, límites de WIP y menos ceremonias.
  • Otros mencionan XP, desarrollo incremental ad hoc o Shape Up de 37signals como algo más cercano al espíritu de Agile.
  • Varios equipos usan efectivamente un híbrido: planificación mínima, incrementos cortos, pocas reuniones, entrega continua.

Cultura, gestión y retrospectivas

  • Tema fuerte: una mala cultura y un liderazgo débil harán dolorosa cualquier metodología; Scrum solo hace visible la disfunción.
  • Críticas al “agile de culto cargo” y a managers inexpertos que instrumentalizan el proceso y las métricas mientras evitan la responsabilidad real.
  • Las retrospectivas son vistas por algunos como la práctica más valiosa de Scrum; donde los equipos pueden cambiar honestamente el proceso, Scrum tiende a funcionar mejor.