SELLO PLANETA

COLECCIÓN PP
FORMATO 15 x 23
R

SERVICIO xx

JEFF SUTHERLAND

SCRUM
Otros títulos publicados por Editorial Planeta:
ESTE LIBRO ES PARA LOS CONVENCIDOS DE QUE

SCRUM
LAS COSAS PUEDEN (Y DEBEN) HACERSE MEJOR. PRUEBA DIGITAL
Jeff Sutherland es el creador de Scrum. Ha VALIDA COMO PRUEBA DE COLOR
EXCEPTO TINTAS DIRECTAS, STAMPINGS, ETC.
sido vicepresidente de varias empresas de in-
Para todos los que creemos que las reuniones podrían ser más cortas formática y de ingeniería, en algunas de las
DISEÑO 12/12 sbrina
y fructíferas, que las jerarquías empresariales deberían ser más cuales se ha implementado Scrum con exce-

JEFF SUTHERLAND
fluidas y que nuestra vida en general podría estar mejor organizada. lentes resultados. EDICIÓN

Y es que Scrum logra todo eso y mucho más. Scrum es prácticamen- Además, realiza talleres por el mundo ente-
te mágico. Pero no se trata de magia, sino de un método desarrollado, ro, comparte su conocimiento y sus experien-
EL NUEVO Y
mejorado y probado a lo largo de los años cuyos principios beben de cias con numerosas empresas y organismos,
disciplinas tan variadas como las artes marciales, la robótica o el REVOLUCIONARIO e imparte conferencias sobre las normas y la
CARACTERÍSTICAS
rugby. Scrum es capaz de todo, de lo más grande a lo más pequeño: MODELO ORGANIZATIVO metodología de Scrum.
puede mejorar la situación del Tercer Mundo o ayudarnos a afrontar
con serenidad una estresante mudanza. Scrum cambia nuestra forma
QUE CAMBIARÁ IMPRESIÓN XX

de enfrentarnos al mundo, consigue que todos los miembros de un TU VIDA

equipo saquen lo mejor de ellos mismos y que, por lo tanto, el traba-
PAPEL XX
jo en equipo sea efectivo. Scrum nos ayuda a conseguir aquello que
queremos y, lo más importante, nos da aquello que más echamos de
PLASTIFÍCADO XX
menos: más tiempo o, lo que es lo mismo, un tiempo mejor invertido.
UVI XX
En SCRUM, escrito con gran claridad y brillantez por el propio creador
RELIEVE XX
del método, Jeff Sutherland, encontraremos todo lo que necesitamos
para poner en práctica el sistema que definitivamente va a mejorar
BAJORRELIEVE XX
nuestras vidas.
STAMPING XX

FORRO TAPA XX

PVP 16,50 € 10102230

Diagonal, 662, 08034 Barcelona Diseño de la cubierta: Departamento de Arte y Diseño, Área Editorial
GUARDAS XX
Grupo Planeta
www.editorial.planeta.es
Ilustración de la cubierta: © Edmond Haro
www.planetadelibros.com 9 788408 135326 INSTRUCCIONES ESPECIALES
XX

17 mm
 Jeff Sutherland

Scrum
El nuevo y revolucionario modelo
organizativo que cambiará tu vida

Traducción de Victoria Eugenia Gordo del Rey

032-117515-SCRUM.indd 3 05/12/14 11:14

 No se permite la reproducción total o parcial de este libro, ni su incorporación a un sistema
informático, ni su transmisión en cualquier forma o por cualquier medio, sea éste
electrónico, mecánico, por fotocopia, por grabación u otros métodos, sin el permiso previo
y por escrito del editor. La infracción de los derechos mencionados puede ser constitutiva
de delito contra la propiedad intelectual (Art. 270 y siguientes del Código Penal)
Diríjase a CEDRO (Centro Español de Derechos Reprográficos) si necesita fotocopiar
o escanear algún fragmento de esta obra. Puede contactar con CEDRO a través de la web
www.conlicencia.com o por teléfono en el 91 702 19 70 / 93 272 04 47

Título original: Scrum

© Jeff Sutherland y Scrum, Inc., 2014

© de la traducción, Victoria Eugenia Gordo del Rey, 2015
© Editorial Planeta, S. A., 2015
Diagonal, 662-664, 08034 Barcelona (España)
www.editorial.planeta.es
www.planetadelibros.com

Primera edición: enero de 2015

Depósito legal: B. 26.476-2014
ISBN 978-84-08-13532-6
ISBN 978-0-385-34645-0, Crown Business, Nueva York, edición original
Composición: Víctor Igual, S. L.
Impresión y encuadernación: Huertas Industrias Gráficas, S. A.
Printed in Spain – Impreso en España

