Resumen del libro
Metodología Scrum
Por: Jeff Sutherland
La metodología de desarrollo ágil de proyectos que está revolucionando el mundo
Introducción
Hace más de veinte años Ken Schwaber y yo inventamos Scrum con el objetivo de encontrar una forma más eficaz de crear software. Hasta aquel momento, la mayoría de las empresas usaba el método en cascada, en el que el trabajo se completa por fases y se avanza paso a paso hasta el lanzamiento del producto. Este proceso era lento, impredecible y a menudo el resultado era un producto que nadie quería o por el que nadie estaba dispuesto a pagar.
Lo normal en la planificación con diagramas de Gantt es no cumplir los plazos y pasarse del presupuesto de forma desastrosa. Para evitar esto, en 1993 inventé una forma nueva de hacer las cosas: Scrum, un método que está en línea con los sistemas evolutivos, adaptativos y que se autocorrigen. Este método ha sido adoptado por la industria tecnológica, pero sigue siendo relativamente desconocido en otros campos. Ese fue el motivo de que escribiera este libro, revelar y explicar el sistema Scrum a empresas fuera del ámbito de la tecnología.
En las páginas que siguen, descubrirá que hemos utilizado el Scrum para hacer de todo, desde automóviles asequibles de bajo consumo a la actualización del sistema de datos del FBI. Este libro le ayudará a entender cómo el Scrum puede ayudarle a transformar el funcionamiento de su compañía y su forma de crear, planificar y pensar, del mismo modo que ha revolucionado la innovación y el tiempo de lanzamiento al mercado en un número grandísimo de empresas nuevas y en cantidad de productos que proceden de Silicon Valley y del mundo de la tecnología.
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.
El efecto de Sentinel en el FBI ha sido espectacular. La capacidad de comunicar y compartir información ha cambiado de forma radical lo que el FBI es capaz de hacer. En enero de 2013, una oficina del FBI recibió el aviso de que una cuenta de una pequeña empresa había sido pirateada. Se había transferido un millón de dólares a otro país antes de que los bancos de EE. UU. pudieran detener la operación. Gracias a Sentinel, el oficial del FBI se coordinó con el agregado jurídico de la embajada en el país de destino, que alertó a las autoridades locales, que a su vez interceptaron la transferencia antes de que llegara al sistema bancario. Todo esto ocurrió en cuestión de horas, lo que sencillamente no podría haber sucedido en la época (no tan lejana, aunque se crea lo contrario) de las tres copias de papel y los bolígrafos rojos para señalar lo importante en un expediente…
En una entrevista, Johnson contó que lo más impactante del Scrum eran las demos, que le permitieron avanzar con regularidad hacia un producto demostrable. El Scrum, basado en la generación de versiones operativas del producto en ciclos cortos, facilita el feedback temprano y la eliminación de errores y esfuerzos baldíos. El Scrum no va dirigido a los programadores, sino a los clientes y a todas las partes implicadas.
Los miembros del equipo original siguen en sus puestos, realizando mejoras y añadiendo nuevas funcionalidades al sistema que construyeron.
¿Qué me llevó a crear el Scrum? Tras la guerra de Vietnam, cursé un máster en Estadística en la Universidad de Stanford y me hice profesor de Matemáticas en la Academia de las Fuerzas Armadas. Allí inicié mi doctorado en Biometría y mi director de tesis me retó a explicar las variaciones entre los tipos de tumores. Durante casi una década aprendí mucho sobre teoría de sistemas y también sobre adaptación. Años después, se me ocurrió que, al igual que las células, las organizaciones, equipos y personas son sistemas complejos adaptativos.
En 1983, la empresa MidContinent Computer Services me contrató para trabajar en las redes de cajeros automáticos. Como se producían retrasos crónicos y los proyectos solían sobrepasar el presupuesto asignado, conseguí formar una organización separada formada por todos aquellos implicados en la red de cajeros automáticos. Allí puse en práctica algunos elementos de lo que luego sería el Scrum, como responsables de producto (Product Owners), lista de objetivos o requisitos pendientes (Product Backlog) y sprints semanales. En seis meses nos convertimos en el departamento más rentable de la empresa.
Convencido de que el constante feedback era la mejor forma de aumentar el rendimiento, en 1993 llevé mis nuevas ideas a una empresa llamada Easel. Mi objetivo era desarrollar una línea nueva de productos que permitieran a nuestros clientes diseñar y construir aplicaciones internas. Mi equipo y yo pasamos semanas leyendo publicaciones sobre organización de equipos y desarrollo de productos hasta que encontramos un artículo de 1986 de la Harvard Business Review escrito por los catedráticos japoneses Hirotaka Takeuchi e Ikujiro Nonaka.
En este texto, titulado The New Product Development Game (‘El nuevo juego del desarrollo de producto’), sus autores afirmaban que el sistema en cascada tenía fallos importantes y que las empresas que triunfaban lo hacían porque utilizaban un proceso de desarrollo simultáneo, rápido y flexible. Los equipos eran multidisciplinares; tenían autonomía; los directivos no daban órdenes sino que actuaban como facilitadores apartando los obstáculos del camino de sus equipos; y tenían un propósito trascendente, es decir, aspiraban a algo más allá de sí mismos. Los catedráticos comparaban el trabajo de estos equipos con el rugby y decían que los mejores actuaban como si estuvieran en una Scrum o melé: “la pelota se la pasan los unos a los otros en el equipo, mientras avanzan como una unidad en el campo”.
Aquel fue el nacimiento el Scrum. El producto fue entregado en Easel en el plazo contemplado de seis meses sin desviaciones presupuestarias y con menos fallos que cualquier entrega anterior. Me entusiasmé tanto con las posibilidades de esta nueva forma de gestión de proyectos que todo mi trabajo futuro se centró en perfeccionar el Scrum. Dos años después, en el marco de un congreso de la Association for Computing Machinery presenté un artículo escrito junto a Ken Schwaber titulado “SCRUM Development Process” (‘El proceso de desarrollo del SCRUM’) en el que codificábamos estas prácticas con el objetivo de crear grupos hiperproductivos guiados por el principio PDCA (Plan, Do, Check, Act), o Planificar, Hacer, Comprobar y Actuar.
El PDCA se basa en las técnicas de fabricación japonesa, que a su vez se deben a la labor del estadounidense W. Edwards Deming, quien trabajó en aquel país durante la ocupación militar tras la Segunda Guerra Mundial. La influencia de Deming en la fabricación japonesa fue espectacular. Formó a cientos de ingenieros en lo que se denomina “control estadístico de procesos”. La idea básica es medir exactamente lo que se está haciendo y en qué medida se está haciendo bien, y esforzarse por una “mejora continua” (kaizen). No hay que mejorar solo una vez; hay que mejorar constantemente. Siempre hay que estar buscando algo que mejorar. Nunca jamás conformarse con lo que se ha logrado.
El ciclo PDCA es lo que permitió que empresas como Toyota se convirtieran en líderes mundiales. En Japón, el Scrum no se ve como una moda, sino como una forma de vida. Práctica, atención y esfuerzo continuado para que las cosas fluyan y ocurran. Ese es el objetivo final del Scrum, un método que nos permite alcanzar un propósito más alto con alegría y coordinación. Veamos cómo conseguirlo.
Para continuar leyendo
Biografía del autor
Jeff Sutherland
Jeff Sutherland es el creador de Scrum. Ha sido vicepresidente de varias empresas de informática y de ingeniería, en algunas de las cuales se ha puesto en práctica Scrum con excelentes resultados. Además, dirige talleres en todo el mundo, comparte sus conocimientos y sus experiencias con numerosas empresas y organismos, e imparte conferencias sobre las normas y la metodología de Scrum.
Descargar Resumen
Descargas bloqueadashelp_outline
Ficha técnica
Editorial: Planeta
ISBN: 9788408135326
Temáticas: Habilidades directivas Gestión del tiempo y técnicas de productividad Mejora de procesos
Comprar el libro
Si has leído el resumen y quieres profundizar más, te recomendamos comprar el libro completo, en papel o ebook, haciendo click aquí
