" Supongamos que al tratar de integrar código de Matt en el sistema, los empleados de control de calidad detectaban un error. Renuente, como la mayoría de los desarrolladores, a corregir ese código de inmediato, Matt se comprometía a ocuparse de eso después. Primero escribía nuevo código. En casi todas las compañías pruebas como ésa no ocurren siquiera el mismo día. Pueden pasar semanas o meses antes de probar todo el código y sólo entonces se descubrirían los problemas. Pero Palm hacía pruebas automáticas diarias de todo su código, así que sabía de inmediato cuándo había un problema. Puesto que examinaba a todos sus “Matts” –cientos de desarrolladores–, la compañía decidió analizar cuánto implicaba remediar un error si se le corregía de inmediato o semanas después. Recuerda que el software puede ser demasiado complicado, así que ¿cuál crees que era la diferencia entre ambas prácticas? De veinticuatro veces. Si un error era atacado el mismo día en que se le cometió, corregirlo llevaba una hora; tres semanas después, veinticuatro. Así el error fuera grande o pequeño, simple o complejo, corregirlo suponía siempre veinticuatro veces más tiempo tres semanas después. Como "

― Jeff Sutherland , Scrum: The Art of Doing Twice the Work in Half the Time