MANUAL DE CAMPO
UNA CLASE MAGISTRAL PARA ACELERAR EL DESEMPEÑO, OBTENER RESULTADOS Y PLANEAR PARA EL FUTURO
Scrum_Manual de campo_2R.indd 5
2/4/20 16:55
SCRUM: MANUAL DE CAMPO Una clase magistral para acelerar el desempeño, obtener resultados y planear para el futuro Título original: T HE SCRUM FIELDBOOK. A Master Class on Accelerating Performance, Getting Results, and Defining the Future © 2019, J.J. Sutherland and Scrum, Inc. Todos los derechos reservados. Traducción: Enrique Mercado Diseño de portada: Estudio Sagahón / Leonel Sagahón Fotograf ía del autor: Brandon Cole D.R. © 2020, Editorial Océano de México, S.A. de C.V. Homero 1500 - 402, Col. Polanco Miguel Hidalgo, 11560, Ciudad de México info@oceano.com.mx Primera edición: 2020 ISBN: 978-607-557-191-1 Todos los derechos reservados. Quedan rigurosamente prohibidas, sin la autorización escrita del editor, bajo las sanciones establecidas en las leyes, la reproducción parcial o total de esta obra por cualquier medio o procedimiento, comprendidos la reprograf ía y el tratamiento informático, y la distribución de ejemplares de ella mediante alquiler o préstamo público. ¿Necesitas reproducir una parte de esta obra? Solicita el permiso en info@cempro.org.mx Impreso en México / Printed in Mexico
Scrum_Manual de campo_2R.indd 6
2/4/20 16:55
Índice
Capítulo uno: La decisión frente a nosotros . . . . . . . . . . . . . . . . . . .
11
Capítulo dos: Para que el costo de cambiar de opinión sea de poco valor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Capítulo tres: Por qué no podemos decidir . . . . . . . . . . . . . . . . . . . .
43
Capítulo cuatro: Ocupado vs. hecho . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Capítulo cinco: Las personas y los lugares que parecen caóticos suelen serlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
Capítulo seis: Estructura es cultura . . . . . . . . . . . . . . . . . . . . . . . . . . . .
113
Capítulo siete: Para que lo hagas bien . . . . . . . . . . . . . . . . . . . . . . . .
141
Capítulo ocho: Lo que no debes hacer . . . . . . . . . . . . . . . . . . . . . . . .
169
Capítulo nueve: La empresa del Renacimiento . . . . . . . . . . . . . . . . .
193
Capítulo diez: Cómo podría ser el mundo . . . . . . . . . . . . . . . . . . . . .
211
Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Índice analítico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
223 225 229
Scrum_Manual de campo_2R.indd 9
2/4/20 16:55
Scrum_Manual de campo_2R.indd 10
2/4/20 16:55
CAPÍTULO UNO
La decisión frente a nosotros
E
ntre las cosas que más me gustan de la vida está descubrir con frecuencia que el mundo no funciona como lo creí. La revelación de mis equivocaciones me entusiasma. Supone que existe una forma de ver el mundo más fresca, mejor, más acertada y más amplia. He recibido en numerosas ocasiones el don de percatarme de que mis antiguos axiomas, mis viejos e inamovibles modos de entender cómo operan las cosas, eran erróneos. Frecuentemente descubro que la forma como funcionan las cosas en la biología, las ciencias, los negocios y la vida es más intrincada y complicada, más sutil y abierta al cambio de lo que alguna vez imaginé, lo cual es para mí increíblemente liberador. Esto me recuerda la historia detrás de la publicación del revolucionario libro de Antoine Lavoisier Traité élémentaire de chimie (Tratado elemental de química) en 1789. Lavoisier propuso en él que una experimentación rigurosa permitiría derivar principios básicos: Es una máxima universalmente admitida en la geometría, y de hecho en todas las ramas del conocimiento, que en el progreso de la investigación debemos ir de lo conocido a lo desconocido. […] De esta forma, de una serie de sensaciones, observaciones y análisis surge un razonamiento consecutivo tan coherente que un observador atento podría remontar a un cierto punto el orden y entrelazamiento de la suma entera del conocimiento humano.1
Lavoisier especuló que había elementos químicos básicos que eran imposibles de dividir y que constituían los componentes de la materia, por lo que procedió a buscarlos con rigor. Él fue el científico que bautizó al
Scrum_Manual de campo_2R.indd 11
2/4/20 16:55
12
Scrum: manual de campo
oxígeno, hidrógeno y carbono, el que descubrió el papel del oxígeno en la combustión y la respiración, y quien demostró que el agua consta de hidrógeno y oxígeno. Revolucionó el campo de la química. Creó un lenguaje totalmente nuevo para describir las interacciones de las partes que integran la realidad. En otras palabras, hizo una novedosa descripción de cómo opera el mundo. Y utilizó los principios básicos que estableció él mismo para predecir la existencia de otros elementos que no se descubrirían hasta tiempo después. Antes de él, los químicos sólo examinaban las sustancias que la naturaleza había esparcido en el paisaje. Lavoisier postuló que no debíamos limitarnos a esos elementos, sino experimentar hasta que halláramos el universo completo de todos los compuestos químicos posibles, no nada más aquellos con los que convenientemente tropezamos. Sus ideas fueron asombrosas. Su libro terminaría por sobresalir como una de las grandes líneas divisorias en la historia de la ciencia. Antes de él, los científicos e intelectuales suponían que el mundo funcionaba de cierto modo; después de él, comprendieron que operaba de manera muy distinta. Fue así como nació la química moderna. El mundo había sufrido un cambio fundamental. Todo en la actualidad, de los botones de tu camisa al frío en tu refrigerador, la tinta de este libro y los chips que impulsan el dispositivo que tienes en las manos mientras lees estas líneas, existe gracias a ese descubrimiento. Cosas como éstas me fascinan. Que un descubrimiento provoque una alteración fundamental en nuestro modo de ver y comprender el mundo en que vivimos. Que todo lo que creíamos conocer sea puesto en duda por nueva información o nuevos datos. Que el mundo sea de una forma un día y al siguiente dispongamos de posibilidades que no habríamos concebido el día anterior.
Una nueva manera de pensar Desde la publicación de mi primer libro, Scrum: el arte de hacer el doble de trabajo en la mitad de tiempo, el cual escribí con mi padre, Jeff Sutherland, un creciente número de personas ha tomado conciencia de que nos encontramos justo en medio de un cambio similar en la forma en que opera el mundo de los negocios. Una revolución impulsa el
Scrum_Manual de campo_2R.indd 12
2/4/20 16:55
La decisión frente a nosotros 13
cambio. Y al igual que la obra de Lavoisier, esta revolución pone también ante nuestros ojos un mundo nuevo, en el que los antiguos límites no se aplican. En mis recientes conversaciones con compañías, directores generales y altos ejecutivos, uso ya una nueva frase: Scrum es el arte de cambiar lo posible. Scrum es un imperativo en vista de los rápidos cambios sociales, económicos y políticos de nuestra era, debidos a la celeridad extrema del avance tecnológico. Es probable que ya hayas oído hablar de Gordon Moore, cofundador de Intel. En 1965, Moore escribió un artículo con el ingenioso título de “Cramming More Components onto Integrated Circuits”. Lo que ahora se conoce como “ley de Moore” es la conclusión de ese artículo: que la cantidad de transistores en un chip se duplicaría cada dos años. Esto es crecimiento exponencial. Ah, y también que el precio de esa mayor capacidad de computación se reduciría a la mitad en el mismo lapso. No podemos percibir siquiera la rapidez del cambio. Hacerse a la idea de lo que vendrá después se ha vuelto imposible. Permíteme compartir contigo un antiguo acertijo francés para niños que ilustra la velocidad de los acontecimientos actuales. Imagina que ves un hermoso lago con lirios, quizás el de Giverny que docenas de cuadros de Monet volvieron famoso. El agua está quieta, los lirios flotan en la superficie, a la distancia se distingue un pequeño puente y el cielo y los árboles enmarcan el lago, el cual pintan con sus reflejos. Resulta que el número de lirios en ese lago se duplica cada día. Dentro de un mes, cubrirán por completo la superficie y el lago se colmará de pétalos. Éstos sofocarán todas las demás formas de vida: peces, ranas e incluso otros lirios. Pese a ello, aún hay tiempo para salvar el lago, ¿no es así? Después de todo, los lirios son encantadores. Si decides no intervenir hasta que ellos cubran la mitad del lago, ¿cuántos días tendrás para salvarlo? Uno. Un día y nada más. El día veintinueve, los lirios cubrirán la mitad del lago. Al día siguiente ocultarán todo. Déjame darte otro ejemplo: el ritmo de la duplicación de transistores y la potencia que esto genera. Usemos para ello el famoso caso de los granos de trigo sobre un tablero de ajedrez, el cual data de 1256 (lo que te da una idea del larguísimo tiempo que la gente ha dedicado a pensar en esto). Si pones un grano de trigo en un cuadro de un tablero de ajedrez y
Scrum_Manual de campo_2R.indd 13
2/4/20 16:55
14
Scrum: manual de campo
en cada cuadro sucesivo duplicas el número de granos, cuando llegues al último cuadro habrás duplicado esa cifra sesenta y tres veces. Este cuadro tendrá 9 trillones de granos de trigo (9,223,372,036,854,775,808 para ser exactos). Esta cantidad es inmensa, incomprensible, insondable. Tal es el ritmo del cambio que atravesamos. Las antiguas maneras de trabajar se vienen abajo frente a problemas tan variables que rebasan su capacidad de abordarlos. La complejidad ha dejado de ser una rareza; ahora debemos batallar con ella todos los días.
Qué sucederá después Scrum es un medio para que una persona, equipo u organización sean capaces de responder a esa complejidad, a cambios impredecibles, y desplazarse con diligencia y destreza dentro de un ámbito repleto de problemas en constante cambio. El intenso ritmo de las transformaciones que atravesamos demanda una manera distinta de trabajar. Scrum es una solución a este problema. Pero para obtener de verdad las ventajas de Scrum, los drásticos aumentos de productividad y el valor efectivo que brinda, debe haber un cambio fundamental en la gerencia y las operaciones. Aunque algunos equipos Scrum ofrecen resultados con una celeridad notable, Scrum debe estar presente en el nivel empresarial. Las estructuras tradicionales deben cambiar, los incentivos deben cambiar, la gestión del desempeño debe cambiar y todos en la organización, aun si no pertenecen a equipos Scrum, tienen que aprender a interactuar en una forma nueva con esos equipos, así como a aprovisionarlos, ayudarlos y administrarlos. Una vez que comprenden la magnitud del cambio que les aguarda, los miembros de las organizaciones tradicionales se limitan en ocasiones a cruzarse de brazos. Eso es imposible. Es un salto muy brusco. En las compañías establecidas hay demasiada burocracia, demasiada historia, demasiadas “maneras corporativas de hacer las cosas” No podemos cambiarlo todo, dicen los gerentes; aquí no trabajamos así. Y si las cosas marchan mal, buscan a quién echarle la culpa. No importa quién haya sido el responsable de un éxito o fracaso en una compañía, cómo se gastó el dinero o qué marchó mal. Lo único que importa es ¿qué sucederá más tarde? El pasado es el pasado. Esto se aplica
Scrum_Manual de campo_2R.indd 14
2/4/20 16:55
La decisión frente a nosotros 15
por igual a los negocios, la política y las relaciones. ¿Cómo deseas que sea el futuro? ¿Cómo puedes prepararte para aprovechar cambios que sabes que son indispensables? ¿Qué puedes hacer para incorporar en tu equipo, área y compañía no sólo elasticidad, sino también un sistema que le ayude a ser más fuerte cada vez que enfrente un problema? ¿Cómo erigir un sistema que no sólo logre recuperarse de cada desastre, sino que además crezca, aprenda y aumente su capacidad? Las mejores organizaciones aprenden de sus errores y éxitos y usan sistemáticamente estas lecciones para mejorar. Como acostumbro decirles a mis equipos cuando me presentan algo que falló: “¡Magnífico! Ahora sabemos que esto no surte efecto. Tráiganme un error más interesante para la próxima vez”. Lo que necesitas es lo que yo llamo una empresa del Renacimiento: sin los grilletes del pasado ni formas antiguas de ver el mundo y capaz de crear cosas que hace apenas unos años eran inimaginables. Requerimos una ley de Moore para la gente. ¿Cómo podemos ser más rápidos, eficientes y productivos? ¿Cómo podemos lograrlo a gran escala?
Un mundo de Lego Acompáñame al norte de Europa, a Suecia, la sede de Ikea, La chica del dragón tatuado, la banda pop abba, las que son quizá las mejores albóndigas del mundo y el sol de medianoche. Ese país es también la sede de Saab. Probablemente identifiques a esta compañía como una fábrica de automóviles que ya no produce automóviles, pero la verdad es que éstos siempre representaron para ella una actividad suplementaria. A lo que realmente se dedica es a hacer aviones de combate. ¿Quién iba a decirlo? Saab ha fabricado aviones de combate durante décadas, desde 1937. Esto era obvio cuando el mundo estaba a punto de iniciar una conflagración global, y Suecia, que no estaba alineada con ningún bando o nación, decidió establecer su fuerza aérea. Ese país ha tenido una política de neutralidad, similar a la de Suiza, desde fines de la era napoleónica, y la mantuvo oficialmente durante la Segunda Guerra Mundial y la Guerra Fría. Pero con la otan de un lado y la urss del otro, nuestros buenos amigos del País Alargado se hallaban sin duda alguna en una situación estresante.
Scrum_Manual de campo_2R.indd 15
2/4/20 16:55
16
Scrum: manual de campo
Así pues, instauraron una fuerza aérea. En 1950 introdujeron el avión Saab 29 Tunnan, entonces a la par de los mejores del mundo. Integraron cincuenta y cinco escuadrones, muchos de los cuales mantenían en alerta y podían ser lanzados en sesenta segundos. Y empezaron a vender aeroplanos a otros países como Austria, Brasil, Sudáfrica y Tailandia. Después del Tunnan vinieron el Lansen, el Draken y, en la década de 1980, el Gripen A/B, seguido por el C/D. Entonces se presentó un problema. Aunque el Gripen era un buen avión y se vendía muy bien, Saab y el ejército sueco deseaban modernizarlo, volverlo más potente y dotarlo de mayor autonomía y mejores armas. Fue así como surgió la idea del Gripen E. Al principio, los ingenieros de esa compañía se propusieron modernizar nada más sesenta Gripen 39C ya existentes, porque las aeronaves son caras y difíciles de fabricar. Al final, mientras las mejoraban, su equipo de software adoptó Scrum, que pronto se extendió a diseño, ingeniería y control de calidad: a todos los departamentos. Scrum@Scale es un marco organizacional modular con equipos interfuncionales que aportan valor rápidamente. Al tiempo que ese marco se difundía en Saab, los líderes de esta corporación tuvieron una idea radical: ¿qué ocurriría si la aeronave fuera reflejo de la estructura organizacional de la empresa? “Queremos un avión que vuele cincuenta años”, señaló Saab. “Sabemos que la tecnología cambiará por completo en las décadas siguientes. Nuestros diseños actuales son difíciles de actualizar. Su montaje es inalterable. Cada pieza está fuertemente entramada con las demás. ¿Qué sucedería si fabricáramos un avión modular que se desarme y rearme con la misma facilidad que los equipos Scrum de una organización? Mejoraríamos sistemas enteros de un momento a otro. No tendríamos que esperar a que haya lugar un programa de modernización para hacerlo. ¿Por qué no hacer las cosas de tal modo que si aparece un nuevo radar, computadora o motor podamos quitar el antiguo y poner el nuevo sin tocar el resto de la nave? ¿Y si produjéramos un avión de combate como si estuviera hecho de piezas de Lego?” “Deseamos que sea un sistema de enchufar y usar”, dijo Jorgen Furuh jelm, de Saab. “Llamémoslo un avión de combate inteligente. No sabemos lo que nuestros clientes querrán dentro de unos años.” ¿Es preciso desarrollar un mejor motor? No hay problema; cámbialo por el antiguo. ¿Un radar mejor? Hecho. ¿Armas más ligeras? Listo. La filosofía de Saab permite que el Gripen haga cosas que parecerían im-
Scrum_Manual de campo_2R.indd 16
2/4/20 16:55
La decisión frente a nosotros 17
posibles. Puede aterrizar sobre un camino en condiciones climáticas extremas. Puede ser reabastecido de combustible y rearmado en menos de diez minutos, por seis personas sin herramientas especiales. Casi todos los demás aviones de su clase requieren el doble o triple de tiempo. Saab puede cambiar un motor en una hora. Eso es lo que la modularidad hace por ti. Además, trabajar en esa compañía es divertido. Así lo juzgan los estudiantes suecos de ingeniería, quienes conceden sólo a Google una calificación más alta que a Saab. Y a diferencia de casi cualquier otro centro de trabajo en el mundo, cuyos empleados preferirían no ir a la oficina, a los de Saab les agrada presentarse a trabajar todos los días. “Es cuestión de compromiso. Nuestra gente está convencida de que nuestro proyecto es fantástico, realmente increíble. Le entusiasman los aviones. La sensación de compromiso de los equipos es casi palpable”, dice Furuhjelm. Éste es el poder de Scrum. Libera a la gente para que trabaje más rápida y productivamente y haga más en menos tiempo. Permite que los equipos realicen su tarea con pasión y sin impedimentos. Cuando Saab adoptó Scrum, descubrió que sólo quitar cosas del camino de la gente da rienda suelta un grado asombroso de potencial humano. Pese a que el Gripen E es mejor, con mejores partes y equipo —y casi todo lo demás— que su predecesor, es más económico de desarrollar, fabricar y operar. Mantener en el aire ciento cincuenta Gripens durante cuarenta años te costaría 22 mil millones de dólares, la mitad de lo que representaría mantener sesenta y cinco F35 de factura estadunidense. Saab lo logró con Scrum. Fabricó desde cero un avión de combate avanzado. Yo he trabajado en numerosas ocasiones con compañías cuyos gerentes me dicen: El marco de Scrum está diseñado para hacer software. Lo que nosotros hacemos es demasiado complejo para adecuarlo al sistema Agile. Entonces les hablo del Gripen. “Puedo asegurarles que, produzcan lo que produzcan, no es más complicado que un avión de combate”.
Scrum_Manual de campo_2R.indd 17
2/4/20 16:55
18
Scrum: manual de campo
No estoy seguro de que esa palabra signifique lo que crees Scrum se ha propagado en los últimos años, frecuentemente bajo la bandera de Agile. Ya no es únicamente la forma en la que trabajan las empresas de software y tecnología; grandes compañías de casi cualquier área lo aplican de modo creciente. Organizaciones especializadas en banca, automóviles, instrumental médico, biotecnología, seguros, salud y otros ramos han recurrido a Agile para mantener su relevancia. Compañías líderes como Bosch, Coca-Cola, usaa, Schlumberger, Fidelity y Lockheed Martin han echado mano de Scrum para rendir valor y calidad con la rapidez que sus clientes requieren hoy en día. Gran parte de esto ha sido impulsado por lo que suele llamarse las transformaciones digitales. La idea es que los viejos tiempos en que se distinguía entre negocios y tecnología de información se han ido para siempre. Actualmente todas las organizaciones son compañías tecnológicas. Además, el software ha devorado al mundo. Tu coche tiene más líneas de código que Windows. ¡Vaya!, mi lavadora nueva me exige la contraseña de Wi-Fi. Hoy las compañías —incitadas con frecuencia por su director general, una ted Talk o colegas o consultores que les hablan de los beneficios de la agilidad— deciden volverse ágiles a como dé lugar. Juzgo oportuno definir el término ágil y el modo en que Scrum se relaciona con él. Scrum se inventó en 1993 y fue formalizado por sus cocreadores, Jeff Sutherland y Ken Schwaber, en 1995. A mediados de esa década, en grupos de Usenet y conferencias, numerosas personas buscaban formas de desarrollar software sin el terrible índice de errores que era cada vez más común. En 2001, diecisiete de esas personas se reunieron un par de días en una estación de esquí en Snowbird, Utah. Mi padre, Jeff Sutherland, era una de ellas, al igual que Ken Schwaber y un inmediato adepto de Scrum, Mike Beedle. Las otras catorce tenían distintos antecedentes y metodologías, pero intentaban abordar los mismos problemas en formas similares, si no es que idénticas. El primer día lo dedicaron a discutir, tal como me lo contaron varios de los presentes. Hablaron sobre todo de cómo bautizarían ese concepto tan amplio que sabían que estaba ahí, pero que carecía de nombre. Casi
Scrum_Manual de campo_2R.indd 18
2/4/20 16:55
La decisión frente a nosotros 19
al final de la jornada, Mike Beedle sugirió el nombre Agile. Todos lo estimaron más fácil de vender que otros contendientes, como “Peso ligero”. Así pues, decidieron llamarlo Agile y se pusieron a debatir sobre su significado. Al día siguiente discutieron otro poco. Estaba bien, era Agile, pero ¿qué quería decir eso? ¿Cómo podía describírsele? Nueve de los presentes hicieron una pausa para fumar mientras los otros ocho permanecían en la sala. Uno de ellos, Martin Fowler, se acercó al pizarrón blanco y dijo algo como esto: ¿No sería vergonzoso que no pudiéramos llegar a un acuerdo en estos dos días? En los quince minutos siguientes, las ocho personas en la sala produjeron esto: Buscamos mejores formas de desarrollar software en la práctica, y de ayudar a otros a hacerlo. Esta tarea nos ha llevado a valorar: Los individuos y las interacciones sobre los procesos y las herramientas El software funcional sobre la documentación exhaustiva La colaboración con el cliente sobre la negociación del contrato La respuesta al cambio sobre el cumplimiento de un plan Aunque hay valor en los factores de la derecha, valoramos más los de la izquierda. Quince minutos después, cuando los otros nueve participantes regresaron a la sala, uno de ellos, Ward Cunningham —inventor del wiki, entre otras cosas— dijo: “¡Eso es impresionante!”. No cambiaron una sola palabra. Así que esto es Agile: una declaración de valores. Los integrantes de ese grupo dedicaron el resto del día a elaborar doce principios, como “La sencillez —el arte de maximizar el volumen de trabajo que no se hace— es esencial”, “Organizar los proyectos alrededor de individuos motivados; darles el entorno y apoyo que necesitan y confiar en que cumplirán con su labor”, y “La atención continua a la excelencia técnica y un buen diseño favorece la agilidad”. A pesar de que todas estas cosas son grandiosas, en ninguna de ellas se indica cómo alcanzarlas. No había ningún mar-
Scrum_Manual de campo_2R.indd 19
2/4/20 16:55
20
Scrum: manual de campo
co ni metodología, sólo cuatro valores y magníficos principios de sentido común. Esto cambió el mundo. El Manifiesto Agile se subió a un sitio web, agilemanifesto.org, y los participantes en aquella reunión volvieron a casa, donde continuaron la ardua tarea de volver realidad todo eso. Ignoraban la influencia que sus ideas ejercerían mucho más allá del mundo del software. Debo advertirte, sin embargo, que cuando alguien dice que ha adoptado el método Agile es muy importante que le preguntes qué entiende por eso. Scrum es, con mucho, la forma más popular de aplicar ese concepto; setenta por ciento de los equipos Agile usan Scrum. Agile no es en absoluto el único medio para hacerlo, pero afirmar que una compañía es ágil no revela gran cosa.
Ley de Moore para la gente Si nunca habías oído hablar de Scrum o si ya lo conocías, pero aún no estás seguro de en qué puede servirle a tu empresa, permite que te exponga una rápida lección de historia sobre su origen y qué se propone. Desde fines de la década de 1980, la gente de Silicon Valley se interesó en el efecto que la ley de Moore tendría en el rápido crecimiento de la tecnología. Cuando las máquinas fueron capaces de hacer más, los proyectos de software se volvieron más complejos, y su fracaso más común, lo que implicaba desperdiciar gran cantidad de tiempo, energía, productividad y sueños. Piensa por ejemplo en el proyecto Taurus, que la Bolsa de Valores de Londres lanzó en esos años. Taurus es el acrónimo de Transfer and Automated Registration of Uncertified Stock. El problema era que el sistema de liquidaciones de esa Bolsa empleaba el sistema Talisman. “Liquidaciones” es una manera elegante de decir “recibir aquello por lo que pagaste”. Así, una vez que alguien compraba una acción, su transferencia a la respectiva cartera tardaba de dos a tres semanas, y suponía trasladar de un lugar a otro el certificado impreso alusivo. El sistema de intercambio, la compraventa de certificados, se llamaba Seaq. Era electrónico, pero no podía enlazarse con el sistema Talisman, muy anterior a él.
Scrum_Manual de campo_2R.indd 20
2/4/20 16:55
La decisión frente a nosotros 21
Taurus debía remediar eso. Era un sistema electrónico de liquidaciones que reemplazaría al antiguo procedimiento impreso y se enlazaría con sistemas de pagos internacionales para permitir la operación con valores extranjeros. Sería imponente. No obstante, los operadores individuales necesitaban una cosa y los mayoristas otra. De igual modo, casi todos los operadores querían que Taurus se enlazara con sus sistemas hechos a la medida, no que los reemplazara. En consecuencia, no dejaban de añadirse requisitos a este programa. Sería impresionante de todos modos. Se integraría con diecisiete sistemas más. ¡Increíble! Pero según Hamish McRae, en un artículo publicado en el Independent el 12 de marzo de 1993, el problema era triple. Primero, producir desde cero grandes sistemas de software y lanzarlos en una suerte de Big Bang era demasiado riesgoso. No podría haber la menor falla ni error; la equivocación más insignificante sería catastrófica. Pese a ello, ese método era común en aquellos días, y lo sigue siendo ahora, en ocasiones. Las compañías apuestan en grande a que un sistema gigantesco lo resuelva todo desde el primer momento. De acuerdo con datos del Standish Group, 40 por ciento de los proyectos de este tipo son un absoluto fracaso.2 La mitad de ellos se atrasa, excede el presupuesto y no cumple las expectativas. Esto era más que factible en el caso de Taurus, sistema que reemplazaría por completo el sistema de liquidaciones de una de las principales sedes globales de las finanzas. En segundo término, señaló McRae, aunque era importante tener un sistema funcional, un buen sistema funcional es mil veces preferible a uno perfecto pero disfuncional. Jamás permitas que lo perfecto sea enemigo de lo bueno. Como en casi cualquier otro caso en cualquier sitio, la “corrupción del alcance” fue el principio del fin del proyecto Taurus. ¿No sería maravilloso que este nuevo sistema hiciera no sólo todo lo que ya pensamos y pedimos, sino también esta otra cosa? Y que preparara espressos perfectos mientras esperamos a que se ejecute una operación sería más impresionante todavía, y así sucesivamente. Al final, un proyecto simple y bien definido pasa a ser un dispositivo complicadísimo que debe hacerlo todo para todos y que ni siquiera es capaz de ejecutar lo más sencillo que sus diseñadores querían. Veo esto todo el tiempo en relación con un sistema institucional general: el sap. Este programa es el líder del mercado en sistemas de planeación de recursos para la empresa (enterprise resource planning, erp).
Scrum_Manual de campo_2R.indd 21
2/4/20 16:55
22
Scrum: manual de campo
Se supone que los sistemas erp lo hacen todo. Son bases de datos inmensas que rastrean recursos como efectivo, materias primas o capacidad de producción y los asocian con nómina, facturas, pedidos, etcétera. Así, un sistema erp toca todas las áreas de una compañía —compras, ventas, recursos humanos, contabilidad, producción, casi todo— y las integra digitalmente. Y en efecto, es muy bueno para eso, si se utiliza la versión estándar. El problema aparece cuando, como en Taurus, la gente se emociona con su solución mágica para todo: integrar cada sistema, enlazar con las viejas macrocomputadoras alojadas en el sótano, manejar la computación en la nube, unir los retazos de sistemas que los diversos departamentos improvisaron (¡o reemplazarlos todos por algo mejor!). Así es como se inicia la corrupción del alcance. Hagamos que esto se comunique con el sistema que hemos usado treinta años. O Que incluya todas las funciones del producto que compramos hace dos décadas y ya no dispone de soporte. La lista es interminable. Tan sólo en los seis últimos meses trabajé con tres corporaciones globales que llevan más de una década tratando de implementar el sap. En una compañía global de bebidas —uno de cuyos productos es probable que hayas consumido hoy—, después de que hablé de simplificar las cosas, un ingeniero se me acercó y me dijo en voz baja: “Hemos gastado más de mil millones de dólares en esto y todavía no funciona”. En otra corporación, con miles de empleados que laboran en una de las áreas más remotas del planeta, me dijeron que mil millones era poco; ellos habían gastado mil quinientos en el sap y aún no servía. No te deprimiré con el tercer ejemplo; créeme, es espantoso. Los tres tenían algo en común: pese a aquellos millones de dólares y millares de personas, el sistema no funcionaba. Aun así, seguían arrojando al problema cientos de millones al año: hacían las cosas de la misma manera y esperaban resultados diferentes. Pero volvamos a Taurus, esa perfecta joya de los sistemas de liquidaciones, y a esos pobres sujetos con la tarea, digna de Sísifo, de integrar diecisiete propuestas de cómo debía operar el sistema. Tenía que ser todo para todos. De verdad lo intentaron. En cuanto al último problema de Taurus, citaré aquí sólo un párrafo de McRae:
Scrum_Manual de campo_2R.indd 22
2/4/20 16:55
La decisión frente a nosotros 23
La Bolsa no ha escuchado a sus clientes. Los hay de muchos tipos: compañías afiliadas, compañías cuyas acciones comercializa, inversionistas institucionales, inversionistas personales. A las compañías afiliadas les preocupaban los costos de Taurus, las otras empresas estaban insatisfechas (y algunas se habían negado a ayudar), las instituciones mostraban indiferencia en el mejor de los casos y hostilidad en el peor, y a los pequeños inversionistas les inquietaban los cargos adicionales que tendrían que pagar. Insistir en algo de cara a una resistencia de esta índole conlleva una arrogancia particular. “Una arrogancia particular”: es la del experto, del profesional, del burócrata, del proceso sobre las personas, de conceder más valor a las intrincadas descripciones de las cosas funcionales que a las cosas mismas. La insistencia egoísta en un enredoso plan en el que se habían involucrado muchas mentes y corazones superó la prudente idea de que las cosas podían cambiar, y de que por tanto era razonable hacer un plan. Habiendo nacido como una idea atractiva, Taurus se canceló en 1993, luego de varios años de esfuerzo, el arduo trabajo diurno e incluso nocturno de miles de personas y una inversión de 75 millones de libras esterlinas. El costo total para los interesados se calculó en 400 millones de libras. Eso es mucho dinero. Pero fueron también mucho tiempo y vidas desperdiciados. Un gran grupo de personas muy inteligentes dedicaron varios años a crear algo que acabó por ser sinónimo de desastre tecnológico. Y aunque me agradaría decir que Taurus es el peor ejemplo que puedo darte, no es así. Muchos otros le disputan ese título. El proyecto Connec ting for Health del National Health System, para generar en el Reino Unido expedientes médicos electrónicos, derivó en nueve años perdidos, con un costo de 12 mil millones de libras. El Expeditionary Combat Support System del ejército estadunidense resultó a su vez en siete años perdidos, con un costo de 1,100 millones de dólares. El California Department of Motor Vehicles gastó 10 millones desde 1987 en el establecimiento de un sistema que para 1990 era peor que aquel al que reemplazaría, pese a lo cual no se le abandonó hasta 1994. El San Francisco Chronicle lo describió como “un sistema impracticable, que no podrá repararse sin el gasto de varios millones más”.
Scrum_Manual de campo_2R.indd 23
2/4/20 16:55
24
Scrum: manual de campo
Las máquinas se volvieron más capaces y veloces, pero los seres humanos no teníamos nada que mostrar a cambio: éste fue el contexto en el que mi padre se desempeñaba a principios de la década de 1990. Si quieres conocer toda la historia de lo que ocurrió, lee Scrum: el arte de hacer el doble de trabajo en la mitad de tiempo, pero en pocas palabras él dio con una nueva manera de trabajar. Su principal revelación fue que los fracasos de ese tipo no se debían a las personas involucradas. Los gerentes, ingenieros y diseñadores de esos grandes proyectos fallidos no eran malas personas, ni personas tontas que se hayan propuesto fracasar. Comenzaron con grandes sueños y la meta de hacer una diferencia, de transformar el modo en que el mundo hacía las cosas. No fallaron las personas, erró el sistema y la forma en que trabajaban, su manera de pensar en lo sucedido cuando se reunían a hablar de sus esfuerzos y a planearlos. Ésa era para ellas la manera como las cosas se hacían. Trabajar de cualquier otro modo equivalía a que un pez cuestionara su necesidad imperiosa de vivir en el agua.
Una guía de sobrevivencia Los individuos cuyo empleo está en peligro a causa de la automatización no son distintos a las corporaciones cuya razón de ser se halla bajo constante amenaza. Sea que tomes decisiones personales sobre tu trabajo, planees las metas estratégicas de una gran multinacional o decidas cómo se adaptará una cultura a una nueva serie de circunstancias con un juego de axiomas diferente, tu rápida capacidad de adaptación determinará tu éxito. Como mi padre y yo escribimos en nuestro libro anterior: el cambio es cuestión de vida o muerte. En este libro te daré más herramientas. Te llevaré por todo el mundo, y desde el espacio exterior hasta los centros de atención telefónica, de tecnologías radicalmente nuevas a un restaurante. Pese a que las tendencias sean intimidatorias, estoy convencido de que podemos aceptar el cambio y ser más flexibles y menos aprensivos, capaces de más cosas, con el objeto de que dejemos de quejarnos de lo que ya no podemos hacer y actuemos con un propósito global en vez de que nos sintamos atrapados por las fuerzas que ejercen influencia a nuestro alrededor.
Scrum_Manual de campo_2R.indd 24
2/4/20 16:55