Toyota, Lean, Agile y Scrum

Introducción

Mucho se ha dicho y escrito acerca de Toyota y cómo sus prácticas han revolucionado (o al menos intentado) el entorno de trabajo de empresas de diferentes rubros a nivel mundial.

Toyota ha sido la piedra fundamental sobre la cual los principios Lean se crearon y estos a su vez influenciaron grandemente la corriente Ágil y el marco de trabajo Scrum.

Sin embargo, dentro de Scrum muchas veces olvidamos volver a las raíces para así entender por qué hacemos las cosas. Scrum se ha vuelto popular pero más mucha gente sigue desconociendo los pilares sobre los que se funda y esto trae consigo consecuencias negativas.

La Máquina que Cambió el Mundo

Los automóviles han tenido una gran influencia en la transformación de las sociedades y su forma de fabricación ha sido definitiva a la hora de influenciar la manufactura global.

De hecho, ninguna otra máquina en la era moderna ha tenido una influencia tan grande en la forma como se han organizado trabajadores, materiales, capital, conocimiento y equipos [Womack07]. 

Una forma de organización más eficiente (evitando las varias formas de desperdicio) conduce a una mayor producción mejor alineada con el mercado y a su vez impacta positivamente sobre el ánimo y bienestar de los equipos: de aquí la recomendación de los ScrumMasters conozcan y apliquen los principios de manufactura Lean.

La Esencia del Pensamiento de Toyota

Taiichi Ohno [Ohno13] resume de manera muy acertada un principio fundamental: la percepción errada que proviene del distanciamiento del gemba. Para clarificar estos errores de percepción Ohno sugiere una práctica simple “Go and see”.

Por desgracia este principio no se ve frecuentemente dentro de los equipos Scrum en los cuales se pretende supervisar o evaluar el trabajo a través de reportes e indicadores visuales. 

Un segundo principio fundamental es “stop and fix” que literalmente quería decir para Toyota detener la línea de producción en cuanto se detectaba un problema de calidad, aplicar la técnica de los “cinco whys” para encontrar la raíz del problema, mitigar (no encontrar la solución perfecta) y luego reanudar la línea de producción.

El principio de “stop and fix” tenía también un segundo propósito: forzar el aprendizaje. En general los adultos, o al menos no todos, no quieren seguir aprendiendo y por tanto un mecanismo como este forzaba a que dejen de trabajar, reflexionen acerca de qué no está funcionando bien, planteen posibles mitigaciones y luego experimenten poniéndolas en práctica.

Contrariamente a “stop and fix” en los equipos Scrum muy frecuentemente se observa que los defectos se van apilando y hasta se crea un backlog para ponerlos allí, priorizarlos y no perderlos de vista; esta práctica no solo rompe el principio Toyota, sino que además no contribuye a mejorar las practicas ingenieriles ni el conocimiento de los desarrolladores. Hacer más mal trabajo de baja calidad o hacerlo con predictibilidad no contribuye positivamente al producto que continuará acumulando deuda técnica y deuda de aprendizaje.

Si bien la lista de principios Toyota [Liker04] se extiendo bastante mencionaremos aquí solamente uno más: “kaizen al infinito”. Este principio tiene que ver con el aprendizaje continuo y con cultivar un ambiente de gente con conocimiento elevado que hace productos excelentes [Senge90].

Muy frecuentemente encuentro ScrumMasters que andan en busca de las “mejores prácticas de Scrum” las cuales en realidad no existen y si las hay son dependientes de un contexto particular no fácilmente replicable o extrapolable. En lugar de eso, la labor del ScrumMaster debería volcarse más a construir un ambiente de aprendizaje continuo donde se experimenten con diferentes prácticas. Parafraseando a Senge [Senge90] el factor diferenciador de una empresa (y consecuentemente de un equipo) es el grado de conocimiento adquirido y las ganas de seguir aprendiendo.

Lean, Respeto y Desperdicios

El enfoque de manufactura Lean puede resumirse de manera muy genérica a través de la siguiente formula [Ballé14]: 

LEAN = RESPECT + KAIZEN

Donde RESPECT se refiere al respeto por los trabajadores, su creatividad y el deber que tiene la gerencia de proveer las condiciones necesarias para que estos desarrollen su máximo potencial.

Desde un enfoque más estratégico Lean podría ser conceptualizado a través del siguiente esquema:   

Desde una perspectiva tradicional el enfoque Lean tiende a maximizar las actividades que generan valor en el producto y a reducir las actividades que generan desperdicio. El desperdicio a su vez puede clasificarse como: desperdicio inmediato que deber ser reducido ahora o desperdicio identificado para el cual no hay una mitigación inmediata.

Si hablamos de formas de desperdicio, existen algunas que son clásicas:

  • Trabajadores sobrecargados y estresados
  • Cuellos de botella
  • Espera en cola
  • Handoff
  • Ilusión 
  • Diseminación de la información

