Leo en las noticias de la CNBC que Elon Musk achaca a una expectativas injustificadas de la línea de producción parte del retraso en la entrega de vehículos. «Los seres humanos están infravalorados y a veces son superiores a los robots», afirma en un gesto de rectificación que forma parte de las medidas que está tomando para resolver los problemas de Tesla Motors. Tanta confianza tiene en esas medidas que ya ha anunciado que la empresa tendrá beneficios a finales de este mismo año.
A partir de este punto, este artículo podría ser una reflexión sobre buenas prácticas de gestión, de cómo Musk ha cogido el toro por los cuernos y ha respondido a todos los que afirman que Tesla Motors está a dos pasos del cementerio, señalando su déficit de liquidez y unos beneficios que nunca llegan. Pero quiero centrarme en el mismo gesto de rectificación de Musk, el reconocimiento de que una expectativa excesiva en los beneficios de la robotización no ha dado los resultados que esperaba. Este detalle, reconocer un error de resultados sobre la adopción de una práctica concreta, es algo que brilla por su ausencia en el mundo de la consultoría de gestión en nuestros días.
Creo que sabrás a qué me refiero si te pregunto cuántas veces has escuchado la excusa de que «no es que (pon la metodología ágil que quieras) funcione mal, es que no lo habéis sabido implementar». Parece casi impensable que nadie asuma la responsabilidad por implantar un método o técnica que no termina dando los resultados esperados. A cambio, escuchamos una y otra vez ataques virulentos contra prácticas establecidas y perfectamente funcionales como el análisis del camino crítico. Todo lo que «huela» a planificación es malo y todo lo que lleve el apéndice «Lean» o «Agile» es bueno, independientemente de los resultados.
Si dejásemos de lado los prejuicios y analizásemos los resultados de forma objetiva, cualquier metodología tan susceptible de errores en su implantación quizás no es tan buena ni tan metodológica. Pero existe una especie de alergia a reconocer un error en la actualidad, que nos mete en lo que yo llamo «el ciclo de la expectativa desmedida».
Tomemos el caso de XP. Extreme Programming fue una propuesta de Ken Beck para el desarrollo de una aplicación interna de gestión de nóminas en Chrisler, denominada C3 o Chrysler Comprehensive Compensation System. Cuando Beck tomó las riendas del proyecto, éste ya llevaba en funcionamiento unos tres años, pero no se había conseguido emitir ni un sólo cheque de nóminas. Beck introdujo una serie de prácticas que terminaron cristalizando en torno al concepto de «Extreme Programming», llevar al extremo las buenas prácticas de programación. ¿Revisar es bueno? Entonces revisemos todo el tiempo y pongamos a la gente a programar por parejas, para que uno supervise al otro. La idea suena bien e inicialmente se consiguieron algunos avances, hasta el punto de que Beck consiguió entregar una versión funcional del software con sólo dos meses de retraso sobre el plan inicial.
Entusiasmado por la acogida que tuvo su propuesto y los primeros resultados, Beck publicó un libro en el que recogía sus ideas (Extreme Programming Explained) y se lanzó a una carrera como conferenciante y consultor de gestión de proyectos que le hizo famoso y millonario. Ante la perspectiva de poder abandonar las eternas fases de planificación y entregarse a la programación práctica, muchos vieron una vía para abandonar los métodos en cascada tradicionales, refrendados por la decisión de una gran empresa como Chrysler, que se tildaba de innovadora y arriesgada en su búsqueda de competitividad. Una digna heredera de Toyota y las innovaciones de Taiichi Ohno.
Lo que no se dijo con tanto entusiasmo es que al poco tiempo de entregar esa primera versión la representante del cliente (lo que hoy llamamos Product Owner en Scrum) abandonó por agotamiento y depresión y fue imposible sustituirla. Tras gestionar poco más de 10.000 nóminas y con graves problemas de eficiencia, el sistema se fue abandonando y Chrysler retiró el apoyo a la utilización de XP en sus proyectos internos. Pero para ese momento la marea de XP ya era imparable. Era lo que podemos llamar una propuesta «hiperhyped». Dos años después de la publicación del libro aparece el Manifiesto Agil y todo el mundo abraza con entusiasmo el concepto Agil. Se entierra una y otra vez la gestión en cascada y surgen iniciativas como la Scrum Alliance para divulgar e implantar el agilismo en todas sus diversas formas y colores.
Desde entonces todas las encuestas y estudios muestran un continuo declive de XP en todos los ámbitos. VersionOne, en su 10th Annual State of Agile Report, recogía ya hace un par de años que la presencia de XP era irrelevante, rozando el 1%. En poco más de 15 años hemos pasado del estusiasmo desmedido a la casi desaparición total de una metodología que, en su día, se presentaba como sustituta obligatoria del PMBoK u otras prácticas convencionales en el ámbito del desarrollo de software.
De ninguna forma pretendo decir que esta historia confirme que los métodos ágiles son un fracaso. Muy al contrario, soy un gran defensor de esta aproximación, pero siempre que se haga con prudencia y contrastando las expectativas con los resultados. El motivo por el que XP subió como la espuma es que satisfacía algunas reivindicaciones de los programadores, al ser un método esencialmente de producción (no de organización o gestión), no porque fuera rentable o eficaz. Lo primero, la satisfacción, es emocional; lo segundo, la rentabilidad, es analítico. ¿Dónde están los estudios académicos o informes que refrenden la rentabilidad de implantar esta u otra técnica? Hasta Martin Fowller, a quien no se puede tachar de conservador recalcitrante, reconocía en su blog que no había visto ningún análisis basado en hechos sobre el auge y caída de XP en Chrisler.
El ciclo de la hiper-expectativa emocional nos lleva por un camino que crea expertos en consultoría en pocas horas, pero que no garantiza resultados a largo plazo. Recordemos que una de las críticas que se ha hecho a Scrum y su proceso de certificación es que coloca en el mercado técnicos con el título de Scrum Master con poco más de un par de días de formación y ninguna experiencia práctica en su aplicación. La Scrum Alliance es una fábrica de vender certificaciones y cursos, pero no de consolidar empresas capaces de realizar su trabajo.
Sea cual sea nuestra actitud hacia el PMI, hay que reconocerle el mérito de actualizar y rectificar continuamente sus propuestas en base a estudios empíricos. No sólo publica revisiones de su guía de prácticas recomendadas cada cuatro años, más o menos, sino que mantiene una revista académica en la que se divulgan estudios objetivos sobre resultados en la implantación de gestiones. ¿Cuándo hemos visto algo similar en el mundo ágil? La Scrum Alliance no ha variado el contenido de sus propuestas en casi dos décadas y casi te queman en la hoguera si se te ocurre decir que «a lo mejor» habría que hacer caso a las numerosas iniciativas que intentan implantar un Sprint Zero para inicializar proyectos.
El agilismo, la actitud de afrontar el riesgo en los proyectos de gran incertidumbre y proponer técnicas que sirvan para resolverlo, es una gran idea y debemos seguir enriqueciendo nuestra experiencia y conocimientos de estas propuestas. Pero esa línea de trabajo debe afrontarse con prudencia y apoyada en resultados que ratifiquen las expectativas. De lo contrario nos convertimos en fanáticos subidos en la cresta de la ola de cada moda sucesiva, que sólo dan beneficios a los que venden consultoría y formación. Y eso es algo que va en contra de nuestros intereses a largo plazo, porque aunque puntualmente podamos vender cursos y horas al precio que queramos, si la empresa no ve compensada su confianza en resultados, puede que no nos crean la próxima vez.
No sé qué pasará con Tesla. Elon Musk ha intentado afrontar la situación con algo más que retórica y ha hecho público un análisis de la situación en el que reconoce problemas de producción y propone soluciones para alcanzar beneficios en este mismo ejercicio. No voy a negar que es un hombre que apoya su gestión en el marketing efectista, pero también hay que reconocerle el mérito de reconocer fallos en base a resultados y hacerlo antes de la quiebra de su empresa.