El papel utilizado para la impresión de este libro es cien por cien libre de cloro y está
calificado como papel ecológico

032-117515-SCRUM.indd 4 10/12/14 18:48

 Índice

Prefacio 9

1. La forma en que funciona el mundo ya no vale 13

Una nueva forma de pensar 21
Arreglar el FBI 25
Los puntos clave 39

2. Los orígenes del Scrum 41

Aprender a pensar como un robot 47
Dejemos de perseguir cascadas 50
Inspeccionar y adaptar 54
Cambiar o morir 57
Shu Ha Ri 58
Los puntos clave 60

3. Equipos 61
La larga línea gris 66
El Scrum en tiempos de revuelta 69
Un equipo que haga el trabajo 73
El Scrum en la guerra 76
El tamaño sí importa, pero no en el sentido
que usted cree 82

032-117515-SCRUM.indd 5 10/12/14 18:48

 El Scrum Master 85
No odie al jugador, odie el juego 87
Llegar a ser «grande» 94
Los puntos clave 95

4. Tiempo 97
El sprint 98
La Reunión Diaria 103
Una y otra vez 108
Los puntos clave 112

5. Desperdiciar es delito 113

Hacer las cosas de una en una 116
A medio hacer no significa hecho 124
Hacerlo bien a la primera 127
Trabajar demasiado duro hace que se trabaje más 132
Sea razonable 139
Fluir 141
Los puntos clave 142

6. Planifique sobre la realidad, no sobre

la fantasía 145
Planificación de bodas 153
El tamaño importa, pero solo relativamente 157
El oráculo de Delfos 161
Póquer de planificación 166
No hay tareas; solo hay historias 170
Historias cortas 173
Listo y hecho 175
Planificación del sprint 177
Conozca su velocidad 178
Los puntos clave 183

032-117515-SCRUM.indd 6 05/12/14 11:14

 7. Felicidad  185
La felicidad es el éxito  188
Cuantificar la felicidad  190
Hacer todo visible  194
Proporcionar felicidad  199
Explotar la Burbuja de la Felicidad 
203
Feliz hoy, feliz mañana  209
Los puntos clave  213

8. Prioridades  215
El backlog o lista de objetivos pendientes:
qué hacer y cuándo hacerlo  217
El Responsable de Producto  220
Observar, Orientarse, Decidir, Actuar  226
Lo primero es lo primero  235
Lanzamiento  237
Dinero fácil y cambios gratis  241
Riesgo  245
Esto es lo que tienes que hacer mañana  249
Los puntos clave  251

9. Cambiar el mundo  253

Educación  254
Pobreza  263
El gobierno  268
Así trabajaremos todos algún día 
276
¿Qué no podemos hacer?  284
Los puntos clave  286

Apéndice. Implementar el Scrum: por dónde empezar  289

Notas  295
Índice alfabético  301
Agradecimientos  307

032-117515-SCRUM.indd 7 12/12/14 11:12

 1
La forma en que funciona el mundo ya no vale

Jeff Johnson estaba bastante seguro de que no iba a ser un

buen día. El 3 de marzo de 2010, la Oficina Federal de Investi-
gación (FBI) cancelaba su mayor y más ambicioso proyecto
de modernización, el que se suponía iba a impedir otro 11 de
septiembre, pero que había degenerado en una de las mayores
debacles informáticas de todos los tiempos. Durante más de
una década el FBI había estado tratando de actualizar su siste-
ma informático y, por lo que parecía, iban a fracasar. Una vez
más. Ahora la criatura estaba en sus manos.
Se había presentado en el FBI siete meses antes, llamado
por el nuevo jefe de Información, Chad Fulgham, con quien
había trabajado en Lehman Brothers. Jeff era subdirector del
Departamento de Ingeniería de Tecnologías de la Informa-
ción. Tenía un despacho en el piso más alto del edificio J. Edgar
Hoover, en el centro de Washington, D.C. Era un despacho
muy grande. Con vistas al Monumento a Washington y todo.
Quién le iba a decir entonces a Jeff que los dos años siguientes
los pasaría casi enteros en un despacho del sótano con pare-
des de ladrillos de hormigón y sin ventanas, tratando de arre-
glar algo que todo el mundo decía que no tenía solución.

032-117515-SCRUM.indd 13 10/12/14 18:48

 14 | Scrum

«No fue una decisión fácil», dice Jeff. Él y su jefe habían

