Searching for common ground: existing literature on automotive agile software product lines

The digital transformation of the automotive industry has a significant impact on how development processes need to be organized in future. Dynamic market and technological environments require capabilities to react on changes and to learn fast. Agile methods are a promising approach to address these needs but they are not tailored to the specific characteristics of the automotive domain like product line development. Although, there have been efforts to apply agile methods in the automotive domain for many years, significant and widespread adoptions have not yet taken place. The goal of this literature review is to gain an overview and a better understanding of agile methods for embedded software development in the automotive domain, especially with respect to product line development. A mapping study was conducted to analyze the relation between agile software development, embedded software development in the automotive domain and software product line development. Three research questions were defined and 68 papers were evaluated. The study shows that agile and product line development approaches tailored for the automotive domain are not yet fully explored in the literature. Especially, literature on the combination of agile and product line development is rare. Most of the examined combinations are customizations of generic approaches or approaches stemming from other domains. Although, only few approaches for combining agile and software product line development in the automotive domain were found, these findings were valuable for identifying research gaps and provide insights into how existing approaches can be combined, extended and tailored to suit the characteristics of the automotive domain.


INTRODUCTION
Agile development within So ware Product Lines (SPLs) is not new.Several studies treated this issue before.Perez and Silva [15] conducted a mapping study and a structured literature review on agile so ware product line engineering.Our study extends the ndings from the survey and includes references published a er 2011.We primarily focus on literature which addresses the automotive domain.e aim of our study is to increase the understanding on how agile so ware development (ASD) might be integrated within an automotive so ware product line.We limited the scope to automotive embedded so ware development.In this context it is important to consider deep integration between hardware and so ware, strong focus development processes, strong supplier involvement, and safety-critical functionality [17].Furthermore, speci c testing conditions, like tests in the real car, must be considered.
e presented study examines existing challenges which arise when agile development and SPLs are introduced in the automotive domain and how they can be overcome.
Existing literature deals with (1) the use of agile methods in the automotive domain, (2) the use of product line development in the automotive domain, and (3) the combination of agile methods and product line development.is study o ers an intersection of all three topics.Furthermore, the literature review helps to identify already existing solutions in published literature.e remainder of this paper is structured as follows.Section 2 describes the method used for the literature review.Section 3 reports the contributions of the collected studies.Section 4 summarizes key ndings as well as implications for practitioners.Section 5 presents conclusions due to the ndings.Finally, Section 6 summarizes the paper and gives an outlook on future work.ICSSP'17, July 2017, Paris, France Philipp Hohl, Javad Ghofrani, Jürgen Münch, Michael Stupperich, and Kurt Schneider

RESEARCH DESIGN
In order to conduct a literature review, two main research methods are applicable: A mapping study as well as a structured literature review.Both methods share some commonalities.For the presented study, the researchers conducted a mapping study as this method enables to identify gaps in literature to the speci c research eld [16,56].In addition, the mapping study allows to gain a wide overview of the research area [36].e research process described by Petersen et al. [56] served as a basis for our research.Researcher 1 (P.Hohl) was following the process primarily.is process was extended by the data collection of Researcher 2 (J.Ghofrani).He conducted a snowballing search to nd related literature which helps to answer the research questions.By including this literature and combining it with the results from Researcher 1, we achieved a broader view on the topic.With this, related research areas are taken into account.Whenever we deviated from the process, we describe our actions in the following subsections.
e process by Peterson et al. [56] is illustrated in Figure 1, whereas solid lines and white background de ne Process Steps and dashed lines with grey background the corresponding Outcome to each process step.In the rst step of the research process, research questions were de ned.In the next step, we conducted the search within suitable reference databases.erefore, a search string was constructed.We extended the results by two di erent searches, conducted by two researchers independently.In the third step, the papers were screened by applying de ned inclusion and exclusion criteria.Whenever, it was not clear how to categorize a paper, it was discussed by Researcher 1 and Researcher 2 in a review meeting.e abstracts were screened in detail and a mapping process was executed as a last step in the mapping process.

Research estions
e general question that guides this mapping study is: What is the state-of-the-art to combine agile so ware development and so ware product lines in the automotive domain, according to published literature? e question is divided into three research sub-questions to provide di erent views on the topic.Figure 2 summarizes the questions.

