Automotive and Agile: SAFe or not?

Reasons why Automotive Managers fall in love with SAFe.

The Digital Disruption

For more than 100 years car manufacturers all over the world developed and produced automobiles. Thousands of employees at car manufacturers work on the development of today’s car models between 3 to 4 years. This is a long time, where these employees have to collaborate with each other.

Software changes everything

Car manufacturers have to manage the digital transformation if they are to survive. Cars are not just cars anymore. Today, 50 – 70 percent of development costs go into software development. In an increasingly digital world, including in automobiles, it is necessary to deliver innovations in short development cycles. Ideally, car makers today would like to update software in a car even after it has been sold.

Car development is no longer about mechanics, hardware, steel and sheet metal. With software their development processes become more and more complex. Car manufacturers therefore look out for new working models that will better prepare them for the future. A future built on software rather than hardware.

Business agility with Scrum

This is why companies look out for alternative working models that address such complexity in software much better than traditional engineering practices.

Scaling frameworks help to organize the company towards more business agility. The usual suspects are SAFe, LeSS, Nexus, DAD or Scrum@Scale with SAFe being the framework most companies choose for their transformation.

Spoiled for Choice

Which framework is the right one to choose? Automotive managers usually decide based on their previous experience in the industry. They can no longer ignore the evident disruption based on software taking over control of what the market needs. It’s time to think outside of the box.

SAFe is loved too quickly

The automotive industry often chooses the Scaled Agile Framework (SAFe) for their new way of working with software development. In many cases, the introduction of SAFe does not lead to the desired success. Three possible reasons explain their decision in favour of “SAFe” and why its implementation is not successful.

Reason #1: From Complicated to Complex

When a car manufacturer builds a new model, the path for all steps required to develop is clearly defined. Lots of pieces must fit together. All involved employees must be very organized in their development process. The internal organization of all car manufacturers is pretty much the same, and their processes are too.

Such development processes are complicated but well defined and mature. Engineers in the automotive industry are used to such processes for decades, it is within their DNA.

Except for something called software. Developing software is not complicated but complex. It can get to a point where it would be impossible to know and understand all of it. While changing software is easy to do, the effects of such changes cannot be foreseen once the software has grown to a certain size.

Because it is so easy to change software, its direction can change very quickly and, unlike changes in hardware (i.e., cars), can shift much faster. This major difference in approach requires a different working model, one that deals with complexity much better.

Scrum addresses that with short development cycles and empirical process control. In large-scale Scrum it is essential that teams collaborate with each other in hierarchies with minimum handovers. Scrum addresses that with short development cycles and empirical process control. In large-scale Scrum it is essential that teams collaborate with each other in hierarchies with minimum handovers.  SAFe offers you much of that but does not change an existing organization towards more simplicity and thus gaining more transparency and flexibility. Instead, SAFe makes managers believe that overflowing hierarchies are not their main challenge.

In order for an organization to be able to change direction quickly, it has to be de-scaled and simple in its hierarchical levels. More responsibility has to be brought into the teams. PI-Planning in SAFe is done for the upcoming 8 to 12 weeks and capacities are planned accordingly. If teams run into unforeseen changes, they usually do not have plan in the extra effort to overcome these changes. This leads to time pressure and problems typically seen in traditional projects: teams carrying over unfinished work from one sprint to the next and eventually to the next PI. As a consequence, trust in the teams goes down, control from outside rises. Just the opposite of what was intended. And ultimately you are in love with the wrong one.

Reason #2: The situation is Taylor-made

In the late 1800’s Frederick W. Taylor advocated a system of scientific management to improve workers performance by breaking each job down into its individual motions and eliminating those considered to be unnecessary and giving out incentives for good performance. Taylor’s principles are not designed to solve complex problems. The automotive industry is still infected by these ideas thus leading to false thinking in how to approach problems and – again – how to organize themselves.

Taylorism leads to local optimization and complex organizational designs. It prevents teams from collaborating with each other and thus prevents your organization to become more flexible.

SAFe as a large-scale agile framework with its many levels (Product, Solution, Portfolio) gives managers a feeling of safety that it is possible to start large-scale agile ways of working without adapting their line organization. Instead of keeping unnecessary hierarchies or scaling them, managers must identify an organizational model that makes it easy to collaborate between teams and eliminates the need to manage dependencies. The more hierarchies you implement the more you move away from principles like Customer Centricity and Adaptiveness.

Reason #3: Control the supplier as before

Today suppliers do most of the development for cars. Meanwhile engineers at car manufacturers are acting more like project managers controlling the work of suppliers rather than doing it themselves.

Traditionally there is this urge to control (also because there is a contract between car manufacturers and their suppliers) leading to corresponding roles and organization. With its multi-level role and organizational concept, SAFe gives automotive managers a wrong impression: They think that appropriate coordination roles for managing service providers make sense in order to ensure successful delivery of their supplier.

Lean Software Development is primarily about eliminating “wastes” because they severely limit the flexibility and adaptability of a development organization.

Several of these “wastes” are in focus with suppliers: Hand-Off, Waiting / Delay and Extra Process. SAFe as a framework does not address such a leaner organization by avoiding these “wastes”. Instead, managers are tempted to put suppliers into their own ARTs and then control them instead of partially passing control to the supplier.

Conclusion

In conclusion, SAFe seems to be an obvious choice for Automotive Managers for the reasons explained above. It can be, if the basic principles of Lean, together with organizational design, are considered for any change made based on SAFe, e.g.

• Concentrate on the main organizational targets within the organization: flexibility and adaptability.
• You cannot treat complexity with known practices of the complicated world. It requires a different approach towards a software solution and therefore a different organization.
• Prefer to eliminate wastes in the organization over building up multiple organizational levels. SAFe does not foresee de-scaling an organization. But will greatly help to reach the organizational targets.
• Shift responsibility to the teams in order to support true collaboration and hence reducing the need to coordinate or even control teams.