llegado a la conclusión de que había que acabar con un pro-
grama que había llevado casi una década y costado cientos de
millones de dólares. En aquel momento tenía más sentido in-
ternalizar el proyecto y llevarlo a cabo ellos mismos. Pero ha-
bía que hacerlo y hacerlo bien.
El proyecto era el muy esperado sistema informático que
llevaría al FBI a la era moderna. En 2010 —la era de Face-
book, Twitter, Amazon y Google—, el FBI seguía archivando
la mayoría de sus informes en papel. El sistema que utilizaba
tenía por nombre Sistema de Apoyo Automatizado de Casos.
Funcionaba con ordenadores gigantescos que debían de ha-
ber sido tecnología punta allá por la década de 1980. Muchos
agentes ni siquiera lo utilizaban. Era demasiado engorroso y
demasiado lento para una era de ataques terroristas y crimi-
nales de movimientos muy rápidos.
Cuando un agente del FBI quería hacer algo —cualquier
cosa—, desde pagar a un informador a perseguir a un terro-
rista o presentar un informe sobre un ladrón de bancos, el
proceso no era muy distinto al de treinta años atrás. Johnson
lo describe así:

Tenías que escribir un documento en un procesador de textos

e imprimir tres copias. Una se enviaba a la cadena de mando
para su aprobación. Otra se almacenaba localmente en caso de
que la anterior se perdiera. Y con la tercera tenías que coger un
bolígrafo rojo —no es broma, un bolígrafo rojo— y marcar las
palabras clave para la base de datos. En una palabra, cada uno
indexaba su propio informe.

Cuando se aprobaba una solicitud, la copia en papel ini-

ciaba su recorrido administrativo descendente con un núme-

032-117515-SCRUM.indd 14 05/12/14 11:14

 La forma en que funciona el mundo ya no vale | 15

ro. Un número escrito en un papel era la forma en que el FBI

llevaba el registro de todos los expedientes de sus casos. Este
método era tan anticuado y endeble que en parte se le echó la
culpa del fracaso del FBI a la hora de «atar los cabos» que
mostraban que varios activistas de Al Qaeda habían entrado
en el país las semanas y meses anteriores al 11 de septiembre.
En una de las oficinas se sospechaba de una persona. En otra
se preguntaban por qué tantos extranjeros sospechosos esta-
ban recibiendo clases de vuelo. Otra tenía a alguien vigilando
a una lista de personas pero en ningún momento se lo comu-
nicó a nadie más. Nadie en el FBI pudo atar cabos.
A raíz del ataque, la Comisión del 11 de Septiembre proce-
dió a un análisis detallado para descubrir qué había fallado. Los
analistas, afirmó la Comisión, no podían acceder a la propia
información que se suponía debían analizar. «La mala calidad
de los sistemas de información del FBI —dice el informe— ha-
cía que el acceso dependiera en gran parte de las relaciones per-
sonales de cada analista con los individuos de las unidades o
brigadas operativas en las que se encontraba la información.»
Antes del 11 de septiembre, el FBI jamás había completado
del todo una evaluación de la amenaza terrorista global para
Estados Unidos. Había múltiples razones para esto, desde la
concentración en el ascenso profesional hasta la ausencia de
una información compartida. Pero el informe destacaba la
falta de sofisticación tecnológica como posible razón clave
para que el FBI fracasara tan estrepitosamente en los días pre-
vios al 11 de septiembre. «Los sistemas de información del FBI
eran tristemente inadecuados —concluye el informe de la Co-
misión—. El FBI era incapaz de saber lo que sabía: no existía
un mecanismo eficaz para recuperar o compartir el conoci-
miento adquirido durante años.»

032-117515-SCRUM.indd 15 05/12/14 11:14

 16 | Scrum

Cuando los senadores empezaron a formular preguntas

incómodas a la agencia, el FBI básicamente respondió: «No se
preocupen, tenemos un plan de modernización en marcha».
El plan se denominaba Sistema Virtual de Archivo de Casos
(VCF), y se suponía que lo iba a cambiar todo. Sin desperdi-
ciar la oportunidad que ofrecía cada crisis, los responsables
dijeron que necesitaban 70 millones de dólares además de
los 100 millones que ya se habían presupuestado para el plan.
Si uno relee los reportajes de prensa de aquel momento sobre
el VCF, se dará cuenta de que las palabras revolucionario y
transformación se empleaban de forma reiterada.
Tres años después se decidió eliminar el programa. No
funcionaba, ni lo más mínimo. El FBI había gastado 170 mi-
llones de dólares de los contribuyentes en comprar un siste-
ma informático que nunca se utilizaría; ni una sola línea de
código, ni una aplicación, ni un solo clic de ratón. El proyecto
entero fue un desastre sin paliativos. Y no se trataba de que
IBM o Microsoft hubieran cometido un error. Las vidas de la
gente estaban, casi literalmente, en juego. Como el senador
de Vermont Patrick Leahy, entonces el demócrata de más alto
rango en el Comité Judicial del Senado, declaró al Washing-
ton Post en aquel momento:

Teníamos información que podía haber evitado el 11 de sep-

tiembre. Estaba ahí, y no se hizo nada con ella... Yo no he visto
que hayan corregido los problemas... A este paso llegaremos al
siglo xxii sin tener todavía la tecnología del siglo xxi.1

Resulta bastante significativo que muchas de las personas

que estaban en el FBI cuando ocurrió el desastre del Archivo
de Casos Virtual ya no estén allí.

032-117515-SCRUM.indd 16 05/12/14 11:14

 La forma en que funciona el mundo ya no vale | 17

En 2005 el FBI anunció un nuevo programa, Sentinel.

Esta vez funcionaría. Esta vez contarían con los dispositivos
de seguridad adecuados, los procedimientos presupuestarios
adecuados, los controles adecuados. Habían aprendido la lec-
ción. ¿Cuál sería el precio? Nada más que 451 millones de dó-
lares. Y estaría completamente operativo en 2009.
¿Qué podía salir mal esta vez? En marzo de 2010 la res-
puesta cayó sobre la mesa del despacho de Jeff Johnson.
Lockheed Martin, el contratista al que se le había encargado
el sistema Sentinel, había gastado ya 405 millones. Solo ha-
bían desarrollado la mitad del proyecto, y llevaban casi un
año de retraso. Un análisis independiente estimó que llevaría
entre otros seis y ocho años más acabar el proyecto, y los con-
tribuyentes tendrían que invertir otros 350 millones como
mínimo.
Johnson tenía que encontrar la forma de salir del ato-
lladero.
Explicar qué es lo que fue mal y cómo se solucionó es la
razón por la que escribo este libro. No fue porque aquella
gente no fuera inteligente. No fue porque la agencia no con-
tara con el personal o la tecnología adecuados. No fue que no
hubiera una ética del trabajo o que faltara el instinto compe-
titivo.
Fue por la forma de trabajar de la gente. La forma de tra-
bajar de la mayoría de la gente. La forma en la que creemos
que hay que hacer el trabajo, porque así es como nos han en-
señado a hacerlo.
Cuando te enteras de lo que ocurrió, al principio te parece
que tenía sentido: la gente de Lockheed se sentó a hablar an-
tes de presentar su oferta por el contrato, estudió los requisi-
tos y comenzó a planear cómo construir un sistema que hi-

032-117515-SCRUM.indd 17 05/12/14 11:14

 18 | Scrum

ciera todo eso. Tuvieron a muchas personas inteligentes

trabajando durante meses, pensando qué era lo que había que
hacer. Luego pasaron más meses planeando cómo hacerlo.
Elaboraron preciosos diagramas representando todo lo que
había que conseguir y el tiempo que llevaría completarlos to-
dos y cada uno de ellos. A continuación, con una cuidadosa
selección de colores, mostraban cómo cada pieza del proyec-
to iba sucediéndose en cascada, como una catarata.

Estos diagramas se denominan diagramas de Gantt, en

honor a Henry Gantt, que fue quien los desarrolló. Con la
llegada de los ordenadores personales en la década de 1980 y
la facilitación que esto supuso para la creación de estas intrin-
cadas gráficas —y para hacerlas realmente complejas—, se
han convertido en obras de arte. Todos y cada uno de los pa-
sos de un proyecto se representan en detalle. Cada hito. Cada
fecha de entrega. Contemplar estos diagramas es impresio-
nante. El único problema que tienen es que siempre, siempre,
se equivocan.
Henry Gantt inventó sus famosos diagramas allá por 1910.
Fueron utilizados por primera vez en la primera guerra mun-

032-117515-SCRUM.indd 18 10/12/14 18:48

 La forma en que funciona el mundo ya no vale | 19

dial por el general William Crozier, jefe de Material Militar