RQ 1:
In what ways can so ware product lines be combined with existing agile so ware development in the automotive domain, according to published literature? e goal is to investigate how ASD in the automotive domain could be extended by a SPL.Ideas, found in the existing literature, are evaluated, which foster an integration and focus on existing challenges for the introduction of a SPL.

RQ 2:
In what ways can agile so ware development be combined with existing so ware product lines in the automotive domain, according to published literature? is question investigates how current SPL development in the automotive domain could be extended by agile development approaches.Ideas found in the existing literature are evaluated, which foster an integration and focus on existing challenges to introduce ASD.
RQ 3: Are there any suitable concepts from agile so ware product lines to adapt within the automotive domain, according to published literature?To complete the picture, this question identi es how concepts for Agile So ware Product Lines (ASPLs) and agile embedded so ware development can be adapted to the automotive domain.

Conducting the Search
is section describes the research process for the mapping study executed by Researcher 1 and, furthermore, describes the research process applied by Researcher 2. e individual results were combined and screened as described in Section 2.3.

Search Process
Applied by Researcher 1. e used research process based on Petersen et al. [56] is divided into ve steps.ese steps were executed in a sequential order: Selection of databases.e selection of databases is essential to make the research outcome as comprehensive as possible.Eight databases were selected for the mapping study: Scopus, Science Direct, IEEE, ACM DL, Springer Link, Wiley Online Library, World Scienti c, and Google Scholar.With these databases, a comprehensive search was conducted to avoid bias [56].Although Scopus covers IEEE Xplore and Elsevier, the two databases were included to verify the quality of the search strings.
De nition of the search string.e construction of the search string for the mapping study was conducted as follows: First, three main keywords were selected.For these three keywords, synonyms and a corresponding word family were de ned (cf.Table 1).

