Czytaj książkę: «Resumen del libro "Metodología Scrum" de Jeff Sutherland»

Los orígenes del Scrum: lo que ya no vale

En 2009 Jeff Johnson, antiguo subdirector de Ingeniería de Tecnologías de Información de Lehman Brothers, aceptó un trabajo en el FBI. Tenía que crear un nuevo sistema informático para la institución adaptado al siglo XXI tras varios años de fracasos y millones de dólares del contribuyente dilapidados. Después de los atentados del 11 de septiembre de 2001, la Comisión del Congreso de EE. UU. había constatado que en el FBI no existía un mecanismo eficaz para recuperar o compartir los conocimientos adquiridos durante años. Sin embargo, los sucesivos y costosos planes que se habían puesto en marcha habían fallado.

La razón era que el método en cascada y los diagramas de Gantt, que señalan las distintas fases de un proyecto divididas en etapas de descubrimiento, diseño, desarrollo y comprobación, eran poco realistas. Los plazos no se cumplían y los objetivos no se lograban.

En los diagramas de Gantt, todos y cada uno de los pasos de un proyecto se representan en detalle. Cada hito. Cada fecha de entrega. Contemplar estos gráficos es impresionante. He visitado muchísimas empresas en las que el único trabajo de algunas personas consiste en actualizar ese diagrama de Gantt todos los días. El único problema de este sistema es que siempre, siempre, falla. Cuando estos planes elegantemente diseñados se encuentran con la realidad, se vienen abajo. Pero en lugar de desechar el plan o la forma de pensar en el plan, los gerentes contratan a personas para que parezca que funciona. Básicamente, contratan a gente para que les mienta.

Jeff Johnson y su jefe, Chad Fulgham, adoptaron el sistema Scrum, creado por mí y aplicado por primera vez al desarrollo de software. La mayor ventaja del Scrum frente al método de planificación en cascada es que se basa en la forma en que la gente trabaja, no en cómo dice que trabaja. 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. Tratar de reducir la conducta humana a diagramas y gráficos codificados por colores es absurdo y supone un esfuerzo condenado al fracaso.

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 haciendo apunta en la buena dirección y si es lo que la gente realmente quiere? ¿Y por qué no comprobar si existen maneras 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 adaptació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 reflexión, introspección, sinceridad y disciplina.

En el FBI, el primer problema del nuevo equipo fueron los contratos externos, que habían consumido millones de dólares sin haber conseguido el tan deseado sistema de información moderno. Jeff Johnson y Chad Fulgham internalizaron el desarrollo de la programación y redujeron el personal de varios cientos a menos de cincuenta personas. Imprimieron toda la documentación sobre los requisitos que debería tener el nuevo sistema y establecieron prioridades. A menudo, la gente dice que todo es importante y ya está. Pero en la programación de software existe una regla, nacida tras décadas de investigación: el 80 % del valor de cualquier producto de software no reside más que en el 20 % de sus características.

Jeff Johnson y su equipo no sabían exactamente cuánto tardarían en concluir el proyecto. Algo que yo siempre les digo a los directivos es que sabré la fecha cuando vea cómo mejoran los equipos, lo rápido que pueden ir y lo que pueden llegar a acelerar. Y esto es lo que hizo Johnson al establecer ciclos de trabajo de dos semanas. Al final de cada ciclo se producía una mejora del producto final, algo que funcionaba y se podía mostrar a los usuarios. Esto es lo que en Scrum denominamos sprints. Johnson usó estos sprints para medir la velocidad de los equipos y su capacidad de mejora y averiguar qué impedimentos los retrasaban. A los tres meses de trabajar de esta manera, Johnson ya tenía una idea bastante aproximada de cuándo podría tener completado todo el proyecto.

El proyecto Sentinel, puesto en marcha en julio de 2012, necesitó 18 meses de codificación y otros dos para implementarlo en todo el FBI. Fue una tremenda presión de tiempo porque hay que tener en cuenta que este sistema se emplea prácticamente para todo: para pagar a los informantes del FBI, almacenar pruebas, organizar los expedientes de los casos, registrar reuniones... Años de trabajo perdido e ingentes cantidades de dinero habían instalado el escepticismo entre los responsables y usuarios del FBI. Pero el método Scrum logró vencer todas las reticencias y acabó con el mito de que un proyecto complejo necesita una fortuna y décadas para desarrollarse.