Lo que aprendí en Toyota

Prueba del nuevo Toyota Mirai de hidrógeno con Pierre Masai

Conocí a Pierre Masai, CIO de Toyota Motors Europe (TME), hace unos años en la conferencia anual de Lean IT en París. Pierre es un defensor de la agilidad comprometido con el impulso de Scrum en toda la infraestructura de TI. Por invitación suya, hace poco pasé la mayor parte de dos días en Bruselas reuniéndome con directivos y desarrolladores y presentando parte de lo que hemos aprendido sobre Scrum. Decidí empezar preguntando cómo aborda Toyota los tres megadesafíos que identificamos en nuestra Formaciones Scrum y Scrum@Scale talleres:

¿Tiene la empresa un backlog de producto claro para cada equipo en cada sprint?
¿Puede la empresa llegar a Done con funciones útiles al final de cada sprint y Done significa desplegable?
¿Puede la empresa refactorizar fácilmente su organización para aprovechar las condiciones del mercado y optimizar la entrega de un producto valioso a los clientes? Es esencial contar con equipos pequeños e interfuncionales apoyados por la dirección.

Al igual que todas las empresas que pasan del desarrollo tradicional de productos a una forma ágil de trabajar, Toyota se enfrenta a estos retos. Ellos también necesitan prioridades claramente visibles. También encuentran casos en los que todo es prioridad número uno y en los que la gente trabaja en muchas cosas diferentes a la vez. Esto produce mucho despilfarro. En las empresas en las que todo es prioritario y todo el mundo trabaja en muchas cosas a la vez, la multitarea es la norma. Como demostró Gerry Weinberg en Gestión de software de calidad: Pensamiento sistémico, las personas o equipos que trabajan en cinco cosas a la vez tienen una pérdida de 75% debido al cambio de contexto. Parece que cuanto mayor es la empresa, peor es este problema. A nivel de equipo, hace que sea difícil conseguir hacer las cosas al final de un sprint. La eficiencia del proceso es terrible. Ellos también necesitan una definición más rigurosa de DONE para que las características útiles sean desplegables al final de cada sprint. Todas las pruebas deben realizarse dentro del sprint. Todos los errores deben corregirse dentro del sprint. Se tarda mucho más tiempo en corregir un error semanas después, y en el caso de productos complejos se tarda hasta 24 veces más en probarlo y corregirlo. Además, no todos sus equipos son tan pequeños ni tan transversales como podrían ser. Sin embargo, Toyota tiene claras ventajas que la mayoría de las empresas no tienen a la hora de hacer una transición ágil. Toyota cuenta con una herencia de excelencia basada en el Sistema de Producto Toyota y la disciplina de Hoshin, un sistema de planificación estratégica que:

Selecciona un objetivo clave.
Alinea los planes de aplicación a todos los niveles.
Aplica, revisa y mejora el plan de forma continua.

A medida que Toyota aumenta el rigor del sistema Hoshin, más personas realizan un trabajo más valioso. Esperan que las cosas se hagan en iteraciones cortas, idealmente de flujo continuo de una sola pieza. Taiichi Ohno creó el Sistema de Productos Toyota para utilizar pequeños equipos interfuncionales que mejoran radicalmente la eficacia de los procesos. El resultado neto es que Los beneficios por coche de Toyota superan a los de los 3 grandes fabricantes de Detroit. Por desgracia, Toyota ha aplicado históricamente la gestión tradicional de proyectos en cascada en TI. Cuando les recordé su herencia y les pregunté qué diría Taiichi Ohno si viera los restos del proceso en cascada que aún existen hoy en Toyota, me respondieron: "¡Se indignaría!". Así que lo que aprendí en Toyota es que Hoshin y la ira del fundador son poderosos incentivos para conseguir que la TI de Toyota sea ágil. -- Jeff Sutherland

Nota: El proceso de planificación hoshin sigue el modelo de Deming Planificar-Hacer-Verificar-Actuar ciclo. PDCA es un método genérico para la mejora continua, que es lo que pretende ser la planificación hoshin. Scrum se basa en el ciclo PDCA de Deming y en los métodos desarrollo de nuevos productos. Tiene Hoshin integrado en forma de Equipo Product Owner que alinea a toda la organización con un backlog jerárquico de productos. Esta capacidad de concentración permite realizar un trabajo más útil. En el caso de Toyota, le permite lograr una rentabilidad superior en sus productos, que es el objetivo del Product Owner en el Scrum.