Table 1: Overview search keywords
Search keyword 1 "so ware product line(s)" Synonyms "so ware product line engineering" "product line(s)" "so ware product line development" Word family "so ware product line engineering" Search keyword 2 "automotive" Synonyms "regulated domain(s)" Word family "car manufacturing" "car development" Search keyword 3 "agile so ware development" Synonyms "agile methods" "agile practices" Word family "agile so ware development" e constructed search string: ("so ware product line" OR "soware product lines" OR "so ware product line engineering" OR soware product line development" OR "product line" OR "product lines") AND ("automotive" OR "regulated domain" OR "regulated domains" OR "car manufacturing" OR "car development") AND ("agile so ware development" OR "agile methods" OR "agile practices") e shape of the search string was adapted to the selected databases, since search options di er and are speci c for each search engine.
e search was conducted using titles, abstracts and keywords.

Search Process
Applied by Researcher 2. Researcher 2 conducted a systematic literature review using the snowballing method as a systematic approach.erefore, he was following the "Guidelines for Snowballing in Systematic Literature Studies and a Replication in So ware Engineering" by Wohlin [72].
Identify a start set of papers.is step identi es a start set of papers in order to use it for the snowballing procedure.e start set consists of literature which is related to the research.Wohlin [72] mentioned, that there exists no silver bullet for identifying the start set.To conduct the search it is necessary to include relevant papers.ose papers may come from di erent communities.
Selection of databases.Selecting databases which contain the related scienti c studies for ASD methods and so ware product line engineering is an important factor to achieve valid search results.Five databases were selected for the creation of the start set: ACM Digital Library, Web of Science, IEEE Xplore, Science Direct, and Wiley Inter Science.
Building a start set.An initial search string is built from the combination of related keywords to so ware product line development and agile so ware development.Keywords and corresponding words are de ned in Table 2. is results in the following search string: ("Agile" OR "SCRUM" OR "Kanban") AND ("so ware") AND ("product line" OR "product family" OR "reuse" OR "variability") AND ("methode" OR "development" OR "progress" OR "engineering") e shape of the search string was adapted to the selected databases.In total, 26 studies were identi ed and build up the start set for the Systematic Literature Review using the snowballing approach.
Performing the snowballing.For snowballing, the ReviewR tool, was used. is tool is an in-house development of the So ware Engineering Group of Leibniz Universität Hannover to conduct snowballing.e tool manages the search iterations and performs the snowballing within a Scopus database.Five iterations with forward and backward snowballing were performed.If the title and the abstract of the publication contains any combination of agile methods and SPLs it is included for the next iteration.We excluded duplicates, studies older than 2001 and studies which are only mention one keyword.

Definition of Inclusion and Exclusion Criteria.
To eliminate studies which are not relevant for answering the research questions, exclusion criteria were applied [56].
Inclusion criteria: • e paper discusses agile so ware product line development in the automotive domain.
• e paper discusses product line engineering in the automotive domain.
• e paper discusses techniques to speed up feature development in the automotive so ware development.

•
e paper discusses agile so ware development for embedded so ware.
• e paper discusses agile so ware development in combination with the use of SPLs.
• e paper is wri en in English or German.Exclusion criteria:

•
e paper was wri en before 2001.

•
e paper has no accordance with at least two of the search keywords.
• e paper focuses on a speci c tool. ( is study refers to methods and not to speci c tools.) • e paper is not accessible.• Duplicated papers.

Selection of Researchers to Conduct the Study.
Due to the fact that the mapping study is part of a PhD project, Researcher 1 conducted the mapping study.Researcher 2 conducted a separate study and added his literature to extend the dataset and to give a broader view with respect to the related research areas.

Execute the Research.
As described in the previous steps, the research was executed in the selected databases.

Screening of Papers
In this step, the previously de ned inclusion and exclusion criteria were used to select the most suitable set of papers.e screening process was divided into several ltering steps as shown in Figure 3. Papers were included if they ful lled the inclusion criteria.is ltering was applied to the results of Researcher 1 and Researcher 2. In the rst step of the screening process, the inclusion and exclusion criteria were applied on the title and keywords of the identi ed studies.Duplicate papers were excluded as well.Whenever Researcher 1 was not able to include or exclude the paper, he marked the paper as "unclear".In this ltering step, 23 papers were classi ed as unclear.ese papers were reviewed by Researcher 2 and categorization was discussed with Researcher 1 in a review meeting.If the paper was still unclear a er this process, another researcher reviewed the paper and decided to include it to one of the given categories or exclude it.is ltering step leads to 181 remaining papers.
In addition, Researcher 2 separately searched with a broader approach (cf.Section 2.2.2) to nd successful implementations and experience reports examining the combination of ASD and the use of SPLs. is search resulted in a total number of 91 resources.
Both data sets were combined and Researcher 1 deleted the double references in the dataset.For the remaining 246 references, the abstracts were extracted and stored in the reference management and citation tool Citavi.Researcher 1 evaluated the abstracts.is last ltering step led to a nal set of 68 papers.

Categorizing the Studies
For later data extraction, the results of this study were categorized.To analyze, categorize and to sort the collected literature, we used the tagging and coding functionality in the reference management and citation tool Citavi.e rst step in Citavi was to read abstracts and identify keywords and concepts re ecting the contribution of the papers [56].e selected keywords were used for clustering the papers into categories [56].According to Figure 2, three main categories were de ned.e output of this step gave an overview of the covered topics and areas of the selected papers and de ned the current state of research at a granular view.

Data Extraction
For each speci ed category, the data of each paper was extracted.
e rst step of data extraction gathered standardized information like author, type of paper and publication channel. is information was used to give an overview about the active participants in the considered area of research.Furthermore, the results showed frequencies of papers for each category.is enables us to identify gaps and possibilities for future research [56].
A er ge ing an overview of the papers, detailed data was extracted in order to answer the research questions.

reats to Validity
is section treats the identi ed threats to the validity of our study.
Research questions: We de ned the research questions to be unambiguously understandable.erefore, we reviewed the wording of the research questions several times.It would be false to a rm that our research questions cover the complete existing research on ASPLs, containing all related research areas.However, our research questions address an urgent issue in that eld.
Publication bias: Due to the fact, that only Researcher 1 was doing the screening process, we can not guarantee that all relevant primary studies were selected.It might be possible that papers were excluded in the ltering steps.For the data collection, we mitigated this by adding the literature from Researcher 2. Furthermore, a review session was introduced, to discuss the "unclear" marked publications.
Search conducted: e shape of the search string was adapted to the selected databases, since search options di er and are speci c for each search engine.We mitigate the threats introduced by this adaption by using eight databases.Although the database Scopus covers IEEE Xplore and Elsevier, the two databases were included to verify the quality of the search strings. is threat was mitigated further, by adding the literature from Researcher 2.
Data extraction: Data extraction and categorization of the papers was done by Researcher 1. is could introduce bias and incorrectly classi ed papers.Researcher 1 conduct this classi cation two times to avoid a wrong categorization.

REPORTING THE REVIEW
To visualize the results, we divided them into the three categories from Figure 2. e following Table 3 contains the number of studies according to the publishing date.As shown in Table 3, a lot of research focus on related research areas.
e number of papers have increased since 2004.It furthermore illustrates that papers are rare with respect to the automotive domain.Only in 2014, four papers focus on ASD and address the automotive domain.2016 [60] However it seems, that no paper handles the combination of ASD in the automotive domain with respect to SPL development.
is will be analyzed in more detail.e following subsections will derive results from the literature review to answer the research questions:

Research estion 1
In what ways can so ware product lines be combined with existing agile so ware development in the automotive domain, according to published literature? e published literature does not provide signi cant information or approaches on how to adapt existing ASD approaches to SPL development in the automotive domain.erefore, it is di cult to answer the research question based on information from existing literature.However, several publications were found that focus on the adaptation of ASD approaches to the speci cs of the automotive domain.As SPLs are a common approach in the automotive domain it could be argued that this adaptation might at least implicitly consider also product line development.e ndings can be summarized in the following: (1) Adapting ASD in the automotive typically concentrates only on selected agile elements such as Continuous Integration (CI).e published literature does not show any recommendations to use a comprehensive set of agile elements and practices together in the automotive domain.(2) e majority of the published literature suggests that agile models and processes should get customized to the speci cs of the automotive domain before they are implemented in practice.(3) Several agile models and processes that are already customized to the speci cs of the automotive domain are proposed in the published literature.Examples are the Feedback Loop Model that especially considers the collaboration between di erent organizations (such as OEMs and suppliers) and the Agile Hybrid Assessment Method that especially considers safety-criticality constraints in the automotive industry.
ese methods and processes include interesting new concepts such as virtual integration on the system level.
iel et al. [64] analyze the combination of ASD and plan-driven processes which could be seen as a typical characteristic of current automotive so ware development.ey emphasize that a combination could be bene cial under certain conditions such as rigid quality and safety requirements [64].As a solution, iel et al. [64] suggest to introduce selected agile approaches to automotive systems engineering.is suggestion is also supported by the "Agile in Automotive Survey" from Kugler and Maag [71].
e survey highlights that many companies recommend to only introduce single agile elements into existing and proven development cycles.In addition, they recommend not to apply a purely SCRUM approach in practice.Instead, they emphasize that pure SCRUM is o en not applicable due to the context factors and the development environment.
Schlosser et al. [60] de ne an upcoming challenge in the automotive so ware development.
ey identify the necessity of shorter development time for multiple so ware variants by considering constraints of a high cost pressure.
ey further argue that more incremental so ware deliveries are necessary for a quick response from customer which shortens the development time and save money [34,60].In addition, the agile element of CI provides a quick response with respect to functional aspects [1,60,70].In order to integrate further agile elements into the automotive domain, di erent models and processes are introduced including a (1) Feedback Loop Model, the (2) Agile, Hybrid Assessment Method for the Automotive Industry and the (3) Mega Scale So ware Product Line Engineering: e concurrent Feedback Loop Model (1) introduces feedback loops for di erent organizations to enable cooperation [29].e cooperation (including communication) between di erent organizations is managed by a new architect role to shorten the development time.e reduction of time is validated in a case study.In turn, the case study reveals several drawbacks [29].
e Agile, Hybrid Assessment Method for the Automotive Industry (AHAA) (2) considers safety critical development.So ware quality is important for so ware critical companies like in the automotive domain to ensure high reliability and maturity of so ware.Plan-driven practices are assessed with respect to so ware process improvement like CMMI and ASPICE [63].
Additionally, the assessment suggests agile based improvement solutions within the automotive domain.Furthermore, the System Architecture Virtual Integration (SAVI) initiative helps to improve the agile development.In SAVI, CI is concurrently operated within the so ware development process.Integration starts with the earliest available system models into a virtual integration environment.With a virtual integration strategy vendors are more closely tied to the project [62].

Research estion 2
In what ways can agile so ware development be combined with existing SPLs in the automotive domain, according to published literature?Research estion 2 could not be answered by the selected ndings.e majority of the published literature is concerned with SPLs within the automotive domain without considering an adaptation to ASD.Several variant management approaches and appropriate methods and processes to handle variants are discussed.Some product line approaches are presented that might be helpful in understanding what to consider when combining with agile development.Understanding binding times, for instance, might help to be er organize CI mechanisms.
According to Wozniak et al. [73], the automotive domain is the most challenging environment for systems and SPL engineering.Millions of di erent so ware variants exist, where each constraints a large complexity.e complexity is based on the large number of variation points within the product [21].Four di erent binding times may be distinguished: programming, integration, assembly, and runtime.All of them are used in the automotive domain.is leads to a "very large number of individually complex products with incomparably rich feature variation among them" [73, p.336].In order to handle the complexity, the Mega Scale So ware Product Line Engineering (MS-SPLE) (3) approach is introduced. is approach is applied for large product sets with complex products and complex feature variations like the automotive domain.MS-SPLE is a possibility to manage, e.g., calibration parameters for the so ware variation mechanism and the complexity management.However, ASD is not taken into account within MS-SPLE [73].

Research estion 3
Are there any suitable concepts from agile so ware product lines to adopt within the automotive domain, according to published literature? e published literature provides several sources of information on concepts for the combination of ASD and SPLs.ese concepts could be used as candidates for the adoption in the automotive domain or they might reveal helpful insights for an adaptation in the automotive domain.e ndings can be summarized as follows: (1) Several concrete methods and models are described that combine agile and product line concepts.An example is ScrumPL which supports iterative domain and application engineering.(2) Speci c cross-cu ing aspects such as architecture, scoping, or communication are considered in the published literature with respect to the combination of agile and product line development.An example is a scoping approach that allows conducting a commonality and variability analysis in each iteration in order to constantly understand the implications of new or changing requirements.(3) Several publications present expected or experienced bene ts of agile product line development.Among others, frequently mentioned bene ts are increased exibility, shortened development cycles, and in consequence a reduction of technological, customer, and market risks.
(4) Di erent strategies exist to introduce a combination of agile and product line development.Although it is di cult to say with certainty, the primary strategy seems to be introducing agile into well-established SPL development.(5) e combination of agile and product line development signi cantly depends on customer needs (such as availability or cost e ciency).
Besides concepts from agile product line development the published literature includes information on agile development in embedded domains.
is information might be helpful for transitioning towards agile product line development in the automotive domain.
In 2007, Hummel and Atkinson [31] stated, that agile development and systematic so ware reuse have rarely been a empted in the same project.Pohjalainen [57] describes problems with the combination of agile and product line development based on the required upfront planning in SPLs, while agile method practitioners inherently want to avoid any heavy up-front planning [57].To overcome this incompatibility, Pohjalainen [57] describes a bo om-up approach to combine product line engineering and formal modeling with ASD.
Martini [43] mentioned, that agile and reuse practices do not hinder each other.Some sources emphasize the bene ts of introducing ASD practices to SPLs [26].Potential bene ts include the improved change management for requirements, the increased product quality with coincident decrease of development costs, or a reduced time to market [20].e development enriched by agile practices is o en referred to as Agile Product Line Engineering (APLE) [48].
Mainly two approaches for introducing APLE are reported: Either take an existing SPL process and introduce agility or take an agile process in order to tailor it for SPLs [66].e focus is primarily on introducing agile into well-established SPL rather than on the implementation of so ware reuse into an agile-oriented development [43].It is essential to develop a reuse strategy that complements the principles of agile development and to foster so ware reuse in combination with the practices of agile methods [31].Hanssen [28] concludes that a combination makes the organization more exible and thus capable of serving a volatile market with fast-changing technologies.Furthermore, this enables the organization to collaborate be er with suppliers [28].
e published literature can be structured by two di erent viewpoints: e technical viewpoint and the business viewpoint.
Regarding the business viewpoint, it is o en mentioned that it is essential to deliver high-quality so ware in time and within estimated cost and e ort as time to market is an increasingly important success factor for companies.It is, therefore, important to know, which parts of the so ware development process are able to become more agile and how to apply the agile practices to speed up the development [40].
One main goal with respect of the SPL is to satisfy a wide range of customer needs [3].Atherton and Collins [3] describe challenges of product lines and compare a planned development strategy against a haphazard reuse strategy for so ware components in aircra engines.ey describe di erent needs of military customers, who focus on capability and system availability.In addition, they consider commercial customers, who focus on minimizing life cycle cost.McGregor [45] emphasizes, that an entire customer satisfaction always requires a tradeo between exibility and so ware waste due to late rework of code and a late binding time of variability [38,46].e technical viewpoint can be divided into agile methods and models, which are already in use and agile aspects like documentation or scoping, which should be considered for a successful combination.
3.3.1 Agile Methods and Models.Di erent agile methods are described to combine agile so ware development and a reuse strategy of so ware components.
Well-known agile methods such as Scrum and XP are described in the literature.Furthermore, various papers present a tailored approach to use well-known agile methods.Lindvall et al. [40] describe a project which utilizes the XP approach.is is achieved by auxiliary processes in order to de ne the scope and to adjust delivery time in advance.With respect to Scrum, a new method called ScrumPL is introduced.Scrum lifecycle phases and the SPLE sub-processes are combined to form ScrumPL [59].In this tailored Scrum, domain engineering as well as application engineering processes are performed in an iterative way separated in di erent sprints [14].
Another approach of combining SPLs and agile development is the Feature Driven Approach with the use of Feature Models [2,58].
is hybrid method captures the initial view of the results of the commonality and variability analysis [45].In this approach, both disciplines are merged.As a result, feature orientation blends the bene ts of product line engineering with those of agility [35].As an extension of the feature model, the composite feature model is described by Urli et al. [69].eir solution relies on the de nition of composite feature models and the use of a model-driven evolution process to support it on large real systems [69].In addition, Trinidad et al. [68] evaluate the possible reasons why a feature model has dead features and how to evaluate feature models in general.
Neves and Vilain [48] present the idea of Test-Driven-Development (TDD) as the basis to combine ASD and SPLs.e usage of refactored agile practices lead to a reactive SPL.erefore, SPL evolves and acquires variability points on demand [48].Due to the speed up of the development, it is necessary to retest and certi cate some parts repeatedly [3].It is, therefore, essential to automate test procedures.Continuous Integration and Continuous Testing (CT) are necessary to test new working products in each iteration in a exible and rapid way.However, in agile methodologies, testing tools should be capable to test the developed so ware.It is a signi cant e ort to set up tools and to maintain the test environment [42].Ghanam et al. [26] extend the idea of TDD and describe tests not only in form of regression tests.ey rather describe the test approach as a way to determine commonalities in so ware systems of the same domain [26].

Agile
Aspects. is section presents cross-cu ing aspects like architecture, scoping, communication and safety regulations.
ese aspects should be considered in detail when combining ASD and SPLs.
Architecture.McGregor [45] suggests an architecture de nition practice that replaces the product line and agile practices focusing on the structure, commonality and variability.Typically, agile development disregards a detailed consideration of the architecture.However, in product line development, architecture is an important aspect to consider [4].It is necessary to nd the right tradeo between the management of architecture evolution and refactoring without sacri cing the principles of agility.Furthermore, architecture erosion should be avoided at any time [8].e use of proprietary architectures could help to avoid this.In contrast, Chong [9] promotes the adoption of open standards, rather than closed proprietary architectures.He mentions this as an essential economic driver for opening closed markets to competition [6,9].
Scoping.Ghanam et al. [22] introduce a new lightweight variability analysis technique.is enables to determine commonalities and variations between the new requirements and the existing ones.
e analysis is conducted in every agile iteration and not as traditional up-front [22].In addition, another lightweight approach is presented by Atherton and Collins [3].ey divide requirements into small pieces of functionality, categorize and priories them [3].
Communication.An important key factor for a successful combination of ASD and SPLs is communication [27].Intra-and inter-organizational communication practices and the awareness for so ware reuse are essential [43].Good communication is necessary within development teams, between teams, and the units these depend on, e.g., validation and business units [43].It is important to keep the communication overhead low [35].
Safety regulations.Kirchner and Hofman [35] conduct a study based on ndings revealed in the area of medical device development.In this area, they have to ful ll certain pre-requisites with regards to patient safety.Development organizations have to adhere regulations to comply with the law [35].Regarding regulations and standards, process descriptions and development documentation are required.However, this may become ine cient if the overhead to organize document writing, signing, reading, reviewing, and revising increase.A production of waste such as functionality that potentially never gets shipped to a customer should be avoided [35].
Regarding the combination of agile and embedded development, the published literature reveals that the motivation for using agile methods is o en characterized by market uncertainties, competitive pressures, and the need to shorten development cycles [53].
In the embedded domain, safety aspects are a prime goal to satisfy [32].erefore, the use of agile practices in regulated and safetycritical domains is still limited [32].With respect to the literature, the study of Kaisti et al. [33] nds no reason why agile methods could not be used in the embedded domain.XP and Scrum or a mixture of both are the wide-spread used methods [61].Eklund et al. [19] point out the necessity to consider di erent development cycletimes for hardware and mechanics.It is important to synchronize these cycles and to freeze the design at a quality gate and milestone.Traditionally, no or minimal changes are allowed.Subsequent processes like optimizing the manufacturing and sales are o en seen as more important.Nevertheless, so ware is strongly dependent on mechanical structures [19].ey further mention a long feedback loop with customers and management.Furthermore, a long-term predictability is hard to achieve with short-term agility [19].

DISCUSSION
We approached the issue of ASD in combination with SPLs in the automotive domain from three di erent perspectives.e rst direction was treated by Research estion 1. e question focuses on existing ASD in the automotive domain.It further examines, if SPL development could be combined to already existing solutions.Although none of the identi ed approaches addresses the existence or adaption of SPLs, we identi ed several approaches in order to integrate agile elements into the automotive domain.
e second approach to gain knowledge about the combination of all three search keyword, was treated in Research estion 2.Here we focus on existing SPLs in the automotive domain and spot on the combination with ASD. e results we found describe SPLs within the automotive domain but do not consider agile development approaches.A possible explanation is that combining agile development with existing product lines is challenging (consider, for instance, the need for synchronization with mechanical and electrical engineering).is might be the reason that the advent of agile methods in the automotive industry did not start in the area of product line development and no published literature is available on this aspect.Vice versa, there are areas in the automotive domain (e.g., entertainment so ware for the car) where it seems to be comparably easy to introduce agile development without product line development.is might explain that the study was more fruitful with respect to Research estion 1. Anyhow, the need to get more agile in the automotive domain and the lack of approaches with respect to Research estion 2 creates a very strong motivation to do a case study or some other empirical research in order to get answers to this question.
A key nding is that there exists no ready-made solution to combine ASD with SPLs in the automotive domain.It is therefore necessary to take the related research areas into account.In RQ 3, we identi ed challenges and possible solutions, which could be relevant for the automotive domain as well.e identi ed solutions given by the literature might be transferred to the automotive domain (cf.Table 4).

CONCLUSION
e literature review revealed that there is no approach speci cally tailored to the automotive domain handling the combination of ASD and SPLs.
Searching for existing literature about the introduction of agile methods in the context of automotive product line development was also not fruitful.Searching for literature that deals with introducing product line engineering to agile development in the automotive domain also did not reveal signi cant results.
However, looking at related domains provided many insights into how the combination of agile methods and product line development could look alike in the automotive domain.ese insights might help as starting points to modify automotive so ware development processes so that they can bene t from both, agility and systematic reuse through product lines.

SUMMARY AND OUTLOOK
Our work provides an overview on agile and SPL approaches in the automotive domain as well as their common ground.It further identi es the current gaps in the research and proposes speci c agile methods and practices for integration into automotive SPLs.Moreover, our work concludes that there is an existing gap in the literature with respect to agile SPL development in the automotive domain.
Altogether, our work reveals many elds for further research, such as organizational, process, and product-oriented challenges.It further helps to identify means for addressing speci c characteristics and restrictions of the automotive domain.
For future work, we aim at transferring the presented solutions to the automotive domain and evaluate them in existing development projects.As a result, we plan to create and evaluate a model for the adaption of ASD in the context of existing automotive SPL development.

Figure 2 :
Figure 2: Directions of research questions

Table 2 :
Overview search keywords for building the start set

Table 3 :
Publications by year