Scrum
Un marco ágil que organiza el trabajo en sprints de duración fija, con roles, eventos y artefactos definidos para mantener a un equipo entregando e inspeccionando en un ciclo cerrado.
Scrum es una implementación de los principios de agile, con tres roles, tres artefactos y un puñado de eventos. El Product Owner decide qué se construye y en qué orden. El Scrum Master elimina los bloqueos y protege el proceso. Los desarrolladores lo construyen. Los artefactos son el product backlog (todo lo que podría construirse, normalmente escrito como historias de usuario), el sprint backlog (a lo que se compromete este sprint) y el incremento (lo que realmente se entrega). Los eventos son la planificación del sprint, el daily standup, la revisión del sprint y la retrospectiva.
Donde Scrum ayuda de verdad: en equipos que luchan con el foco y la visibilidad. El sprint fijo obliga a un compromiso real, la revisión obliga a una demo real y la retro obliga al equipo a mirar su propio proceso en lugar de ignorarlo. Para un equipo que nunca ha entregado a un ritmo, Scrum es un andamiaje útil.
Donde se convierte en teatro: cuando los eventos sobreviven pero la sustancia muere. Un standup que es un informe de estado para el manager. Una revisión sin software funcional que mostrar. Una retro que produce las mismas tres acciones cada quincena y no actúa sobre ninguna. Muchos equipos de «Scrum» ejecutan las ceremonias y no obtienen ningún valor. Si haces las reuniones pero no puedes demostrar un incremento funcional, no tienes Scrum, tienes un hábito de reuniones.
Ejemplo de la trampa de la sobrecarga: un equipo de cinco personas adopta Scrum al pie de la letra y acaba con planificación del sprint, un daily standup, una sesión de refinamiento del backlog, una revisión del sprint y una retro cada dos semanas. En un equipo de ese tamaño, esa carga de ceremonias puede comerse la mayor parte de un día a la semana por persona, y la precisión de planificación que compra se desperdicia porque un equipo de cinco ya sabe qué hace cada uno. El marco se diseñó para coordinar equipos que habían perdido esa visibilidad; imponerlo entero a un equipo que nunca la perdió es puro impuesto. La solución no es abandonar los bucles de retroalimentación (conserva la demo y la retro) sino dejar caer las ceremonias de coordinación que resuelven un problema que no tienes.
La visión honesta de Wavect: Scrum es un buen marco de inicio y una mala religión. Conserva las partes que crean retroalimentación y descarta las que crean sobrecarga. La mayoría de los equipos maduros derivan hacia algo más ligero, a menudo más cercano a Kanban, una vez que la disciplina se interioriza.