2021-02-03
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 for three to four years. This is a long time in which 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, 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 requiring all involved employees to 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.
The Cynefin Framework
"The framework sorts the issues facing leaders into five contexts defined by the nature of the relationship between cause and effect. Four of these - obvious, complicated, complex, and chaotic - require leaders to diagnose situations and to act in contextually appropriate ways. The fifth – disorder - applies when it is unclear which of the other four contexts is predominant."
– Dave Snowden and Boone (2007)
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, in SAFe, managers are made to 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 eight to 12 weeks and capacities are planned accordingly. If teams run into unforeseen changes, they usually do not have to 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 from becoming 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, most of the development for cars is done with and by suppliers. 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.
- Complexity cannot be treated 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. De-scaling an organization is not foreseen in SAFe 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.