Y muchas otros más que están presentes y son particulares a cada equipo.

Por tanto, la labor de un ScrumMaster es contribuir positivamente a crear una cultura dentro del equipo que tienda a valorar el respecto, practicarlo, extenderlo e identificar a través de él las diferentes formas de desperdicio y tratar de mitigarlas. 

Lo opuesto de lo anterior sería una cultura de no-respeto en la cual los desperdicios no son identificados, y si lo son nadie hace nada al respecto, y la motivación por el trabajo mismo es tan baja que el equipo no hace lo más mínimo para mejorar sus prácticas. 

Agile: van Dos Décadas y Todavía hay Confusión

En estos días mucho se ha popularizado bastante el término “Ágil” y se ha mezclado con diferente prefijos y sufijos (agile coach, agile adoption, agile inception, etc.) pero el problema de fondo persiste: la gente y las empresas entran tratando de copiar y usar algo que todavía no acabaron de entender. 

Por eso es que en el rol de ScrumMasters uno de los principales desafíos es educar a las personas para que su entendimiento mejore. Una herramienta útil el Manifiesto Ágil pero este a la vez se queda muy corto pues es intencionalmente conciso y liviano.

Una otra herramienta es educar a través de la terminología que se utiliza frecuentemente en el espacio ágil ligado al desarrollo de software.

Sin embargo, he encontrado que en la práctica las personas y organizaciones tienden a entender mejor la agilidad cuando esta es presentada desde una perspectiva que describa su evolución histórica, es decir comenzando por sus orígenes en el Toyota Production Systems y su evolución hacia el software en conexión con eXtreme Programming. 

Más aún, resulta muy valioso para muchos establecer la reconexión entre los principios de Toyota y las practicas actuales de DevOps [Forsgren18].

Cualquiera que sea el camino escogido para explicar el concepto creo que es importante que se entienda que Agile tiene que ver con:

MENTALIDAD <-> CULTURA (PRINCIPIOS + PRACTICAS)

De igual importancia es explicar que Agile continúa evolucionando hacia otros enfoques como Modern Agile y The Heart of Agile.

Y que es esperable y de hecho deseable que esta evolución continúe pues Agile es en esencia un concepto evolutivo.

Y así Llegamos a Scrum

Si bien es totalmente cierto que Scrum es un marco de trabajo ligero y ágil orientado a grupos de trabajo que construyen productos, también es cierto que su simplicidad conceptual muchas veces hace que se interprete como una simple prescripción de reuniones y uso de un tablero.

Considero que Scrum debe ser entendido desde una perspectiva histórica asociada con las otras disciplinas con las cuales se interseca, de manera simplificada:

SCRUM = LINAJE + INTERSECCIONES

Si hablamos del linaje pues es vital entender que Scrum no es un marco de trabajo revolucionario; por el contrario, proviene de la evolución hacia el software del Toyota Production System que a su vez propició la aparición de Lean que a su vez influenció fuertemente la corriente ágil.

Y si hablamos de las intersecciones Scrum se interseca con una larga lista de disciplinas entre las cuales podríamos nombrar:

  • Teoría de colas
  • Teoría de sistemas
  • Prácticas ingenieriles como XP y DevOps en el mundo del software
  • Teoría de caos
  • Habilidades blandas para la construcción de equipos
  • Coaching

El objetivo pragmático que Scrum es enfocarse en crear un ambiente de aprendizaje continuo en el cual sea seguro experimentar y fallar. Este ambiente de aprendizaje eventualmente beneficia al Equipo, al Product Owner, a la Empresa y a las Prácticas de Desarrollo pues permite la exploración y mejora continua. 

Un corolario de lo anterior es que el ScrumMaster debe mantenerse enfocado dentro de cuatro áreas de acción principales: Equipo, Product Owner, Empresa y Prácticas de Desarrollo [Larman17].

Conclusiones

Si bien es cierto que Scrum se presta y de hecho invita a la adaptación esta debe hacerse dentro de los principios de la agilidad que a su vez se conectan con Lean y el Toyota Production System.

Hacer adaptaciones desconectadas de estos principios muy frecuentemente lleva a resultados subóptimos o a adopciones de Scrum fallidas. Peor aún en algunos casos ha llevado a ver a Scrum como una nueva y mejorada forma para tener mejor control de los empleados y el cronograma.

En el rol de ScrumMasters es vital clarificar estos malos entendidos y hacer que Scrum se utilice para lo cual realmente fue pensado.

Bibliografia 

Womack07 Womack J., Jones D., Ross D., 2007. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry, Free Press; Reprint edition

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw-Hill

Liker04 Liker J., 2004. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, McGraw-Hill

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute

Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press

Larman17 Larman C., Vodde B., 2011. Large-Scale Scrum More with LeSS, Addison-Wesley

Leave a Reply