La fascinante historia de Lean y Agile y la sinergia con el coaching

De Domingo Valhondo

Domingo Valhondo es coach Internacional certificado por International Coaching Community, dedicado al coaching ejecutivo y de equipos. Colaborador habitual de Instituto Ben Pensante. Fue Responsable de lean y coaching en Repsol. www.domingovalhondo.com

 

¿Qué es Lean, qué es Agile, cuando aparecieron y qué tienen que ver con el Coaching?

Este artículo se propone responder la pregunta.

Lean y especialmente cuando se le añade el apellido de manufacturing nos evoca algo prosaico; fabricación, productividad, reducción de precios y, quizás, calidad. Nos evoca también a Toyota -como la empresa que lo desarrolló-.

Durante muchos años, Lean fue cosa de japoneses, tan ceremoniosos, tan tradicionales y con extrañas costumbres como la de hacer ejercicios gimnásticos antes de empezar la jornada de trabajo, con un sentido de vinculación con la empresa que en Occidente nos parecía (y sigue pareciendo) incomprensible.

Sin embargo, no todos pensaban así. Por razones históricas que veremos más adelante, el MIT (Massachusetts Institute of Technology) encargó un estudio a un equipo liderado por James T. Womack para entender lo que estaba haciendo Toyota. El resultado se plasmó en el libro titulado “La Máquina que cambió el mundo”, publicado en 1991, que describía el TPS (Toyota Production System).

Así nació el mito de Lean, término acuñado por Womack que, literalmente significa, magro, sin grasa (es decir, sin desperdicios), apropiándose del concepto y situando Lean o Lean Management en el mapa de la industria de los Estados Unidos.

El propio James T. Womack, reconocido como el gran valedor y divulgador de Lean, escribió en 1996 otro libro fundamental titulado Lean Thinking, que profundizó en la esencia cultural del TPS, elevando la metodología o el sistema de gestión Lean a otra dimensión: “una forma de pensar”, de entender el mundo de la empresa, dejando atrás la ramplona percepción de cadena de producción de bienes tangibles, que seguía siendo para muchos.

Agile (ágil), mucho más joven, nació con mejor imagen, sonando a algo moderno, a flexibilidad, a software, a tecnología, aunque -nadie es perfecto- vinculado a un entorno de informáticos, un tanto “frikis”, enfrentados a los colegas “antiguos”, que se aferraban a un modelo obsoleto de producción de software “en cascada”.

El caso es que el término se ha extendido en el mundo empresarial a gran velocidad pues no olvidemos que el manifiesto agile que es como la puesta de largo del nuevo paradigma, que veremos más adelante, tiene poco más de 20 años. Poco tiempo para un despliegue tan universal como el que actualmente ha alcanzado.

Y, además, el Coaching, que es el tercer invitado de este artículo, por acompañar tanto a Lean como a Agile de una forma sorprendentemente exitosa.

Como este artículo está escrito para el blog del Instituto Ben Pensante, podemos ahorrarnos detalles sobre el Coaching.

Si acaso destacar que es la disciplina que despliega todo el talento humano, resultado de diversas aportaciones metodológicas de investigadores que han ido construyendo modelos sólidos para que las personas que reciben el coaching, a nivel individual o en equipo, logren lo que viene a llamarse su mejor versión.

En definitiva, el Coaching es el gran revulsivo para lograr la excelencia humana, por logra el máximo potencial de procesos excelentes como Lean o Agile.

Y ahora podemos preguntarnos ¿Qué tienen en común estas tres disciplinas que son Lean, Agile y el Coaching? o reformulando la pregunta ¿Qué tienen Lean y Agile para que el Coaching se amolde a ambos de forma tan armoniosa?

Vamos a tratar de descubrirlo.

Lean Manufacturing, Lean Management, Lean Thinking

¿Qué es Lean? Una definición concisa de Womack es “La idea central es maximizar el valor para el cliente minimizando el desperdicio. Simplemente, Lean significa crear más valor para los clientes con menos recursos”.

No está mal, aunque en principio no apasiona. De modo que para entender mejor qué es Lean vamos a retroceder en el tiempo, brevemente.

Una familia japonesa, los Toyoda (sic), que había tenido un éxito importante fabricando telares, decidió dar el salto a la fabricación de automóviles, hacia 1933. Sakichi Toyoda, creador de Toyota Motor, viajó a los Estados Unidos y visitó las fábricas de Ford.

