15 marzo, 2024
Durante más de 100 años, los fabricantes de automóviles de todo el mundo desarrollaron y produjeron automóviles. Miles de empleados de los fabricantes de automóviles trabajan en el desarrollo de los modelos de automóviles actuales durante tres o cuatro años. Este es un largo tiempo en el que estos empleados tienen que colaborar entre sí.
El software lo cambia todo
Los fabricantes de automóviles tienen que gestionar la transformación digital si quieren sobrevivir. Los autos ya no son solo autos. Hoy en día, entre el 50 y el 70 por ciento de los costos de desarrollo se destinan al desarrollo de software. En un mundo cada vez más digital, es necesario ofrecer innovaciones en ciclos de desarrollo cortos. Idealmente, a los fabricantes de automóviles de hoy en día les gustaría actualizar el software de un automóvil incluso después de que se haya vendido.
El desarrollo de automóviles ya no se trata de mecánica, hardware, acero y chapa. Con el software, sus procesos de desarrollo se vuelven cada vez más complejos. Por lo tanto, los fabricantes de automóviles buscan nuevos modelos de trabajo que los preparen mejor para el futuro. Un futuro basado en el software y no en el hardware.
Agilidad empresarial con Scrum
Esta es la razón por la que las empresas buscan modelos de trabajo alternativos que aborden tal complejidad en el software mucho mejor que las prácticas tradicionales de ingeniería.
Los marcos de escalado ayudan a organizar la empresa hacia una mayor agilidad empresarial. Los sospechosos habituales son SAFe, LeSS, Nexus, DAD o Scrum@Scale siendo SAFe el marco que la mayoría de las empresas eligen para su transformación.
Con muchas opciones para elegir
¿Qué marco es el adecuado para elegir? Los gerentes automotrices generalmente deciden en función de su experiencia previa en la industria. Ya no pueden ignorar la evidente disrupción basada en que el software toma el control de lo que el mercado necesita. Es hora de pensar fuera de la caja.
SAFe es amado demasiado rápido
La industria automotriz a menudo elige el Scaled Agile Framework (SAFe) para su nueva forma de trabajar con el desarrollo de software. En muchos casos, la introducción de SAFe no conduce al éxito deseado. Tres posibles razones explican su decisión a favor de "SAFe" y por qué su implementación no tiene éxito.
Razón #1: De lo complicado a lo complejo
Cuando un fabricante de automóviles construye un nuevo modelo, el camino para todos los pasos necesarios para desarrollarlo está claramente definido. Muchas piezas deben encajar, lo que requiere que todos los empleados involucrados sean muy organizados en su proceso de desarrollo. La organización interna de todos los fabricantes de automóviles es prácticamente la misma, y sus procesos también lo son.
Estos procesos de desarrollo son complicados pero bien definidos y maduros. Los ingenieros de la industria automotriz están acostumbrados a este tipo de procesos desde hace décadas, está dentro de su ADN.
Excepto por algo llamado software. El desarrollo de software no es complicado sino complejo. Puede llegar a un punto en el que sería imposible saberlo y entenderlo todo. Si bien el cambio de software es fácil de hacer, los efectos de dichos cambios no se pueden prever una vez que el software ha crecido hasta un cierto tamaño.
Debido a que es tan fácil cambiar el software, su dirección puede cambiar muy rápidamente y, a diferencia de los cambios en el hardware (es decir, los autos), puede cambiar mucho más rápido. Esta gran diferencia de enfoque requiere un modelo de trabajo diferente, uno que se ocupe mucho mejor de la complejidad.
El marco de Cynefin
"El marco clasifica los problemas a los que se enfrentan los líderes en cinco contextos definidos por la naturaleza de la relación entre causa y efecto. Cuatro de ellos (obvios, complicados, complejos y caóticos) requieren que los líderes diagnostiquen las situaciones y actúen de manera contextualmente apropiada. El quinto, el desorden, se aplica cuando no está claro cuál de los otros cuatro contextos es el predominante".
- Dave Snowden y Boone (2007)
Scrum aborda eso con ciclos de desarrollo cortos y control empírico de procesos. En Scrum a gran escala, es esencial que los equipos colaboren entre sí en jerarquías con traspasos mínimos. SAFe le ofrece mucho de eso, pero no cambia una organización existente hacia una mayor simplicidad y, por lo tanto, gana más transparencia y flexibilidad. En cambio, en SAFe, a los gerentes se les hace creer que las jerarquías desbordadas no son su principal desafío.
Para que una organización pueda cambiar de dirección rápidamente, tiene que ser desescalable y simple en sus niveles jerárquicos. Hay que aportar más responsabilidad a los equipos. La planificación de PI en SAFe se realiza para las próximas ocho a 12 semanas y las capacidades se planifican en consecuencia. Si los equipos se encuentran con cambios imprevistos, por lo general no tienen que planificar el esfuerzo adicional para superar estos cambios. Esto conduce a la presión del tiempo y a los problemas que suelen verse en los proyectos tradicionales: los equipos trasladan el trabajo inacabado de un sprint al siguiente y, finalmente, al siguiente PI. Como consecuencia, la confianza en los equipos disminuye, el control desde afuera aumenta. Justo lo contrario de lo que se pretendía. Y, en última instancia, estás enamorado de la persona equivocada.
Razón #2: La situación es hecha a medida
A finales de 1800, Frederick W. Taylor abogó por un sistema de administración científica para mejorar el rendimiento de los trabajadores dividiendo cada trabajo en sus movimientos individuales y eliminando aquellos que se consideraban innecesarios y dando incentivos para el buen desempeño. Los principios de Taylor no están diseñados para resolver problemas complejos. La industria automotriz todavía está infectada por estas ideas, lo que lleva a un pensamiento falso sobre cómo abordar los problemas y, nuevamente, cómo organizarse.
El taylorismo conduce a la optimización local y a diseños organizativos complejos. Evita que los equipos colaboren entre sí y, por lo tanto, evita que su organización se vuelva más flexible.
SAFe como marco ágil a gran escala con sus muchos niveles (Producto, Solución, Cartera) brinda a los gerentes una sensación de seguridad de que es posible iniciar formas ágiles de trabajo a gran escala sin adaptar la organización de su línea. En lugar de mantener jerarquías innecesarias o escalarlas, los gerentes deben identificar un modelo organizativo que facilite la colaboración entre equipos y elimine la necesidad de administrar dependencias. Cuantas más jerarquías implementes, más te alejarás de principios como la centralidad en el cliente y la adaptabilidad.
Razón #3: Controla al proveedor como antes
Hoy en día, la mayor parte del desarrollo de automóviles se realiza con y por proveedores. Mientras tanto, los ingenieros de los fabricantes de automóviles están actuando más como gerentes de proyectos que controlan el trabajo de los proveedores en lugar de hacerlo ellos mismos.
Tradicionalmente existe esta necesidad de controlar (también porque existe un contrato entre los fabricantes de automóviles y sus proveedores) que conduce a los roles y la organización correspondientes. Con su función multinivel y su concepto organizativo, SAFe da una impresión equivocada a los gestores de la industria del automóvil: piensan que las funciones de coordinación adecuadas para la gestión de los proveedores de servicios tienen sentido para garantizar el éxito de la entrega de su proveedor.
El desarrollo de software Lean se trata principalmente de eliminar los "residuos" porque limitan severamente la flexibilidad y la adaptabilidad de una organización de desarrollo. Varios de estos "residuos" están en el foco de los proveedores: Entrega, Espera / Retraso y Proceso Extra. SAFe como marco no aborda una organización tan ágil evitando estos "desperdicios". En su lugar, los gerentes tienen la tentación de poner a los proveedores en sus propios ART y luego controlarlos en lugar de pasar parcialmente el control al proveedor.
Conclusión
En conclusión, SAFe parece ser una opción obvia para los gerentes de automoción por las razones explicadas anteriormente. Puede serlo, si se consideran los principios básicos de Lean, junto con el diseño organizacional, para cualquier cambio realizado en base a SAFe, por ejemplo:
- Concéntrate en los principales objetivos organizacionales dentro de la organización: flexibilidad y adaptabilidad.
- La complejidad no puede ser tratada con prácticas conocidas del mundo complicado. Requiere un enfoque diferente hacia una solución de software y, por lo tanto, una organización diferente.
- Prefiere eliminar los desperdicios en la organización en lugar de crear múltiples niveles organizacionales. SAFe no prevé la reducción de escala de una organización, pero será de gran ayuda para alcanzar los objetivos de la misma.
- Traslada la responsabilidad a los equipos para apoyar una verdadera colaboración y, por lo tanto, reducir la necesidad de coordinar o incluso controlar los equipos.
