Jeff Sutherland, cocreador de Scrum, explica cómo nació este marco de trabajo en el desarrollo de software y por qué sirve para casi cualquier proyecto. La idea central es trabajar en ciclos cortos con equipos pequeños y autónomos que entregan algo terminado en cada ciclo, revisan qué funcionó y ajustan el rumbo en lugar de seguir un plan rígido.
Lecciones
La planificación en cascada falla porque supone que todo se puede prever. Scrum acepta la incertidumbre y planifica en ciclos cortos, llamados sprints, de una a cuatro semanas.
Cada sprint debe cerrar con algo funcionando que se pueda mostrar. Lo que queda a medio hacer no cuenta como avance.
Los equipos rinden más si son pequeños, de unas siete personas, multifuncionales y autónomos. Con cada persona extra crecen los canales de comunicación y todo se vuelve más lento.
La reunión diaria de quince minutos responde tres preguntas: qué hice ayer, qué haré hoy y qué me lo impide. Sirve para detectar obstáculos, no para rendirle cuentas al jefe.
El dueño del producto ordena la lista de trabajo pendiente por valor. Una parte pequeña de las funciones suele concentrar la mayor parte del valor para el cliente.
Estimar en términos relativos, comparando tareas entre sí con puntos y la secuencia de Fibonacci, resulta más preciso que estimar en horas.
Hacer varias cosas a la vez es desperdicio: cada cambio de contexto consume tiempo y energía. Termina una tarea antes de empezar la siguiente.
Trabajar horas extra no rinde. Pasado cierto punto, la productividad cae y aparecen errores que después cuesta corregir.
La retrospectiva al final de cada sprint mejora cómo trabaja el equipo, además de lo que produce. Las mejoras pequeñas y constantes se acumulan.
