*Author: Peter Li Chengxian
Preface
With the trend of software-defined cars, “rapid delivery” and “OTA” have become industry consensus on one hand; on the other hand, although the “delivery quality” can moderately decrease, there still needs to be a bottom line. The conflict between these two has exceeded the ability range of the traditional ASPICE development process system. Can “agile development” solve all this? How can these two be combined, or can they be combined?
Challenges and thinking of software development system
Challenges and pain points
Recently, a small survey was conducted within the company, and there are still many pain points in the software development process. Here are some “pain points” from the perspective of “management” and the corresponding reasons.
Development “not good”
- A was defined, but it turned into B when implemented: There is a lack of communication between the product definition and implementation, and the deliverables are only visible in the final stage. It is too late to suggest changes.
- The milestone is approaching, and there are still many problems: The software development process is not transparent, making it difficult to control.
- After going online, the after-sales problems are urgent: The compression of the project schedule has a significant impact on non-essential links, seriously affecting quality.
Market changes “too fast”
- A is defined, but halfway through, it is desired to change to B, which is basically impossible: In traditional waterfall development, the later the process goes, the higher the cost of change.
- It is planned to go online in one year, but it is difficult to change to 8 months temporarily: In waterfall development, if the entire process is not completed, there will be many quality issues, making it basically impossible to deliver.
Delayed
- The period from requirement proposal to delivery is too long: A single function involves multiple professional departments, and the stakeholders are complex. The communication cost is too high. The function development process chain is relatively long, involving 10+ links from planning to delivery.
What has Tesla done in the industry?
First of all, Tesla did not adopt ASPICE. The following is the job description of Tesla’s Software QA Engineer, which is testing. If ASPICE is adopted, there will be dedicated personnel to ensure and optimize the process.
So how does Tesla do it? From various channels of evidence, Tesla solves this problem through “agile”. Tesla’s senior management team mostly comes from Silicon Valley, where the software culture is agile, so Tesla’s design, development, production, and organizational structure are all agile forms.
For example, Tesla’s adaptive air suspension was delivered in only one iteration from requirement to delivery [1]. Judging from Tesla’s monthly small iteration rhythm, it is estimated to be online in 1-2 months.
For example, Tesla’s organizational structure ceased to exist after Musk sent the following email, and only has formal significance: “Communication should be accomplished through the shortest path, not the “chain of command”. Any manager who tries to communicate by forcing the “chain of command” will soon find that they have to work elsewhere.”
So, many times, Tesla is like an “alien” that we may not be able to learn from, so how do other “normal” companies do it?
First, internet companies:
- Tesla, Apple, and Google all use agile methods, which basically do not need to be verified. Apple’s organizational structure was already “agile” in 2012 [2], and Google successfully introduced “agile” into AdWords development in 2006 and published related papers, which were included by the IEEE [3].
Then, automotive components giants:
- Since at least 2020, Aptiv has fully promoted “agile” globally and hired consulting companies to customize the AutoScrum agile framework. Its website also shows that it has applied agile methods in fields such as “active safety”, “autonomous driving”, and “vehicle connectivity” [4].
- Bosch announced in 2015 that it was transforming into an agile organization, and the management team began working in an “agile” manner first [5][6].
- In 2020, Continental also announced a comprehensive transition to agile methods and culture, with its VNI department leading the global pilot test [7].
Automakers are no exception:
- Mercedes-Benz has written “agile organizational culture” into its corporate strategy [8], and its subsidiary Mbition has also begun producing vehicles in an agile manner and requires its suppliers to also use agile methods. Its homepage http://mbtion.io has a message that states:”The essence of our Way-of-Working (WoW) is being agile when it comes to applied values and principles.”
- Volvo has been shifting towards agile development in global vehicle R&D since 2017 [9], and has been using fully agile methods to build new mass-produced models since 2020.
- BMW’s Intelligent Cockpit and IT department also use agile methods, with the IT department achieving 100% agility in 2019 [10].
Our Thoughts and Approach
Based on industry practices, as well as our understanding of agile and ASPICE, we believe that shifting to agile development, and building a software development system based on DevOps and an engineering culture, is the solution to the above pain points.
Agile Research
Since we mentioned “agile,” although there is plenty of information about “agile” on the internet, I will briefly share my understanding.
Overview of Agile
- A philosophy originating from “Lean,” began in 2001, initially only used in software development, and has now been applied to areas such as production, retail, human resources, budgeting, auditing, and organizational forms.
- Sweeping the globe in the 21st century, the largest five internet companies Amazon, Apple, Facebook, Google, and Microsoft all use agile.
- Many non-profit organizations around the world provide related training and certification services, such as the Scrum Alliance, Agile Alliance, and PMI (Project Management Institute).
- Mainstream issue tracking tools natively support agile development, such as Jira, Teambition (Ali), and TAPD (Tencent).
The core “philosophy” of agile is as follows:
It is important to emphasize the last sentence here: “Although there is value in the items on the right, we value the items on the left more.” This does not mean that the items on the right have no value, but rather that if you agree with the value on the right, the value on the left is even more important.
Characteristics of Agile Development Process
- Key roles: Product Owner, Scrum Master.- Cross-functional team: A team should possess all necessary roles.
- Rapid iteration: Breaking requirements into smaller pieces, delivery can be made in 2-6 weeks.
Agile has the following advantages (from the 2020 Global Agile Report):
Now we will elaborate on specific advantages of Agile.
Detailed advantages of Agile
1) Agile engineering practices can drastically improve code quality. After 1.5 years of implementation in a fintech group, the ratio of issues/stories decreased from 0.4 to 0.16.
- Test-driven development: Write test cases before writing any code; the test cases need to be able to run completely automatically. According to research by IBM and Microsoft, this approach can reduce bugs by 40%-50%[11].
- Pair programming: Two programmers work at one computer; one writes code, and the other checks the code in real-time. The roles switch regularly. This approach has lower productivity (15%), but fewer bugs (15%).
2) Agile development can speed up delivery. After 1.5 years of implementation in a fintech group, delivery cycle decreased from 75 days to 42 days.
3) Agile development improves software development transparency by visualizing project management and other measures, greatly improving management efficiency and further promoting production efficiency. After 1.5 years of implementation in a fintech group, the average number of user stories per person increased from 2.6 to 4.3.
4) Agile and OKR: The two are naturally complementary, and some companies directly call OKR “Agile” goal management. The team culture of both emphasizes:
- Self-organization: After completing necessary work, the team decides what to do on their own.
- Self-motivation: More communications are initiated from bottom to top, fully tapping individual initiative.
Here we will further explain a benefit. In a good Agile team with self-motivation and self-organization, the number of managers will decrease, which benefits the entire organization’s flat structure.### Key challenges in Agile transformation
Agile is great, but there are significant challenges to successfully transform, according to statistics from the Agile Annual Report.
Here are two key points I’m focusing on:
- Lack of leadership support: Implementing Agile requires adjustments to the organizational structure, which requires leadership support. Simply put, in a SCRUM team, there are people from various functional teams such as product, development, testing, and integration. Why should they listen to commands? Therefore, the SCRUM master needs to have accountability or significant authority.
- Organizational resistance to change: There are three aspects to this issue. Firstly, accepting new concepts and processes can be difficult for many people, and it can be painful during the initial transformation period. Secondly, Agile emphasizes quantifiable data, which exposes “old hands” or “slackers.” They will naturally resist this transition. Thirdly, after Agile transformation, the self-drive of the entire organization becomes stronger, and fewer managers are needed. Where should these people go? Internal resistance is inevitable.
Common problems that may arise in Agile transformation
There are various problems that may arise during Agile transformation, and I will discuss two of them:
- Temporary productivity decline (2-3 Sprints): At the beginning of Agile transformation, many new habits need to be developed, and many new processes need to be followed, resulting in temporary productivity decline. But rest assured, generally after 2-3 Sprints, efficiency will significantly improve.
- Agile is prone to degradation: After some organizations have implemented Agile for some time, for example, when stand-up meetings are held, KANBAN is established, and Scrum is up and running, they may gradually slack off, and efficiency may decline. This is mainly because “Agile” is a “value” rather than a “method,” and using only Agile methods is not enough. There is a saying that goes, “Don’t do Agile, be Agile,” which means this. So how can we ensure that the values of “Agile” are fulfilled and maintained? It depends on the “engineering culture,” which will be described in detail later.
Agile and ASPICE
I’ve talked a lot about the benefits of “Agile,” but in the automotive industry, “ASPICE” is the big brother. This section will cover how to combine these two.
Can Agile and ASPICE be combined?
The answer is: yes. Many companies in the industry use these two together, such as Aptiv. But I have a question, “Why combine them?”
First of all, let’s talk about why we use “ASPICE.” The answer is also apparent: because the customer fathers ask for it. Without ASPICE certification, many OEMs won’t give you the project.Translate the following Chinese text in Markdown to English text in Markdown with professionalism, retaining the HTML tags in Markdown and only outputting the results.
Then, why should we use “Agile”? The answer is obvious: we’re being forced by the customers. They keep changing requirements, compressing delivery cycles until they want it tomorrow, and so on. If we’re not “Agile”, how can we survive?
So, what happens when ASPICE is combined with Agile? In the industry, Agile dominates the entire development process, and ASPICE falls into a formality. Because they conflict in terms of “values.”
Those who understand ASPICE know that:
- ASPICE pays more attention to documents: documents here refer to evidence that can be checked by third parties. ASPICE Level 1 certification is based on your document outputs (outcomes) to infer whether you’ve been following Base Practice. If you don’t have these, you can’t pass Level 1.
- ASPICE pays more attention to processes and plans. GP (Generic Practice) 2.1.1~2.1.6 basically talks about processes and plans. For example, GP2.1.6 clearly states: Suitable resources must be identified, prepared, and scheduled to ensure that the process proceeds as planned. You should note that GP2.1.1~2.1.6 are necessary conditions if you want to pass ASPICE Level 2 certification.
Furthermore, one of the great advantages of implementing “Agile” is to “improve customer satisfaction”. You give the customers something from time to time, let them make suggestions, and then make changes according to their suggestions. Can they be unhappy? After the customers are satisfied, what else do we need ASPICE for?
ASPICE’s various drawbacks
ASPICE has been in the automotive industry for many years, and its benefits should be obvious to everyone: it covers the engineering process comprehensively, can help and guide software development, and improve delivery quality. Here, I will mainly talk about its drawbacks. However, before that, let me share a joke and personal experience.
One day, a software engineer met God, and God said to him, “I can grant you one wish.” The engineer thought for a moment and said, “I want to do a good project.” God thought for a moment and granted the engineer “Immortality.”### As a “software engineer”, it’s really hard to do a good project, but I was lucky to meet one. Around 2013, together with 5 other colleagues, we worked on a TBOX project for about 3 months and delivered it to testing. The quality was surprisingly good, so good that the QA came over and asked why there were no problems with the climbing curve of our project’s data, even though we had only a few bugs at the time, and then we had no bugs again.
However, when this project went through ASPICE, it did not pass… There were a lot of issues submitted.
The above is my personal impression of ASPICE. Next, I will talk about the shortcomings of ASPICE.
Shortcoming 1: Outdated Management Philosophy
“Agile” is a consensus on “values” reached by a group of excellent software engineers, which is more about inspiring individual initiative. “ASPICE” was jointly formulated by more than 20 European OEMs to guide component suppliers. Due to the inherent distrust of one party to the other, more emphasis is placed on “managing and constraining the laziness of human nature”. Which one is better is obvious.
Shortcoming 2: Heavy and Inflexible
- Three to five times the workload: A project that strictly follows ASPICE is three to five times the workload of a regular project. This is the result of the practice of many Tier 1 companies. If you don’t believe it, you can try it yourself.
- Traceability-looking good but difficult in reality: Almost every process in ASPICE talks about bi-directional traceability (Traceability). Most projects either link all requirements to one module, or take a small module to do this. In engineering practice, Traceability can indeed help identify problems, but the cost-effectiveness is extremely low. Do you only look at the requirements once when you do architecture design as an architect?
- What to do when changing requirements or refactoring: At my previous company, I once worked alone on a large module for 2 months, with a code volume of about 40,000 lines, including a few thousand lines of code for generating code. Then, within 2 months, I designed and wrote code while refactoring the design whenever the code didn’t work, and did it 3 times in total. If it were done according to ASPICE, what should I do?
Shortcoming 3: Driving away excellent talents
In this era of “software-defined automobiles,” excellent software talents are scarce. How to attract them is a great question. If we still drive them away, what can we do?The following is the English markdown text based on the provided Chinese markdown text, preserving the HTML tags inside the markdown:
The image above is of the Alibaba wizard “Duo Long,” who single-handedly maintained Taobao’s search engine from 2003-2007, reaching the pinnacle of his programming career. The value system of extraordinary engineers such as “Duo Long” includes the following:
- Sense of accomplishment: implementing a complex feature, solving a difficult problem
- Pride in the robustness, maintainability, and scalability of their own code
- Bragging: “They’re still using code I wrote 10 years ago.”
However, following ASPICE, the value system required of exceptional engineers has changed to the following:
- Sense of accomplishment: completing all of my documents (in a broad sense)
- Pride in strictly adhering to the process and not causing trouble for QA
- Bragging: (I can’t think of anything…)
As a result: “Sorry, I think I’ll leave this company after all.”
ASPICE vs. Agile Summary
In dealing with the “pain points” of the first chapter, ASPICE can effectively address quality issues, but it makes no contribution to the rapidly changing market and can also extend delivery cycles. Agile, on the other hand, can address all “pain points.”
Engineering Culture and DevOps
Engineering Culture
Establishing an “engineering culture” within a company is the fundamental guarantee of Agile methodology. The essence of the “engineering culture” is centered around “engineers.”
From a personal perspective, the main points can be summarized as follows:
- Quality-oriented: Engineers are fully trusted and are not held accountable if delivery standards are not met. Excellent engineers have high self-expectations, and they are often unwilling to release subpar work. At this point, their wishes should be respected, and they should not face repercussions, as they have usually tried their best.
- Pursuit of new technologies: Use and pay attention to the latest technologies and tools, and allow for the time cost associated with trying new technologies. There are risks of failure when trying new technologies. Only focusing on improving efficiency while unwilling to accept the potential consequences is just being dishonest.
- Focused time: Minimize unnecessary meetings and other interferences as much as possible. Otherwise, the engineer’s “inspiration” may be interrupted. A helpful tip is to leave messages instead of making phone calls or going directly to someone in person whenever possible.### DevOps
DevOps, with its swift and agile iteration, is a major topic in the industry. Some key points are summarized as follows:
- Direct triggering of code submission to eliminate waiting time and provide quick feedback
- Each change corresponds to a delivery pipeline, making debugging and problem identification easier
- Highly efficient automation of the entire development process with stable, rapid, and predictable results
- Continuous automation regression testing to improve delivery quality
- Facility sharing and on-demand provisioning to maximize resource utilization
Conclusion
Agility is taking over the world, and the automotive industry is no exception!
References
- ^1 https://www.36kr.com/p/847294138930688
- ^2 https://www.forbes.com/sites/stevedenning/2012/02/03/is-apple-truly-agile/?sh=d209df6641e6
- ^3 https://www.agilearena.net/google-case-study-agile-software-development/
- ^https://www.aptiv.com/en/careers/competencies/join-our-agile-revolution
- ^4 https://flyntrok.com/2020/07/07/agile-owl-edition-3/
- ^5 https://hbr.org/2018/05/agile-at-scale
- ^6https://www.continental.com/en/press/press-releases/2020-10-21-new-project-organisation-vni-238392
Internal Tech Forum
Establishing a full communication and exchange atmosphere for technical issues within the company. A simple and rude way to judge whether a company has a technical atmosphere is to see what those hundreds of people are talking about in the group, is it often technical exchange and sharing? Or are they just administrative notices?8. ^7 https://www.daimler.com/company/strategy/
- ^https://www.forbes.com/sites/stevedenning/2020/01/26/how-volvo-embraces-agile-at-scale/?sh=50690f454cf0
- ^https://www.itpro.co.uk/agile-development/31552/how-bmw-embraced-agile-to-hit-new-speeds
- ^https://zhuanlan.zhihu.com/p/257174601
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.