Sakichi se dio cuenta enseguida de que Toyota no podía competir con las empresas norteamericanas que contaban con un mercado inmenso y con grandes inversiones, dando lugar a una producción en serie a gran escala y a bajo coste en términos unitarios.

En tanto que Toyota solo producía pequeñas cantidades de vehículos, porque el mercado japonés era raquítico, sus finanzas eran igualmente escasas y, según calculó Sakichi, la productividad de Ford con respecto a Toyota era de una proporción de 9:1.

¿Era posible cambiar esta situación? Fue un reto descomunal.

Sakichi se planteó aprender las técnicas norteamericanas, sin copiarlas tal cual, sino adaptándolas a la situación de Japón, llevando a cabos sus propias “investigaciones y su creatividad”.

Pues bien, casi en silencio, la compañía desarrolló el TPS (Toyota Production System) que pocas décadas después alcanzó un nivel de competitividad imparable, no solo exportando al mercado norteamericano, sino instalando fábricas en USA.

Y saltaron las alarmas. El MIT (Massachusetts Institute of Technology) encargó el ya citado estudio a James T. Womack sobre el fenómeno Toyota, cuyo resultado ya conocemos: La Máquina que cambió el mundo.

Quizás es el momento de conocer las claves (o principios) de Lean, que actúan en un ciclo permanente.

Aportar Valor al cliente, estando atentos a lo que dice (La Voz del Cliente, sin duda, la escucha activa). Solo el cliente define qué es el valor.

Identificar el camino ideal, para generar valor, sin desperdicios, haciendo que aquello que se produce va siendo más y más valioso conforme avanza el proceso.

Conseguir el Flujo Continuo a través del camino ideal, sin interrupciones, produciendo elementos “susceptibles de ser entregados al cliente, sin esperar a los demás”. Flujo elemento a elemento vs. grandes lotes.

Producir solo cuando el cliente lo requiere (Pull), reduciendo el gran desperdicio, el inventario.

La mejora continua, sustentada en la base, en las personas, en los equipos Kaizen.

Toyota representa su modelo TPS en un esquema visual denominado la casa Toyota, una suerte de Partenon que, en su versión más simplificada es como sigue:

 

• Objetivos claros, compartidos, con foco en la Calidad
• Procesos brillantes, midiendo el avance y corrigiendo las desviaciones.
• Equipos Kaizen. Respeto a las personas, colaboración, buscando la mejora continua.

No es de extrañar que el coaching se adapte tan bien a Lean. Es lógico; tenemos los 3 grandes ingredientes: Objetivo, Tareas y Relación.

Justificando el título de este apartado. Lean manufacturing, el original, fabricar bienes tangibles.

Lean Management, aplicar Lean a otros ámbitos, no solo a la fábrica.

Lean Thinking, es una manera de pensar, que nos lleva, por ejemplo, a aplicar Lean con increíbles resultados en sectores como el de sanidad. Reflexionado desde la esencia como «¿Quién es el cliente?» o «¿cuál es el producto?» surgen innovaciones asombrosas que aportan valor al usuario y reducen costes innecesarios.

El pensamiento Lean dio con la solución: el cliente es el enfermo, el paciente y, al mismo tiempo, ese paciente es el “producto” que debe mejorar a lo largo del proceso, sin desperdicios. Una genialidad, sin duda.

Agile

El Manifiesto Agile -que veremos en síntesis más adelante-, la gran declaración de los principios y valores de Agile, vio la luz en febrero de 2001, cuando 17 reconocidos expertos del desarrollo de software se reunieron en Utah para debatir y buscar alternativas a los procesos tradicionales de ingeniería de software, cuya rigidez, con una planificación detallada, llevaba  inexorablemente a proyectos que experimentaban grandes retrasos y cuyos resultados estaban muy lejos de resolver las necesidades de los clientes.

Entre aquellos 17 expertos se encontraban representantes de iniciativas como Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal y Pragmatic Programming, que llevaban diez años tratando de zafarse de la camisa de fuerza representada por los desarrollos tradicionales.

El resultado de aquellas reuniones en Utah fue la declaración sobre los métodos ágiles, que representan una mentalidad y un comportamiento guiado por unos valores y principios, más que una metodología. La declaración, conocida como el Manifiesto Agile, cuya repercusión llega hasta hoy.

¿Cómo se llegó a esta situación de choque entre el desarrollo clásico y los métodos ágiles? Para comprenderlo vamos a ir hacia atrás en el tiempo.

En 1943, el ejército de los Estados Unidos firmó un convenio con la Universidad de Pensilvania para construir un ordenador que ayudara a elaborar las tablas de tiro de artillería.

