In our previous blog post we covered the common concerns for stakeholders with agile transformation and how they can be addressed and overcome. In the 5th and final blog post of this series, we discuss the relationship between Automotive SPICE and Agile Engineering and how they contrast and complement each other.
Nowadays, OEMs develop products with a network of suppliers and partners at locations worldwide. In addition, there are challenges such as ever-shorter development cycles, more and more complex products, and an increasing amount of software elements. This requires complete process control in all company areas. Automotive SPICE (ASPICE) was published for this purpose by the Special Interest Group Automotive to enable a uniform evaluation of processes. In this blog post, we first explain the ASPICE basics and then give insights into how ASPICE and Agile Engineering can contradict or complement each other.1
Automotive SPICE consists of a process reference model and a process assessment model, whereby knowledge of the process assessment model is enough for practice or for companies. This model evaluates the process maturity and contains two dimensions: process and maturity. The feasibility of the process is determined in the process dimension. The six-step maturity level dimension assesses the process capability and thus the level achieved.2
The evaluation is carried out in four stages:
- N: Not achieved
- P: Partially achieved
- L: Largely achieved
- F: Fully achieved
The client specifies up to which level the assessor must assess the company. Unlike suppliers, OEMs do not evaluate their own companies. Nevertheless, OEMs use ASPICE as input for supplier selection. At this point, it must be mentioned that system and module suppliers also evaluate their component suppliers.
ASPICE in product development process
ASPICE originally comes from software development, in which the processes can be fully evaluated. We see a need to catch up in mechanical and hardware development. Although the “SPICE for Mechanical Engineering” exists for mechanical development, it must first be integrated into ASPICE and is therefore not yet a fixed component of the maturity model. To cover the entire product development process (PEP), we can imagine an additional evaluation of the hardware development, which does not yet exist.3
Generally, ASPICE is about “properly” developed software in which the implementation status of requirements should be transparent and traceable. This ensures, for example, that a newly hired employee can trace the requirements and quality of the developed software even years later. To understand whether ASPICE and Agile Engineering can be combined, we must first understand the process abstraction.
How does ASPICE relate to Agile Engineering?
At the beginning of the process abstraction, the question of what should be done is clarified. This is followed by how the process must be implemented. Let’s consider the following example: Companies maintain the versioning of work products with the use of certain tools (Fig. 1). The maintenance itself is a higher level and describes what should be done, whereas the use of a tool describes how it should be done. ASPICE is here on the “what” level. Agile Engineering can be assigned to both the “what” and the “how” levels, whereby most agile practices take place mainly on the “how” level. In practice, agile practices implement some of the SPICE principles, and SPICE principles serve as an abstraction of the agile elements.4
Fig.1: Explanation of the term “process” at three levels of abstraction4
“ASPICE needs a waterfall model for evaluation” – myth or truth? We’ve just learned that ASPICE is on the “what” level and therefore cannot predefine a life cycle model. Thus, neither consequential times at which work products should be available nor other types of activity sequences are defined. Instead, ASPICE requires the selection and use of a reasonably chosen lifecycle model that defines such sequences. The actual and meaningful selection is a decision at the “how” level of the project. Here we see a good interaction between Agile Engineering and ASPICE.4
How does this complement Agile Engineering?
- Project management
- Problem management
- Change management
The Agile Engineering Framework points out the optimal coordination of practices and processes in the company in the field of “Processes and methods.” In practice, this can be implemented very well in daily, short meetings and thus addresses the communication required by ASPICE.
A great potential of agile process models lies in the amendment of process transparency. This requires a continuous traceability of processes and can be realized with JIRA, for example, where backlog entries are tracked within a time slot. Initial requirements should be traceable over several steps. However, if requirements are not exclusively in JIRA, it is difficult to guarantee traceability. The use of YIKANDU makes it possible to link various documents and sources with corresponding Jira tickets. This software connects to all tools involved in the development process via user-defined tool adapters, which can access artifacts of the development process and the associated traceability information. This agile methodology describes how a goal can be achieved and thus forms the basis for achieving the required ASPICE maturity level.7
Are there contrasts?
Nevertheless, certain areas in the agile manifesto are not sufficiently considered and thus encounter ASPICE non-compliance. The biggest difficulty here is quality assurance. An agile team needs freedom to constantly optimize working methods. If this freedom is restricted by external ASPICE guidelines, this can considerably hinder the learning process. To be able to work agile within the company, we recommend concentrating on the results only at the end of an iteration.6
Agile Engineering and ASPICE for your company
Companies can combine the best of both worlds and pursue the same goal with regular quality checks, daily stand-ups and employee motivation: Continuous process improvement. However, the implementation must be individually adapted to the company or the project.
If you would like to know more about agile engineering or discuss what we can do for your business, please contact Udo Lange
2 Verband der Automobilindustrie e. V. (VDA), Automotive SPICE®, URL: https://vda-qmc.de/software-prozesse/automotive-spice/.
3 intacsTM, Mechanical SPICE, URL: https://www.intacs.info/index.php/mechanical-spice.
5 Philipp Diebold, Thomas Zehler, and Dominik Richter. 2017. “How Do Agile Practice Support Automotive SPICE Compliance?” In Proceedings of International Conference on Software and System Processes, Paris, France, July 2017 (ICSSP’17), 5 pages. DOI: 10.1145/3084100.3084108 .