
In automotive product development, Automotive SPICE, Agile, and other standards and methodologies often overpromise and underdeliver
“Everyone Is Talking About the Software Crisis” is a chapter title in our recently published discussion on this topic (link; English edition coming soon). The term “software crisis” was coined in 1968 during a NATO software conference in Garmisch-Partenkirchen, Germany. See also the report by Brian Randell (see link), who participated in that event.
The findings from the 1968 conference can be summarized as follows:
- Lack of reliability in data systems.
- Difficulties in adhering to schedules and specifications for extensive software projects.
- Inadequate training of software engineers.
- High systems prices associated with software and hardware.
- Software development is a young discipline that requires further, more intensive research.
- Software production needs to catch up with hardware.
- The management of software projects will only improve once a deeper understanding of the software discipline has been achieved.
- Software development needs more risk management, especially when introducing new concepts and methods.
- Software complexity must be recognized and acknowledged.
- Lessons must be learned from past projects to improve software.
These insights have remained valid despite the hundreds of “methodologies” and novel technologies published, marketed by clever consultants, and heavily invested in—including CMM, CMMI, Automotive SPICE, SCRUM, SAFe, and countless others. An expert on process efficiency, David F. Rico, has published a timeline listing these “methodologies” (see here), although it is not exhaustive.
Looking at this timeline, it becomes clear that ASPICE is just a tiny part of the broader challenge with “the software.” The number of increasingly complex and comprehensive standards—such as functional safety (ISO 26262), cybersecurity (ISO 21434), and many more—is skyrocketing. These standards and methodologies constantly compete for the attention of decision-makers with limited budgets.
Given this development, it is understandable that engineers—particularly software developers—experience growing pressure to comply with the overwhelming avalanche of standards and regulations. While these standards may seem well-intentioned, they often feel “off” or counterproductive. Most software engineers are acutely aware of the urgency surrounding the ongoing “software crisis.” However, it remains unclear whether addressing this challenge with an ever-expanding set of regulations, standards, methods, and models has provided any significant relief.
Fighting the “software crisis” does not motivate a typical software engineer. After all, developers have invested years of proverbial “blood, sweat, and tears” to become creative in their field—only to spend countless hours filling out endless QA checklists instead. The harsh reality is that compliance often stifles creativity, leading to frustration, resentment, and, in some cases, outright rebellion against the “QA machine.”
That said, categorically and dogmatically rejecting such standards might be like throwing the baby out with the bathwater. It is easy to dismiss restrictive “standards,” but rejection alone is not a strategy. A thorough understanding of systems development as both an intellectual and social endeavor is indispensable for developing a successful software-based product.
Rejection is not a strategy
The meaning of frequently trivialized “methodologies” like SCRUM or “agile” (an adjective promoted to a noun by PR-savvy consultants) has become anyone’s guess. “Agile” is a protest movement, which may be a recipe to stir up mass engagement and ignite a “revolution.” Still, revolutions eventually become bloody disasters, and the problem-protest cycle repeats. Initially, “good” ideas, such as “ASPICE” or “Agile,” soon became co-opted, as highlighted by one of the Agile Manifesto signatories, Dave Thomas, during a GOTO event in 2015 (see link). A clear symptom of the co-opting of the Agile movement—which started 30 years ago and has yet to produce a meaningful solution to the “software crisis” (the same applies to Automotive SPICE and others)—is the emergence of new “methodologies” that can be “certified.” While process compliance certification has existed since the early days of CMM, “agile certifications” remain oxymoronic.
Over time, these new “standards” and “methods” tend to become a burden for businesses that suddenly find themselves required to comply with new “standards”—which are often annoying at best and financial bottomless pits at worst. What some might see as a “money grab” consultants see as a legitimate business practice. Every “methodology” movement aims to transform its concept into a “scalable” idea, enabling the consultancy industry to turn them into profitable enterprises by exploiting them as “business growth opportunities.” Such “scalability” is typically achieved through training freshly hired employees who often lack sufficient industry experience or, in some cases, do not share the passion for the concept in the first place. This recurring pattern has occurred with CMM, CMMI, Automotive SPICE, OOAD, RUP (Rational Unified Process), SCRUM, and many others.
Need for constant change: a natural habitat for projects
In the traditional corporate world, a natural tendency is to aspire to be promoted to line management and escape the constant fight for economic survival—a typical challenge in project-oriented environments. The ultimate long-term goal is to reach a point where managers envision accumulating enough wealth to retire eventually. That’s why previously agile, energetic, intelligent, and innovative techies—once relentlessly driven—gradually become slow, risk-averse, and complacent. They tend to rely on “established” standards and processes, avoiding the risky challenge of reinventing organizations. Unfortunately, reinventing an organization is indispensable for ensuring the long-term survival of an automotive systems development organization.
This conflict is a frequent source of both open and hidden tensions in large corporations.
In systems and product development, there will never be “the” solution that allows everyone to sit back and enjoy the proverbial show. Each new product will require a new project, and this project will have to reinvent many aspects of systems development and test strategies. It will never get old. If you dislike this reality and expect otherwise, you will never be happy in an industry like automotive product development. The good news is that countless alternatives to the auto industry exist, and they often offer better pay and longer vacations than the notoriously brutal, breakneck-paced world of automotive product development. I know executives who decided to stop struggling and have become successful in more predictable businesses, providing a better work-life balance than in the auto industry.
Simple, proven concepts instead of heavy processes
If the overly complicated process landscape is overburdening teams, what is the right strategy going forward? We have discussed the perils of complacently believing that methodologies like Automotive SPICE are blueprints that can be implemented and “institutionalized.” That’s a tragic misconception: Automotive SPICE (or, for that matter, SCRUM, SAFe, etc.) are NOT process blueprints. They were never truly intended to be “process models” that could be directly implemented in a development organization. Although ASPICE refers to reference process areas as “processes,” this critical misunderstanding often results in highly redundant, “write-only” process documentation that rarely helps the team deliver a quality product. Instead, concepts like Automotive SPICE are simply checklists designed to ensure that no crucial aspect of systems development is overlooked—no more and no less. In other words, assessment models and various methodologies are analytical approaches.
However, not analysis but synthesis is desperately needed to transform the project management approach into a functioning, “live” organism for product development. When starting a new development project, defining a project approach is an essential step in the product development lifecycle. However, rather than attempting to “tailor” a Level 3 process model that is (at least theoretically) intended to ensure a rapid project start, a more meaningful approach is to rely on the proven “fundamental aspects” that are indispensable in virtually any non-trivial project.
Those aspects include:
- Product Design: defines what needs to be done
- Verification: defines how “good” the design is supposed to be
- Versioning (and configuration): ensures the product parts are consistent
- Issue Management, Task Management, and CR management: that ensures that no tasks are overlooked
- Team Leadership and Team Organisation: ensures organizational coherence and feasibility of the product development.