del ejército de Estados Unidos. Cualquiera que haya estudia-
do esa guerra sabe que su capacidad organizativa no fue pre-
cisamente su rasgo distintivo. ¿Por qué un instrumento de la
primera guerra mundial se ha convertido en la herramienta
utilizada en la gestión de proyectos del siglo xxi es algo que
no he entendido nunca. Perdimos la fe en la guerra de trin-
cheras, pero, de algún modo, las ideas en las que se basaba
siguen gozando de aceptación.
Es extremadamente tentador: todo el trabajo necesario
para un proyecto de grandes dimensiones queda expuesto a
la vista de quien quiera verlo. He visitado muchísimas em-
presas en las que el único trabajo de algunas personas consis-
te en actualizar ese diagrama de Gantt cada día. El problema
es que, cuando ese plan tan elegantemente diseñado se en-
cuentra con la realidad, se viene abajo. Pero en lugar de dese-
char el plan o la forma de pensar en el plan, los gerentes con-
tratan personas para que parezca que funciona. Básicamente,
pagan a gente para que les mienta.
Este lamentable patrón recuerda al de los informes que
recibía el politburó soviético en la década de 1980, antes del
colapso total de la URSS. Un absoluto espejismo. Tanto aho-
ra como entonces, los informes adquieren mayor importan-
cia que la realidad que se supone que deben describir y, si
existe alguna discrepancia, el problema es la realidad, no los
diagramas.
Cuando yo era cadete en West Point, dormía en la antigua
habitación de Dwight Eisenhower. A veces, por la noche, el
reflejo de las farolas en una placa dorada que había sobre la
repisa de la chimenea me despertaba. Dwight D. Eisen-
hower durmió aquí, decía la placa. Entonces recordaba que

032-117515-SCRUM.indd 19 10/12/14 18:48

 20 | Scrum

Eisenhower una vez comentó que la planificación del comba-

te es importante, pero que, al primer disparo, tus planes se
convierten en humo. Al menos, él tenía el suficiente sentido
común para no usar los diagramas de Gantt.
De modo que Lockheed presentó al FBI todos estos pre-
ciosos diagramas, y firmaron el contrato. Supuestamente,
la tarea estaba tan bien planificada que nada podía ir mal.
«Mira, todo está ahí en el plan, con su código de colores, el
sello con la fecha y su gráfico de barras.»
Sin embargo, cuando Jeff y su jefe, el director de Sistemas
de Información, Chad Fulgham, miraron el plan en la prima-
vera de 2010, ya sabían lo que era, lo que son todos esos dia-
gramas en realidad: una completa invención. Cuando estos
dos hombres empezaron a revisar en qué estado de desarrollo
se encontraba y cuáles eran sus resultados reales, se dieron
cuenta de que el problema no tenía arreglo. Se iban detectan-
do nuevos fallos en el software antes de que se hubieran solu-
cionado los viejos.
Chad comunicó al Inspector General del Departamento
de Justicia que podían terminar el proyecto Sentinel interna-
lizándolo y recortando el número de programadores, y que,
de esta manera, podrían entregar el proyecto en menos de
una quinta parte del tiempo y por una décima parte de la can-
tidad presupuestada. El escepticismo en los —por lo general
lacónicos— informes de la Inspección General al Congreso es
palpable. En el informe de octubre de 2010, tras exponer sus
nueve puntos de preocupación respecto a la propuesta, los
perros guardianes de la Inspección General concluyen:

En resumen, albergamos preocupaciones e interrogantes im-

portantes respecto a la capacidad de este nuevo enfoque para

032-117515-SCRUM.indd 20 05/12/14 11:14

 La forma en que funciona el mundo ya no vale | 21

completar el proyecto Sentinel sin salirse del presupuesto,

puntualmente y con funcionalidades similares...2

Una nueva forma de pensar

Este nuevo enfoque se denomina «Scrum». Lo creé yo hace

veinte años. Actualmente es la única forma que se ha demos-
trado válida para proyectos como este. Existen dos formas de
hacer las cosas: el viejo método «en cascada» que derrocha
cientos de millones de dólares y no llega a nada, o el nuevo,
que con menos personas y en menos tiempo puede producir
más resultados, de mejor calidad y a menor precio. Sé que
esto puede sonar demasiado bonito para ser cierto, pero la
prueba son los resultados. Funciona.
Hace veinte años yo estaba desesperado. Necesitaba una
nueva manera de pensar en el trabajo. Mediante cantidades in-
gentes de investigación y experimentación, así como de revi-
sión de información pasada, me di cuenta de que todos necesi-
tábamos una nueva manera de organizar los empeños
humanos. No es que haya descubierto la pólvora; de todo ello
se ha hablado antes. Existen estudios que se remontan a la se-
gunda guerra mundial que ya establecen algunas de las mejores
maneras para trabajar. Pero, por alguna razón, nadie ha atado
nunca todos estos cabos. Durante las dos décadas pasadas yo he
intentado hacer exactamente eso, y ahora esta metodología ha
llegado a ser ubicua en el primer campo en el que yo la apliqué,
el desarrollo de software. En gigantes como Google, Amazon,
<Salesforce.com> y algunas pequeñas empresas de las que po-
cos han oído hablar todavía, este marco ha cambiado radical-
mente el rumbo de la forma en que la gente hace las cosas.

