Jeff Sutherland - Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo (Alta definición) (Spanish Edition)

¿Por qué Scrum?

Creé Scrum, con Ken Schwaber, hace veinte años, como una manera más rápida, confiable y eficaz de crear software en la industria de la tecnología. Hasta ese momento –y aun en 2005–, la mayoría de los proyectos de desarrollo de software se ejecutaban usando el método en cascada, donde un proyecto se completaba en etapas separadas y avanzaba paso a paso hacia el lanzamiento último a los consumidores o usuarios de software. El proceso era lento e impredecible, y a menudo no resultaba en un producto que la gente necesitara o pagara. Retrasos de meses o hasta años eran endémicos al proceso. Los primeros planes paso a paso, expuestos en cómodo detalle en gráficas de Gantt, daban seguridad a la dirección de que teníamos el control del proceso de desarrollo, pero, casi sin falta, pronto nos atrasábamos respecto al programa y rebasábamos desastrosamente el presupuesto.

Para remediar estas fallas, en 1993 inventé una nueva forma de hacer las cosas: Scrum, que representa un cambio radical respecto a las metodologías prescriptivas y verticales de gestión de proyectos del pasado. Scrum se asemeja en cambio a los sistemas evolutivos, adaptativos y capaces de autocorregirse. Desde su concepción, su marco se ha convertido en el modo en que la industria de la tecnología crea software y productos nuevos. Pero aunque Scrum se ha vuelto célebremente exitoso en la gestión de proyectos de software y hardware en Silicon Valley, sigue siendo relativamente desconocido en la práctica general de negocios. Por eso escribí Scrum: para revelar y explicar el sistema de gestión de Scrum a empresas fuera del mundo de la tecnología. En este libro hablaré de los orígenes de Scrum en el Toyota Production System y en el ciclo OODA de la aviación de combate. Describiré cómo organizar proyectos alrededor de equipos pequeños y por qué ésta es una forma muy eficaz de trabajar. Explicaré cómo priorizar proyectos, cómo establecer “sprints” de una semana a un mes para cobrar impulso y responsabilizar a todos los miembros del equipo, cómo realizar breves paradas diarias para estar al tanto de lo que se ha hecho y de los retos que inevitablemente aflorarán. Asimismo, expondré cómo Scrum incorpora los conceptos de mejora continua y productos mínimos viables para obtener realimentación inmediata de los consumidores, en lugar de esperar hasta que un proyecto concluya. Como verás en las páginas que siguen, Scrum se ha usado ya para hacer todo, desde automóviles accesibles de 100 millas por galón (160 km por 3.785 L) hasta la incorporación de los sistemas de base de datos del FBI al siglo XXI.

Sigue leyendo. Descubrirás cómo puede ayudar Scrum a transformar la manera de trabajar, crear, planear y pensar de tu compañía. Creo firmemente que Scrum puede contribuir a revolucionar la forma en que trabajan las empresas de prácticamente todas las industrias, así como revolucionó la innovación y rapidez de arribo al mercado en una deslumbrante serie de nuevas compañías y una variedad pasmosa de nuevos productos salidos de Silicon Valley y el mundo de la tecnología.

–Dr. Jeff Sutherland

J eff Johnson estaba seguro de que aquél no iba a ser un buen día. El 3 de marzo de 2010, el Federal Bureau of Investigation (Buró Federal de Investigación, FBI) de Estados Unidos canceló su más ambicioso proyecto de modernización, que supuestamente impediría otro 11 de septiembre pero que al final se había convertido en una de las mayores debacles de software de todos los tiempos. Durante más de una década, el FBI había intentado poner al día su sistema de cómputo y, al parecer, no lo había conseguido. Una vez más. Sin embargo, en esta ocasión se trataba de un proyecto de Johnson.

Éste había llegado a esa agencia siete meses antes, invitado por el nuevo director de información, Chad Fulgham, con quien había trabajado en Lehman Brothers. Nombrado subdirector de la división de informática, su oficina se hallaba en el piso más alto del J. Edgar Hoover Building, situado en el centro de Washington. Era una oficina grande, con vista al monumento a Washington. Johnson jamás imaginó que pasaría los dos años siguientes en el sótano de ese edificio, en una oficina de hormigón sin ventanas, intentando componer algo que todos juzgaban irreparable.

“No fue una decisión fácil”, dice. Su jefe y él habían resuelto darse por vencidos y acabar con un programa que ya había durado casi una década y costado cientos de millones de dólares. Para ese momento, lo más lógico era que el propio FBI se hiciera cargo del proyecto. “Pero tenía que terminarse y terminarse bien”.

Se trataba del muy esperado sistema de cómputo que introduciría al FBI a la época moderna. En 2010 –la era de Facebook, Twitter, Amazon y Google–, este organismo seguía archivando sus informes en formato impreso. Usaba el Automated Case Support (Soporte Automatizado de Casos), sistema basado en mainframes que había sido de vanguardia en los años ochenta. Pero muchos de sus agentes especiales no lo empleaban. Era demasiado lento y engorroso en una época de ataques terroristas y criminales sumamente dinámicos.

Cuando un agente quería hacer algo –cualquier cosa, desde pagar a un informante hasta perseguir a un terrorista y presentar un informe sobre un asaltabancos– debía seguir casi el mismo procedimiento de treinta años antes. Johnson lo describe de esta manera: “Se hacía un documento en un procesador de palabras y se imprimían tres copias, una para el visto bueno, otra por si la primera se perdía y una más para encerrar en rojo –¡en rojo!– las palabras clave que había que trascribir en la base de datos. Uno mismo indizaba sus informes”.

Una vez aprobada una solicitud, la copia se devolvía a su autor, marcada con un número. Un número en una hoja de papel era la forma en que el FBI seguía la pista de todos sus expedientes. Este método era tan permeable y anticuado que se le creía en parte la causa de que el FBI no hubiera podido “unir los puntos” que indicaban que activistas de Al Qaeda habían entrado al país en las semanas y meses previos al 11 de septiembre. Una de sus oficinas había sospechado de alguien. Otra se había preguntado por qué se enseñaba a volar a tantos extranjeros misteriosos. Otra más había incluido a alguien en una lista de individuos por vigilar, pero sin decírselo a las demás. Nadie en la agencia había asociado entre sí todos esos datos.

La comisión del 11 de septiembre hizo indagaciones tras el ataque para averiguar la razón básica de que eso hubiera pasado. Los analistas, concluyó, no tenían acceso a la información que debían examinar. “El mal estado de los sistemas de información del FBI”, se lee en el reporte correspondiente, “implicaba que ese acceso dependía sobre todo de las relaciones personales de los analistas con los agentes de las brigadas o unidades operativas en poder de la información”.

Antes del 11 de septiembre, el FBI nunca había evaluado la amenaza terrorista general para Estados Unidos. Había muchas razones de ello, desde interés exclusivo en el ascenso hasta no compartir información. Pero ese reporte señalaba el anacronismo tecnológico como posible razón clave de la extrema ineptitud del FBI en los días anteriores al 11 de septiembre. “Los sistemas de información de la agencia eran totalmente insuficientes”, concluía el reporte de dicha comisión. “El FBI no podía saber qué sabía: no contaba con ningún mecanismo eficiente para capturar o compartir sus conocimientos institucionales”.