En 1945 se terminó de construir el ENIAC, un monstruo de 27 toneladas que se mantuvo funcionando 10 años.

Un poco después aparecieron dos de los más importantes lenguajes de programación: FORTRAN, en 1957, para cálculo científico y COBOL, en 1959, para aplicaciones de negocio.

Sorprendentemente, COBOL sigue estando presente en grandes corporaciones bancarias y administraciones públicas, aferrado a lo que se llaman sistemas legacy, cual dinosaurios de software que el movimiento Agile no ha sido capaz de desplazar. Si eres bueno en COBOL, tienes trabajo en 2021.

Con FORTRAN y COBOL se inició el boom de la Informática, liderado por IBM con sus mainframes de la mítica serie IBM 360, aparecida en 1964.

Muy pronto se llegó a la crisis del software, básicamente porque el esfuerzo de automatizar los procesos administrativos (y los proyectos militares) daba pobres resultados, previsiones raras veces cumplidas, lo que implicaba costes incontrolables.

Así las cosas, en 1968, la OTAN impulsó la NATO Software Engineering Conferences, reuniendo a los expertos internacionales de computación para definir las mejores prácticas de desarrollo de software basadas en lo que hacía en otras disciplinas.

 

Para resolver los problemas con los proyectos de software se preguntaron ¿Por qué no aplicar métodos de otras disciplinas tales como la Construcción, Arquitectura o Fabricación?

Concluyendo que los proyectos de software pueden desarrollarse como se construye una autopista o un rascacielos.

Copiaron hasta los nombres y así empezó a hablarse de: Arquitecto de Software, Ingeniero de Software e incluso Factoría de Software, equivalente a la industrialización del software. Y listo, empezaron a aplicarlos.

Desde la Conferencia de la OTAN hasta la aparición del Manifiesto Agile pasaron 32 años, con hitos como la aparición del ordenador personal, Internet o nuevos lenguajes de programación cada vez más sofisticados.

La batalla entre dos formas opuestas de entender el desarrollo del software estaba servida.

Por un lado, el clásico mastodóntico desarrollo en cascada, con plazos de años, sin vuelta atrás, con los clientes resignados con unos productos que no eran los que querían y que, además, habían quedado desactualizados por el tiempo transcurrido.

Y, por otro, las nuevas aproximaciones “pre-ágiles”, que segmentan los proyectos en porciones manejables que, una vez terminadas, aportan valor, con flexibilidad, reconduciendo la situación y, lo más importante, escuchando / entendiendo al cliente cada poco tiempo y buscando la excelencia en el trabajo del equipo autónomo.

Modelo en cascada vs. Scrum (Agile)

 

Quizás sea el momento de mencionar los principios del Manifiesto Agile y su correlación con el Coaching:

• Individuos e interacciones sobre procesos y herramientas. Los procesos son como guías para operar y son muy importantes, aunque se quedan en poco o nada sin las personas con las competencias técnicas y las actitudes apropiadas. La propuesta de Agile pasa por que sean los propios equipos autoorganizados los que generen las mejores arquitecturas, requisitos y diseños. El Coaching potencia los equipos precisamente porque los hace conscientes de hasta donde pueden llegar si creen en sus capacidades. El alto rendimiento pasa por esa creencia.

• Software funcionando sobre documentación extensa. Es mejor ver cómo funciona en la práctica la parte que ya has trabajado que no estudiar la documentación de cómo funcionará. Conviene recordar que Agile, hoy en día, trasciende el desarrollo de software y se aplica con éxito en cualquier actividad que implique equipos autónomos y dosis de trabajo intelectual. Todo es cuestión de saber qué es lo que sustituye al software en su actividad.¿Puede el Coaching hacer que el software funcione? ¡Por supuesto! La función del coaching no es programar, ni producir versiones cada vez mejores de un spot comercial, sino lograr el alto rendimiento de ese equipo que sí que sabe programar o es de lo mejor en publicidad. Porque el coaching, ajeno al contenido, llevará a la máxima creación de valor posible, ya sea en modo de software o de cualquier otra forma de entrega de valor. 