032-117515-SCRUM.indd 21 05/12/14 11:14

 22 | Scrum

La razón por la que este marco funciona es sencilla. Yo me

fijé en la forma en la que gente trabaja en realidad, no en
cómo dicen que trabajan. Repasé la investigación llevada a
cabo durante décadas y las mejores prácticas de empresas de
todo el mundo, y analicé en profundidad los mejores equipos
dentro de dichas empresas. ¿Qué les hacía superiores? ¿Qué
les hacía diferentes? ¿Por qué algunos equipos alcanzan la
grandeza mientras otros no salen de la mediocridad?
Por razones en las que entraré en capítulos posteriores,
denominé a este marco para el trabajo en equipo «Scrum». El
término procede del juego del rugby, y se refiere a la forma en
que un equipo trabaja en conjunto para hacer que la pelota
avance por el campo. La alineación cuidadosa, la unidad de
propósito y la claridad del objetivo se unen en una sola
cosa. Es la metáfora perfecta de lo que quiero que hagan los
equipos.
Tradicionalmente, la jefatura quiere dos cosas de cual-
quier proyecto: control y predictibilidad. Esto conduce a in-
gentes cantidades de documentos, gráficos y diagramas,
como en el caso de Lockheed. Meses de esfuerzo dedicados a
planear cada detalle para que no haya errores, que no se
sobrepasen los costes y que las cosas se hagan en el plazo pre-
visto.
El problema es que este escenario color de rosa nunca lle-
ga a darse en la realidad. Todos los esfuerzos invertidos en
planificar, tratar de restringir el cambio, tratar de conocer lo
incognoscible, son en vano. Cada proyecto implica el descu-
brimiento de problemas y brotes de inspiración. Tratar de
reducir la conducta humana, en cualquier ámbito, a diagra-
mas y gráficos codificados por colores es absurdo y está con-
denado al fracaso. No es así como trabaja la gente, ni como

032-117515-SCRUM.indd 22 05/12/14 11:14

 La forma en que funciona el mundo ya no vale | 23

progresan los proyectos. Tampoco es así como fructifican las

ideas ni como se hacen las grandes cosas.
Por el contrario, el resultado es que las personas se frus-
tran porque no obtienen lo que quieren. Los proyectos se re-
trasan, no se ajustan al presupuesto y, en demasiadas ocasio-
nes, acaban en un miserable fracaso. Sobre todo, cuando se
trata de equipos que desarrollan un trabajo creativo para pro-
ducir algo nuevo. La mayoría de las veces, la dirección de la
empresa no es consciente de que está deslizándose por esta
pendiente hacia el fracaso hasta que ya se han invertido mi-
llones de dólares y miles de horas de trabajo para nada.
El Scrum cuestiona por qué lleva tanto tiempo y tantos
esfuerzos hacer las cosas, y por qué lo hacemos tan mal a la
hora de imaginar cuánto tiempo y esfuerzo requieren. La ca-
tedral de Chartres tardó en construirse cincuenta y siete años.
Estoy convencido de que al principio del proyecto los cante-
ros miraron al obispo y le dijeron: «Veinte años máximo. Es
probable que lo tengamos en quince».
El Scrum asume la incertidumbre y la creatividad. Sitúa
una estructura en torno al proceso de aprendizaje, permitien-
do a los equipos evaluar tanto lo que han creado como, y no
menos importante, el modo en que lo han hecho. El marco
del Scrum se basa en la manera en que trabajan realmente los
equipos y les proporciona las herramientas para organizarse y
mejorar rápidamente tanto la velocidad como la calidad del
trabajo.
Básicamente, el Scrum se basa en una idea sencilla: cada
vez que iniciamos un proyecto, ¿por qué no comprobamos
cómo va cada cierto tiempo, vemos si lo que estamos hacien-
do apunta en la buena dirección y si es lo que la gente real-
mente quiere? ¿Y por qué no comprobar si existen maneras

032-117515-SCRUM.indd 23 05/12/14 11:14

 24 | Scrum

de mejorar lo que estamos haciendo, de hacerlo mejor y más