These aspects should be apparent to anyone who has experienced at least one automotive development project first-hand. With sufficient organizational support, any experienced project lead—whose task is to connect the dots—can typically deliver a new project. If not, meaningful guidance from senior project leads can help quickly address any remaining details within the project organization.
I know it sounds too simple to be true, but I can confirm that organizing and running a project is not rocket science. The real challenge lies in creating and maintaining a sense of urgency, identifying and mitigating project risks early, and managing stakeholders effectively. That’s it. Projects rarely fail due to technical difficulties; they fail because of ignorance, lack of expertise, and the naivety of key stakeholders—along with neglecting the essential aspects mentioned above.
Effective Critical Systems Thinking
Integrating these success criteria into a meaningful approach is only possible if project leadership practices Effective Critical Systems Thinking (ECST). This approach helps avoid silo-thinking, deception by wasteful methodologies, and management hypes while ensuring the entire team understands and supports the project’s purpose.
We have discussed Effective Critical Systems Thinking (ECST) in more detail on these pages. I would like to reiterate the importance of this concept in the context of the current challenges facing our automotive industry, particularly in the Western hemisphere. Our challenges include complacency, political inertia, indiscriminate reliance on “standards,” hopeless corporatism, and an unwillingness to face obvious challenges head-on.
In a nutshell, we often lack the notoriously abused concept of “common sense”—which, unfortunately, frequently turns out to be a hopeless oxymoron. It’s simply easier to go with the flow than to recognize that the ship is sinking.
Automotive SPICE, “agile,” or any other methodology is not the solution to our challenge—it is probably not even a solution.
Instead, a “back to the roots” approach appears more viable: recognizing the critical importance of the five core aspects of project development and internalizing Effective Critical Systems Thinking to establish the right “mindset” and provide fundamental guidance amid the complexities of the automotive industry.
Oh, no, it is not “easy” or “simple”—if it were, anyone could do it. Taking on such challenges is tough, which is exactly what we do in this industry.
I am a project manager (Project Manager Professional, PMP), a Project Coach, a management consultant, and a book author. I have worked in the software industry since 1992 and as a manager consultant since 1998. Please visit my United Mentors home page for more details. Contact me on LinkedIn for direct feedback on my articles.