• Colaboración con el cliente sobre negociación contractual. Si hablamos de negocios, de empresas, el cliente es el actor principal. Sin su concurso la organización, simplemente dejará de existir. Aportar valor al cliente, para que lo siga siendo, se convierte en el gran objetivo. Agile lo sabe, y sabe también que un contrato, como tal, no aporta valor, sino que es una formalidad que establece límites de responsabilidades. ¿Por qué no considerar al cliente como un miembro más del desarrollo? ¿Quién mejor que el cliente para validar lo que se ha hecho?. La apuesta es tan brillante que, si se aplica bien, convertirá la retroalimentación (feedback) del cliente orienta la producción de valor de forma certera. Sin duda, el Coaching, en el contexto de Agile a través de la figura del Scrum Master, cumple una función esencial en esta alianza con el cliente, en la que la escucha activa, la comunicación eficaz, los acuerdos no documentados, se convierten en el lubricante que hace fluir el sistema.

• Respuesta ante el cambio sobre seguir un plan. A estas alturas Agile ya sí que lo asociamos a agilidad, a capacidad de reacción ante los cambios, un rasgo genuino de Agile desde que renegó del modelo en cascada en el que todo estaba planificado con detalle. Por tanto, Agile se desenvuelve en entornos cambiantes por naturaleza y, los equipos, han de desarrollar la capacidad de dar respuesta a los cambios, de forma ágil, eficaz y eficiente y, si es posible anticiparse a ellos. Todo está muy bien, salvo que en esos entornos de cambios constantes y rápidos surge algo consustancial en los grupos humanos: el conflicto, pues cada persona puede abordar el cambio de forma diferente. Esta es precisamente la oportunidad del Coaching, que asume el conflicto como algo natural, inherente al cambio y, lo más interesante, un factor de evolución del equipo, que saldrá reforzado conforme aprende a resolver los conflictos que aparecerán sin duda alguna.

 

Reflexión final

En este rápido vistazo a la historia de Lean y Agile dejamos muchos aspectos sin tocar, aunque sí que podemos señalar algunas pinceladas interesantes sobre lo que Lean y Agile comparten:

• El concepto de Valor centrado en el cliente
• El flujo continuo de lean equivale a la producción incremental de software funcionando.
• El equipo Kaizen (1) y el equipo Scrum (2) son, en esencia, equivalentes.
• La obsesión por la calidad es parecida: el concepto del “error no avanza” de Lean y la reducción de la “deuda técnica” que preconiza Agile son las dos caras de una misma moneda.

Con respecto al coaching, especialmente el coaching de equipo se encuentra como pez en el agua tanto en el contexto de lean como de agile, incluso adaptándose al nuevo contexto híbrido de trabajo, mediante el coaching online. Objetivos, colaboración, empoderamiento, medición, alto rendimiento… No es casualidad que hoy se hable de Lean y Agile Coaching.
Y ahora una idea para desarrollar.

Si Lean se entiende solo para la producción de bienes tangibles y Agile se circunscribe al desarrollo de software, surge la pregunta ¿qué hacemos con una empresa que no fabrica nada? ¿para qué nos vale un departamento de informática en una fábrica?

Afortunadamente Lean es “una forma de pensar” (Lean thinking) y Agile no es solo producción de software sino cualquier actividad humana de carácter intelectual que pueda realizarse en equipo.

Es por eso por lo que las fronteras entre Lean y Agile se amplían progresivamente y, al mismo tiempo, son cada vez más imprecisas. Todo hace pensar que ambas disciplinas convergen y, tal vez, se fusionen.

El coaching está contribuyendo a ello y ahora cobra sentido pleno esa profesión etiquetada como Lean y Agile Coaching, que probablemente deba su éxito por su capacidad para ayudar a las empresas a desenvolverse mejor en la situación actual del mercado, que ha dado en llamarse VUCA, acrónimo en inglés de Volatilidad (cambio continuo y constante), Incertidumbre (falta de predictibilidad), Complejidad (Múltiples condiciones que desvirtúan el factor causa-efecto) y Ambigüedad (Distorsión de la realidad en el contexto organizacional y del trabajo).

 

• (1) El término Kaizen, proviene de la fusión de dos palabras japonesas: “Kai” y “Zen” que significan “cambio” y “mejor”. Un equipo Kaizen mantiene reuniones que conforman un evento para resolver problemas, llevar a cabo mejoras y cambios, teniendo presente lo que el cliente espera. Kaizen es la esencia de la mejora continua en el contexto de Lean.

• (2) Un equipo Scrum es un grupo de personas que trabajan conjuntamente para producir y entregar mejoras incrementales de un producto, en ciclos de tiempo cortos denominados sprints. Los roles de un equipo Scrum son 3. El “propietario” del producto, el Scrum Master y el equipo de Desarrollo.