rápido, y qué es lo que puede estar impidiendo que sea así?
Esto es lo que se denomina un ciclo de «inspección y adap-
tación». Cada poco tiempo, dejamos de hacer lo que estamos
haciendo, revisamos lo que hemos hecho y vemos si sigue
siendo lo que deberíamos estar haciendo y cómo podríamos
mejorar. Es una idea sencilla, pero ejecutarla requiere re-
flexión, introspección, sinceridad y disciplina. El propósito de
este libro es enseñar cómo se hace. Y no solo en las empresas
de software. Yo he visto utilizar con éxito el Scrum para cons-
truir coches, dirigir una lavandería, enseñar a los alumnos de
una clase, construir naves espaciales, planificar una boda, in-
cluso cómo lo usa mi mujer para asegurarse de que cumplo
con la lista de encargos que me hace cada fin de semana.
Los resultados finales del Scrum —el objetivo, si se quiere
llamar así— son equipos que mejoran espectacularmente su
productividad. Durante los pasados veinte años he formado
estos equipos una y otra vez. He sido director ejecutivo, di-
rector de tecnología o jefe de ingeniería en una docena de
empresas, desde pequeñas start-ups de unas pocas personas
trabajando en una habitación a grandes empresas con ofici-
nas por todo el planeta. Y he trabajado como consultor y ase-
sor para otros centenares de ellas.
Los resultados pueden ser tan espectaculares que grandes
empresas de investigación y análisis como Gartner and Stan-
dish hoy en día afirman que el viejo estilo de trabajo ha que-
dado obsoleto. Las empresas que siguen aferrándose a ideas
experimentadas pero no ciertas de mando y control, y que
tratan de imponer una predictibilidad estricta están sencilla-
mente condenadas al fracaso si tus competidores utilizan el
Scrum. La diferencia es demasiado grande. Empresas de capi-

032-117515-SCRUM.indd 24 05/12/14 11:14

 La forma en que funciona el mundo ya no vale | 25

tal riesgo como OpenView Venture Partners, en Boston, de la

que soy asesor, dicen que el Scrum ofrece una ventaja compe-
titiva demasiado importante para no utilizarla. No se trata
precisamente de personas tibias o poco decididas; son hom-
bres de negocios de mirada escrutadora que simplemente
afirman que «los resultados son incontestables. Las empresas
tienen dos opciones: cambiar o morir».

Arreglar el FBI

En el FBI, el primer problema al que se enfrentaba el equipo

de Sentinel eran los contratos. Cada cambio terminaba sien-
do una negociación contractual con Lockheed Martin. De
manera que Jeff Johnson y Chad Fulgham pasaron meses de-
senmarañando todos los contratos, internalizando el desarro-
llo de la programación y reduciendo el personal de varios
centenares a menos de cincuenta. El equipo básico era toda-
vía más reducido.
La primera semana hicieron lo que hace mucha gente en
las mismas circunstancias: imprimieron toda la documenta-
ción referente a los requisitos. Quien no haya visto nunca un
proyecto de dimensiones tan grandes, puede hacerse a la idea
de que se trata de cientos y cientos de páginas. Yo he visto
apilados montones de papel que alcanzan más de un metro
de altura. Lo he visto proyecto tras proyecto, la gente corta y
pega, y mete mucha morralla, pero en realidad nadie se lee
esos miles de páginas. No pueden. Esa es la cuestión. Han
creado un sistema que les obliga a apoyar una fantasía.
—Había mil cien requisitos. El montón de papeles tenía
un grosor de varios centímetros —dice Johnson.

032-117515-SCRUM.indd 25 05/12/14 11:14

 26 | Scrum

Solo pensar en estos documentos me hace sentir lástima

por la gente que probablemente ha pasado semanas de su
vida creándolos, cuando lo cierto es que no tienen ningún
propósito. El FBI y Lockheed Martin no son los únicos. He
visto esto mismo en casi todas las empresas con las que he
trabajado. Esta inmensa montaña de inutilidad es una de las
razones por las que el Scrum puede constituir una herra-
mienta de cambio tan poderosa para la gente. Nadie debería
pasarse la vida realizando un trabajo inútil. No solo porque
no es un buen negocio, sino porque mata la ilusión.
Así que, una vez que tuvieron en sus manos esta pila de
papeles, se pusieron a leerlos y a priorizar requisitos. Lo que
es de una importancia vital y bastante más difícil de lo que
parece. A menudo la gente dice que todo es importante y ya
está. Pero lo que necesitan preguntar, lo que los equipos del
Sentinel preguntaban era, ¿qué es lo que aportará mayor va-
lor al proyecto? Hagamos esas cosas lo primero. En la progra-
mación de software existe una regla, nacida de décadas de
investigación: el 80 por ciento del valor de cualquier produc-
to de software no reside más que en el 20 por ciento de sus
características. Pensémoslo: ¿cuándo fue la última vez que
utilizamos el Visual Basic Editor en el programa de Microsoft
Word? Probablemente no sabemos ni lo que es Visual Basic,
así que, cómo vamos a saber utilizarlo. Pero está ahí, y al-
guien ha dedicado un tiempo a implementarlo, aunque yo le
garantizo que no aumenta mucho el valor de Word.
Hacer que la gente priorice en función del valor les obliga
a producir ese 20 por ciento primero. Con frecuencia, para
cuando han terminado, se dan cuenta de que en realidad no
necesitan añadir el otro 80 por ciento. O dicho de otra forma:
lo que al principio parecía importante ya no lo es.

032-117515-SCRUM.indd 26 05/12/14 11:14

 La forma en que funciona el mundo ya no vale | 27

Para el equipo de Sentinel, la cuestión acabó siendo: «De

acuerdo, este enorme proyecto con el que estamos es de una
importancia vital y hemos desperdiciado cientos de millones
de dólares en él. ¿Cuándo estará terminado?». Después de
pensarlo, prometieron que la entrega sería en el otoño de
2011. El informe del Inspector General de otoño de 2010
es todo un tratado sobre el escepticismo:

El FBI afirmó que emplearía una «metodología ágil» para com-

pletar el desarrollo de Sentinel, utilizando menos empleados
del FBI, de Lockheed Martin y de las empresas que han sumi-
nistrado los componentes más importantes de Sentinel. En
conjunto, el plan del FBI consiste en reducir el número de con-
tratados que trabajan para Sentinel de 220 a unos 40. El FBI
dijo que, al mismo tiempo, el número de empleados del
FBI asignados al proyecto también disminuirá de 30 a 10...
El FBI nos dijo que cree que puede tener terminado Sentinel
con los 20 millones de dólares que quedan del presupuesto ori-
ginalmente asignado y en un plazo de 12 meses desde el arran-
que de este nuevo enfoque.3

El uso de la expresión «metodología ágil» muestra lo poco

que el Inspector General sabía sobre el Scrum. El término
«ágil» se remonta a un cónclave de 2001 en el que yo y otros
dieciséis líderes en el desarrollo de software redactamos lo
que ha dado en llamarse el Manifiesto Ágil. En él se declara-
ban los siguientes valores: las personas han de anteponerse a
los procesos, los productos que de verdad funcionan se ante-
ponen a documentar lo que se supone que el producto hace,
la colaboración con los clientes se antepone a la negociación
con ellos y responder al cambio se antepone a seguir un plan.

032-117515-SCRUM.indd 27 10/12/14 18:48

 28 | Scrum

El Scrum es el marco que yo construí para poner en práctica

estos valores. No existe una metodología.
Obviamente, la promesa de Johnson de los doce meses era
engañosa en cierto modo. Porque en realidad, no lo sabían;
no podían saberlo. El FBI no sabía lo rápido que sus equipos
podían trabajar en realidad. Es algo que yo siempre les digo a
los directivos:
—Sabré la fecha cuando vea cómo mejoran los equipos, lo
rápido que pueden ir, lo que pueden llegar a acelerar.
También era crucial, claro está, que los miembros de los
equipos pensaran qué podría impedirles acelerar. En palabras
de Johnson: «Yo me ocupaba de eliminar los impedimentos».
Un «impedimento» es un concepto que viene de la empresa
que primero dio forma a un buen número de las ideas en las que
se basa el Scrum: Toyota. Y, más concretamente, el Sistema
de Producción de Toyota de Taiichi Ohno.
No voy a entrar aquí en todos los detalles, pero uno de los
conceptos clave que Ohno introdujo es la idea del «flujo».
Esto es, que la producción debía fluir rápida y suavemente
durante todo el proceso y que, como él mismo dijo, una de las
principales tareas de los directores es identificar y eliminar los
impedimentos que obstaculizan dicho flujo. Todo lo que se
interpone en el camino es desperdicio. En su libro ya clásico,
The Toyota Production System, Ohno confiere al desperdicio
un valor moral a la vez que empresarial:

No es exagerado decir que en un periodo de bajo crecimiento,

dicho desperdicio es un delito contra la sociedad más que una
pérdida de negocio. Acabar con el desperdicio debe de ser
siempre el primer objetivo empresarial.4

032-117515-SCRUM.indd 28 10/12/14 18:48