Achieving agility and quality in product development-an empirical study of hardware startups

Context: Startups aim at scaling their business, often by developing innovative products with limited human and financial resources. The development of software products in the startup context is known as opportunistic, agility-driven, and with high tolerance for technical debt. The special context of hardware startups calls for a better understanding of state-of-the-practice of hardware startups’ activities. Objective: This study aimed to identify whether and how startups can achieve product quality while maintaining focus on agility. Method: We conducted an exploratory study with 13 hardware startups, collecting data through semi-structured interviews and analysis of documentation. We proposed an integrative model of agility and quality in hardware startups. Results: Agility in hardware startups is complex and not achieved through adoption of fast-paced development practices alone. Hardware startups follow a qualitydriven approach for development of core components, where frequent user testing is a measure for early debt management. Hardware startups often lack mindset and strategies for achieving long-term quality in early stages. Conclusions: Hardware startups need attention to hardware quality to allow for evolutionary prototyping and speed. Future research should focus on defining quality-driven practices that contribute to agility, and strategies and mindsets to support long-term quality in the hardware startup context. © 2020 The Author(s). Published by Elsevier Inc. This is an open access article under the CC BY license. ( http://creativecommons.org/licenses/by/4.0/ )


Introduction
Startups, newly created companies producing cutting-edge technology, are an important source of technology innovation, and have a significant impact on the wave of digital transformation ( Jacobson et al., 2017 ). Despite stories of successful startups, most of them fail, primarily due to self-destruction rather than competition ( Crowne, 2002;Marmer et al., 2011 ). Without previous operational experience, startups often need to learn how to establish new roles, new connections to external stakeholders, and new processes and practices ( Stinchcombe, 20 0 0;Abatecola et al., 2012 ). In a startup company developing high-tech products, besides personal trait of startup founders and financial and market factors ( Giardino et al., 2015;Aldrich and Auster, 1986;Van Gelderen et al., 2005 ), product development is also a key factor characterizing the development of the startup Giardino et al., 2015;Tripathi et al., 2016;Giardino et al., 2016;2014a ). For instance, software research has shown interest in achieving effective Minimum Viable Products ( Nguyen-Duc and Abrahamsson, 2016 ) and managing technical debt ( Giardino et al., 2016 ) in the startup context. Even though the obstacles to success gradually become known and aware to entrepreneurs, the startup context poses several unique challenges to traditional product development and innovation methods .
The part of startup ecosystems that is relatively little explored in research is hardware startups. They include startup companies developing products and services with a value proposition based on an integral solution of software and hardware components ( DiResta et al., 2015;Jacobson et al., 2017 ). Hardware is a physical, tangible part of a system, or a system of systems (e.g., sensors, gateways, connectivity components, wearable devices, mobile phones), while software is a code-based, intangible part of the system (e.g., operating systems, server-side scripts, databases, algorithms). A typical example for a modern hardware system is a connected house, where the hardware part is implemented to measure, collect and transmit data, and the software part is https://doi.org/10.1016/j.jss.2020.110599 0164-1212/© 2020 The Author(s). Published by Elsevier Inc. This is an open access article under the CC BY license. ( http://creativecommons.org/licenses/by/4.0/ ) used to coordinate the operations of hardware, store and process the collected data. The barriers for starting a hardware company have never been lower, a result of the advanced development of hardware technology. Rapid prototyping, decreased component costs, small-batch manufacturing, and fundraising platforms have renewed the interest for hardware startups ( DiResta et al., 2015;Wei, 2017 ).
Hardware startups add additional complexity to software startups as they need to handle the development and integration of hardware parts into the offered products . Hardware products usually need to be secured and safe, which puts a focus on ensuring quality attributes of delivered products. Moreover, the quality of the whole product relies on the quality of its integrated components, both software and hardware modules. While it is known that software startups focus on speed and agility, remaining low priority on quality assurance, it is not known if the same practices occur in hardware-related product development. While knowledge from development of embedded products in established companies can be relevant ( Kaisti et al., 2013;Albuquerque et al., 2012 ), the "newness and smallness" nature of startups calls for an investigation and further, an adaption of existing methodologies and practices that are suitable to startup context ( Bosch, 2016 ).
Software startups are known for fast-paced development, with ability to handle uncertainty, react to changes in product and business development, and introduce flexibility in the process ( Garbajosa et al., 2017 ). The concept of agility in hardware startups might be different from pure software development, as hardware development typically involves a long development cycle and depends on a larger set of third-party vendors. The relationship between agility and quality might be more critical in some circumstances, for instance startup companies who deliver quality-driven products. For example, the Norwegian startup Prediktor Medical AS develops a glucose smartwatch that measures glucose level without penetrating people's skin. The product was quality-driven and has been developed under a market-pressure with a promised launch time. A recent industry survey also calls for systematic adoption of product development methodologies in hardware startups .
To this end, we seek to create a better understanding of workpractices in hardware startups by investigating the role of engineering activities, from idea conceptualization to a launched product. In particular, we will investigate factors influencing agility and quality, and explore commonalities and challenges. As mentioned by Jacobson et al. (2017) , literature regarding methods for hardware product development is scarce. We aim at exploring how agility and quality are managed in practice. This has motivated the following research question: RQ How do hardware startups achieve both agility and product quality during product development?
This paper presents the results from a qualitative survey investigating 13 early-stage European hardware startups. The work contributes to startup engineering research by focusing on hardwareintensive product development. The research provides early empirical evidence to agility in hardware startups, and simple qualityaware practices in the context of restricted resources. The work also builds the foundation for researchers and practitioners to further explore hardware startup engineering, which is still in a nascent stage.
The remainder of this paper proceeds as follows: Section 2 introduces the background of the study and relevant theoretical frameworks. Section 3 presents the research method undertaken and potential threats to the validity. Section 4 reports the results of the study, including transcribed citations from the participants. Section 5 discusses the results in relation to the research questions. Section 6 concludes the paper by answering the research questions and proposing directions for future work.

The context of high-tech startup companies
The term "startup" has been defined differently across various principles ( Steininger, 2019;Sutton, 20 0 0;Ghezzi, 2018;Unterkalmsteiner et al., 2016;Crowne, 2002 ). From the recurrent themes on startups, high-tech startups share common characteristics of organizations focusing on the creation of softwareintensive products, with little or no operating history, aiming to grow by aggressively scaling their business in highly scalable markets ( Giardino et al., 2016 ). The context of startups is long understood as a special organizational state. New companies generally involve new roles, and the "coordination of strangers" scenario often lead to low quality of performance ( Stinchcombe, 20 0 0;Abatecola et al., 2012 ). Sommer et al. (2009) highlighted that new companies often do not correctly foresee real opportunities or the best ways of addressing them, and so are forced to adapt and modify their approach over time. Giardino et al. (2014b) revealed that startups often fail to achieve the problem-solution fit during their execution. From early-stage, startups increase their learning curve and foster the establishment of survival determinants (i.e., successful practices and procedures) ( Abatecola et al., 2012;Hodgson and Knudsen, 2004 ).

Software product development in startup companies
Startups generally develop products in high-potential target markets without necessarily knowing what customers want ( Blank, 2013b;Rafiq et al., 2017 ). Increasingly more industries experience that new technologies become available to all players at the same time, hence the benefits of technology-driven innovations decrease. This has led companies to prioritize customerdriven development, which involves identifying new and unknown customer needs as well as meeting known needs ( Bosch, 2016 ). This relates to market-driven software development, where requirements tend to be (1) invented by the software company, (2) rarely documented ( Karlsson et al., 2002 ), and (3) validated only after the product is released in the market ( Carmel, 1994;Dahlstedt, 2003;Keil and Carmel, 1995;Rafiq et al., 2017 ). Products not meeting customer needs are common, resulting in failure of new product releases ( Alves et al., 2006 ). There exist several entrepreneurial theories and frameworks that can guide practitioners in their pursuit to lasting business growth, including "Effectuation Theory" ( Sarasvathy, 2001 ), "Discovery and Creation" ( Alvarez and Barney, 2007 ), the customer development approach introduced by Blank (2013a) , and the Lean Startup ( Ries, 2011 ).
Research on software engineering depicts that startup companies prefer to prioritize time and cost over product quality ( Yau and Murphy, 2013 ), neglecting traditional process activities like formal project management, documentation, and testing ( Giardino et al., 2016 ). Shortcuts taken in product quality, design, or infrastructure can inhibit validated learning ( Ries, 2011 ), in a context where customized development practices are necessary to manage the challenges posed by customer development methods. Inadequate use of software engineering practices might be a significant factor leading to the high failure rates of software startups ( Klotins et al., 2015 ).
Entrepreneurs are in general aware of the significance of how their products are built. Even though studies have found that startups are either reluctant to introducing process ( Coleman and O'Connor, 2008 ), or that they use their own mix of Agile and ad-hoc methods ( Giardino et al., 2014a ), many startups emphasized the importance of having good practices in building their products ( Sutton, 20 0 0;Giardino et al., 2014a ). Small early-stage software startups don't experience the same challenges as larger, more experienced companies, and the cost and time of implementing a rigorous Agile methodology may not provide big enough benefits ( Yau and Murphy, 2013 ).

Agility in product development
Agility as a concept is multi-facet and in many cases refers to the ability of an organization, a team, or a project to react to changes occurred to them ( Conboy, 2009 ). In a general sense, agility can be defined as "the capability to react and adapt to expected and unexpected changes within a dynamic environment constantly and quickly, and to use those changes (if possible) as an advantage" ( Bohmer and Lindemann, 2015 ). In software development, Agile methods have proven to be a powerful tool when the goal is to build a successful, profitable business model . When a company needs to quickly address market and customer needs, Agile processes have proven to be much more effective than traditional high-ceremony processes ( Wasserman, 2016 ). Since the birth of the Agile Manifesto (2001), with stated principles and practices of Agile methodology ( Beck et al., 2001 ), it has become a popular set of practices in the software industry to replace traditional, rigid, and heavy software development processes.
During the last decades, Agile in software engineering has been an extensive research area with an enormous amount of literature ( Dybå and Dingsøyr, 2008;Conboy, 2009;Abrahamsson et al., 2010;Díaz et al., 2011;Misra et al., 2012;Jalali and Wohlin, 2010;Da Silva et al., 2011 ). Existing studies provide the introduction and adoption of Agile methods and their variance in different organizational settings. They do not agree on a unified view of current practices, but offer a broad picture of experience and some contradictory findings ( Dybå and Dingsøyr, 2008 ). Benefits were reported in the following areas: customer collaboration, work processes for handling defects, learning in pair programming, thinking ahead for management, focusing on current work for engineers, and estimation ( Dybå and Dingsøyr, 2008 ). A recurring theme in studies on Agile development is human factors (e.g., team dynamics, team coordination, customer involvement, etc.) and their influence on Agile development. Much research reports experience of combining Agile development with other Software Engineering paradigms, such as distributed teams ( Jalali and Wohlin, 2010 ), product line development ( Misra et al., 2012 ), and user-centered design ( Díaz et al., 2011 ). The combination of product line development, with the focus on upfront investments, planning, design, and Agile methods, with the highlight of rapid and frequent changes, attention to the design is found challenging ( Misra et al., 2012 ). Several practices are investigated in the fusion of Agile methods into more rigid processes, including release planning ( Hanssen and Faegri, 2008 ) and the bottom-up application driven approach with automated acceptance tests ( Ghanam and Maurer, 2010 ).
Research suggests that Agile methods are suitable for software startups, as iterative development approaches are adaptive, with short lead time ( Pantiuchina et al., 2017;Paternoster et al., 2014 ). The adoption of formal sets of Agile practices and methods in startups is limited, often due to an excessive amount of uncertainty and high time-pressure ( Giardino et al., 2014a ). Startups often use a tailored version of Agile development, in many cases, the quick combination of Agile and other methodologies.

Engineering processes for embedded system development
Research on development processes in hardware startups is rare, where exploration of state-of-practice is limited to a few studies . The processes and practices for developing hardware-relevant products have been reported in literature about embedded system engineering, which concerns about application-specific computing devices consisting of hardware and software components ( Ronkainen et al., 2002 ). Current knowledge on development processes of hardware-related products in established companies is rarely transferred to hardware startups' product development, as the startup context is unique and special Ronkainen and Abrahamsson, 2003 ). In the embedded domain, hardware sets strict requirements to software. Development of hardware-intensive systems require simultaneous development of hardware-components and hardwarerelated software ( Ronkainen et al., 2002 ). Since software allows for frequent updates and releases, the system architecture often seeks to separate hardware from software to allow for two largely independent release processes ( Bosch, 2016 ). This is illustrated in Fig. 1 where hardware and related software development are distinct processes requiring constant communication and interconnected testing and verification. Ronkainen et al. (2002) found four main characteristics of hardware and related software development, including (1) hard realtime requirements, (2) experimental work, (3) documentation requirements, and (4) testing.
1. Hard real-time requirements (e.g., data throughput rates, cycle counts, or function call latency) mean that if software doesn't meet requirements, further system operation may be at risk.
Hardware simulations can help determine the precise operation of hardware without producing an expensive prototype and even enable testing of the hardware-software co-operation. 2. Hardware-oriented software development is experimental by nature, and developers need to understand the whole system to deal with all uncertainties related to changes in hardware and how software affects the whole system. Every requirement cannot be known and every decision cannot be made before writing software. Developers should utilize an iterative development approach to deal with all ambiguities of hardware-related software development. 3. The communication among hardware and software developers must work to implement the hardware-software interface efficiently. Information has to be explicit and relies heavily on exact documentation to minimize information loss between iterations. However, due to the vast amount of experimental work, too much documentation is not feasible in early stages of product development. 4. Testing is an essential activity both due to reliability and device autonomy requirements, and regression tests to ensure parallel development doesn't drift. In addition to independent software and hardware tests, checking the right interaction between hardware and software (i.e., co-verification) is important to ensure the system works as intended.
Recent advancement in hardware technology suggest that Agile practices also could be used in the embedded domain ( Kaisti et al., 2013 ). Although Agile methods and practices may have a positive impact (e.g., decreased development time and reduced error rates) on product development, the use of Agile in the embedded domain is not widespread ( Albuquerque et al., 2012 ). There is a need for a coherent understanding of how Agile methodologies best fit to embedded systems development in the startup context, and how such practices can reduce costs and effort s in different phases of the development process (i.e., requirement management, design, and architecture).

Research methodology
Software startup engineering research is to a great extent concerned with investigating the development, operation, and maintenance of software and hardware products in startup companies. In order to gather and to interpret evidence for answering our research questions, we devised a qualitative approach. The goal of qualitative research is to investigate and understand phenomena within their real-life context ( Robson, 2002 ). Dependent on the indepth knowledge in a case, the qualitative research can have a narrow focus on a few case studies, or a broader scope as a qualitative survey ( Robson, 2002;Andersson and Runeson, 2002;Walsham, 1995 ). As the study's overall goal is to characterize current status of adopting agility and quality-driven practices in a population of hardware startups, a qualitative survey appears to be suitable, especially when there is a limited capacity for capturing insight data from a number of companies in a short time ( Andersson and Runeson, 2002 ). Robson classified four types of research purposes ( Robson, 2002 ): • Exploratory -understanding what is happening; to seek new insights. • Descriptive -portraying a situation or phenomenon. • Explanatory -seeking an explanation of a situation or a problem, mostly but not necessary in the form of a causal relationship.
• Improving -trying to improve a certain aspect of the studied phenomenon.
In line with the non-deterministic nature of product development in the startup context ( Nguyen-Duc et al., 2015 ) (i.e., contexts for product development are highly influenced by team, financial, market situations and entrepreneurial approaches), and with the exploratory nature of our research question, we exploratively investigate multiple startups. Klein and Myers differentiate three types of research perspectives, positivist, critical, and interpretive ( Klein and Myers, 1999;Walsham, 1995 ). Positivist studies search evidence for testing hypotheses, drawing inferences from a sample; critical studies identify social critique, and interpretive studies attempt to understand phenomena through participants' interpretation of their context. In this research, we investigate a phenomenon that integrates human factors and engineering concepts. Hence, we adopted the interpretive view and collected data from semi-structured interviews.
There are several possible levels of analysis (e.g., individual, artifact, team, project and company). We chose project as a suitable level of analysis, as this study concerns about product development activities and processes, with certain expectations about the interactions between the products and their contextual environments. The focus of our interviews is startups' single projects that leads to the launching of their core products. Fig. 2 illustrates all steps of the research process.

Channel
Description Link

Innovation Center Gløshaugen
The center is located at campus Gløshaugen, and houses various early-stage high-tech startups, mainly to support innovative students.
www.ntnu.no/ig NTNU Accel and FAKTRY NTNU Accel is a uni-based accelerator for promising startups. FAKTRY is an incubator which is part of Accel, and houses various hardware startups.
www.oslotech.no www.startuplab.no The Hub The Hub is a community platform which gives an overview of Norwegian and Nordic startups. Via the platform, startups can get assistance with recruitment and connection with investors. www.hub.no

Companies and subjects selection
Our research relies on theoretical sampling: purposive, nonprobabilistic samples which are typically small, as a single observation is sufficient for inclusion in the coding system. Researchers identify key participant, for instance, CEO, CTO or key engineers who has access to important information. To select appropriate participants, we chose criteria, as suggested by Runeson and Höst (2009) . Startups were relevant for inclusion in the study if they met the following criteria: • The startup has at least two members, so product development is not an individual activity. • The startup has been active for at least six months, so their experience can be relevant. • The startup develops products or services that include both hardware and software parts. • The startup has a first running prototype so it's engineering practices are relevant.
Our sample in the survey is comprised of 13 hardware companies. They represent a diverse selection of application domains, product types and company characteristics, although they are not systematically sampled from any larger distribution.
People from the relevant startups were eligible for participation if they had experience and/or knowledge about software and/or hardware development. If the candidate met the criteria, he/she was regarded as qualified for contributing to the research study.
Via professional networks of co-authors of this work, we identified several potential sources of contacts, which are co-working spaces, incubator programs, and technology parks. The five different channels used to find relevant startups are (1) Innovation Center Gløshaugen, (2) NTNU Accel and FAKTRY, (3) our co-authors' professional networks, (4) OsloTech and StartupLab, and (5) The Hub. Table 1 provides an overview of the different communication channels and can help other researchers to find and contact startups ( Table 2 ).
There was a mix of startups originated from academica (7 out of 13 companies), entrepreneurs (5 out of 13 companies), and industry spin-off (1 out of 13 companies). The investigated startup founders have varied industrial experience, ranging from 1 to more than 10 years. Regarding entrepreneurial experience, five startups are first time startups. The other eight startups have experienced some failure before. Regarding the background of the interviewees, the majority (12 out of 13 companies) have technical backgrounds that are relevant for developing products ( Table 3 ).

Data collection procedure
Our chosen data collection method was interviews, identified as an efficient method for answering research questions in explorative studies ( Oates, 2005 ). The semi-structured approach enabled discovery of unforeseen information as interviewees could express The first and second researcher were in direct contact with the subjects, hence the data collection process can be regarded as a first degree data collection technique. First degree data collection requires a significant effort, but allowed both researchers to control what data was collected, ensuring that all pre-defined interview questions were answered sufficiently and exploring new directions by asking follow-up questions ( Runeson and Höst, 2009 ). Both the first and second author attended all interviews to avoid one single interpretation of the respondent's perspective and in- sight on topics, as qualitative data often can be rich and broad, but less precise. Before the interviews, we looked into the participants' business background, either through their company websites or other relevant incubator or accelerator websites. Additionally, most participants answered a simple questionnaire prior to interviews where they filled out basic information about themselves and the company ( Appendix B ). These measures allowed for more efficient interviews as the first and second author possessed more knowledge about the interviewee and could use less time on formalities. Initial company analysis allowed for a holistic understanding of each company and provided stronger evidence for the conclusions drawn from the interviews. Each interview lasted between 40 min and 1 h. Table 3 presents key facts about the investigated companies. The size of the company provides insight into the required need for development process and managerial overhead. The "Current stage" is adapted from the paper ( Crowne, 2002 ), as applied in the systematic mapping study by Berg et al. (2018) , representing the stage of the startups at the time of the interviews. The startup stage refers to the period between product conception and the first sale. The stabilization phase starts when the first customer receives the product, while the growth phase begins when a product is delivered to a new customer without disturbing the development team.

Analysis procedure
We applied the thematic synthesis process which is a codesto-theory model for qualitative research ( Cruzes and Dybå, 2011 ). The objective of our thematic synthesis process was to both answer the research questions and come up with a model of higherorder themes describing development strategies in hardware startups, focusing on aspects that are unique from software startups. The main steps of the process are illustrated in Fig. 3 .

Initial reading
The first step of the analysis process was to read through the transcribed interviews to generate initial ideas and identify pos-sible patterns in the data. All interviews were transcribed shortly after they were conducted to ensure the actual meaning of interviewees' answers. All authors discussed the interviews, creating a mind map of central concepts relevant to hardware startups.

Coding process
To generate initial codes, the first and second author applied a descriptive coding technique ( Saldaña, 2015 ), to identify interesting concepts, categories, or other findings in a systematic way across the data set. Descriptive coding helped organize and group similar data into categories, which is the first step towards the creation of themes.
The coding process followed an integrated approach ( Saldaña, 2015 ). This allowed us to avoid coding data out of context, while at the same time identifying what the text was saying rather than what we wanted to see. We applied an iterative coding process, to allow for simultaneous data collection and analysis ( Runeson and Höst, 2009 ). The coding process resulted in a total of 49 codes and 734 references from 13 interviews. The first iteration involved coding the data from the four first interviews. A total of 29 codes were generated from 416 references. The codes were examined by the first, second, and third author. Lessons from the evaluation were implemented in the next interviews to generate relevant codes. For the second iteration, we classified text into the codes from the first iteration, while at the same time generating new codes in an inductive manner.

Codes into themes
A theme can be seen as a way of grouping initial codes into a smaller number of sets, to create a meaningful whole of unstructured codes ( Cruzes and Dybå, 2011 ). We divided related codes into categories and concepts ( Strauss and Corbin, 1998 ). All interview transcripts were analyzed separately to ensure that themes were in line with the associated context.

Model of higher-order themes
The generated themes were further explored and interpreted to create a model of higher-order themes ( Appendix A ). The higherorder themes were prototyping and development, quality assurance, and enabling factors . In addition, we identified patterns more general to the startup context. The 14 themes in the thematic map were extracted to address management of Agility (as shown in Table 5 ) and Quality (as shown in Table 6 ).

Validity procedure
In qualitative research, the validity must be addressed to enable replication of research and to ensure findings are trustworthy ( Yin, 2003;Cruzes and Dybå, 2011;Runeson and Höst, 2009 ). To ensure the validity of this study, we followed the validity guidelines from Runeson and Höst (2009) .
Construct validity ensures that the operational measures that are studied really represent what the researcher have in mind and what is investigated according to the research questions. To assure that the interview questions ( Section 3.2 ) were suitable for answering our research questions, we defined interview questions through a top-down approach using the Goal Question Metric method. Interviewees were either CEOs or engineers with insight into business-and technical-related aspects. Since it is difficult to understand a startup and its dimensions within a time-span of 30 to 60 min, we collected data about the startups through incubator and company websites prior to interviews. To improve the reliability of the study, all participating startups were included in the process of writing company descriptions to ensure their conformance with reality.
External validity refers to the extent to which the findings are generalizable beyond the context studied. For qualitative studies, the intention is to enable analytical generalization where the results are extended to companies which have common characteristics. Our startups were mostly located in Norway, mainly consisting of early-stage small-size entrepreneurial teams. They are also mostly self-funded and acquiring some key competence from the start. Hence, it would be safe to rely the findings to startups with similar characteristics (i.e., early-stage European startups). Startups from other American countries or startups already in a growth stage, might not be observed with similar features.
Reliability refers to the extent that data and the analysis are dependent on the specific researchers. We have defined and validated interview protocols with colleagues. To decrease the risk of biased interpretations, author one and two attended all interviews. Some interviews were in Norwegian, hence transcripts were not always verbatim to preserve the actual meaning of respondents. Recordings were transcribed shortly after each interview to mitigate bias. Additionally, we compared findings to related literature ( Giardino et al., 2016;Nguyen-Duc et al., 2018;Ronkainen and Abrahamsson, 2003 ), examining similarities, contrasts, and explanations. Such comparisons have proven to enhance internal validity and the quality of findings ( Eisenhardt, 1989 ). 4. Results -How do hardware startups achieve both agility and product quality during product development?

An integrative view on agility and product quality in hardware startup development
The integrative model of agility and quality in hardware startups is presented in Fig. 4 . We have grouped the main concepts according to two dimensions (1) agility-driven or quality-driven, (2) project activities (i.e., prototype and product development, or quality assurance). Each concept describes a common foundation in hardware startups that manage agility or product quality. We classified the emerging concepts into three categories: • Mindset (represented by green boxes in Fig. 4 ): a belief, an opinion, or a way of thinking towards a topic • Practice (represented by pink boxes in Fig. 4 ): the actual application of an idea, a belief, or a method to solve a specific task • Strategy (represented by yellow boxes in Fig. 4 ): a high level plan that might include a set of practices or processes to achieve a goal As can be seen from Fig. 4 , the integrative model of agility and quality in hardware startups focuses on four quadrants on two axes. The vertical axis shows two major activity areas (1) prototyping and product development and (2) quality assurance. The horizontal axis shows the area of Agility or Quality. By putting them together, we offer an integrative overview of how agility and quality are managed in both product development and quality assurance activities. The final section in the model represents enabling factors that apply to both quality and agility concepts. As seen from the model, hardware startups achieve agility at both mindset, strategy, and practice level in the prototyping and product development phase. Hardware startups include development practices during the quality assurance phase that provide short-term gains in quality. However, it becomes clear that hardware startups lack both strategies and mindsets for achieving the long-term quality of the product during the prototyping and development phases.
The model also illustrates the lack of practices during the quality assurance phase that support the vital need for agility in hardware startups. In other words, there are none quality-driven activities adopted by hardware startups that contribute to their agility. This impedes the adoption and focus on quality in hardware startups.
The commonality among hardware startups performing these approaches are (1) customized iterative practices, (2) sufficient competence in team, and (3) collaborative technical decision making. These appear as key mindsets and strategies for startups to perform both agility and quality-driven product development. In the following sub-sections, we present detailed insights related to the common enabling factors, agility and quality aspects in prototyping, product development, and quality assurance activities ( Table 4 ).

Enabling factors for achieving agility and quality
Customized iterative practices. Hardware and hardware-oriented product development involve a lot of experimental work, and so developers are encouraged to follow an iterative development approach ( Ronkainen and Abrahamsson, 2003 ). Among the startups, five practiced simplistic versions of Scrum, seven used ad-hoc Agile practices, while one startup did not follow a defined Agile development process. In some startups there was not identified a need to implement specific development methods, one reason being the small size of the development team. This was especially the case in early stages when tech teams were co-located and introduction of formal communication processes would inhibit the agility and freedom of the team. In the startup where the development team only consisted of one person, the degree of process was almost absent.
S5 -"Since the team is so small, communication is easy. We have not seen a need to implement any specific Agile methods or other lean practices." S13 -"I don't think Agile practices are applicable to hardware development, for example you cannot frequently re-design a port as it involves great costs." S8 -"In hardware, the variance of tasks and interrelated dependencies make it more complex than what current Scrum tools like Jira are suited for." S4 -"Strict Scrum is probably easier to implement for pure software development, so we use a simplified version of it." Due to different team sizes, product offerings, and other financial, managerial, and human factors, Agile practices were implemented differently among the hardware startups. Sprint duration usually lasted between 1-2 weeks, and goals were defined in weekly meetings. Since development of physical products usually takes longer time than implementation of software, the startups focused on defining measurable sub-goals that were part of a longterm plan. Most startups had the same Sprints for the respective hardware and software development. However, one startup differ-    Sufficient competence in team. Although contracting is a common approach, startups mention that internal development would be the best way to achieve agility. Hardware startups need team members that are dedicated to all aspects of the development process. As hardware startups have to deal with many factors besides software there are higher demands to expertise and experience of team members. Team members of hardware startups will preferably need knowledge about application domain, systematic development, software and hardware development, mechanical engineering, and experience of working with third-party companies. Particularly, achieving a good collaboration between software engineers and hardware engineers in the team would accelerate the process of prototyping. However, this is only observed in one startup. Most of the startups had challenges of achieving right sets of competence from the beginning: S6 -"Finding talented people is hard. Since we are a startup we cannot give very good salary. This is why we try to attract people who see that the product may provide great value in the future." Even though external resources can substitute for the missing competence, this would not be sustainable in the long run. Many startups include part-time team members, who are typically more task-based oriented than co-founders. Depending on these people might reduce the agility of production due to the availability and commitment issues.
Collaborative technical decision making. Hardware startups are found with technology-driven processes of iterating their products. The teams are typically flat structured, probably due to the fact that startups often have a small number of members at early stages. Members are motivated and voluntary in taking tasks and responsibilities. In our study, startups seem to lack governance mechanisms of legal rules and strict regulation. Typically, technical decisions are made by engineers themselves. All decisions are made on team-basis. We also observe that startups allow for flexibility in working time and place, as everyone is responsible for the requirements needed for their area of responsibility. For a small team, team members could probably play multiple roles. Overall, team members trust other's competence. The team is flexible in organizing and reorganizing (i.e., adding new members and collaborating with vendors) to react to changes from environments.

Agility aspects of hardware startups
Partial laboratory-prototyping. Almost all startups immediately built a physical prototype to elicit requirements and achieve rapid business experimentation. They usually followed an evolutionary approach, performing incremental improvements on an early lowresolution prototype. Rapid prototyping is important to obtain customer feedback, however it can be problematic in the hardware context. Hardware startups usually have a significant focus on nonfunctional requirements because of the many challenges and regulations associated with complex systems development and the general hardware ecosystem. Common to the investigated startups is their priority of modularity both at software and hardware level, much so to achieve frequent user testing.

S10 -"We made a physical prototype immediately. It looks like today's product, but with many shortcuts and lower quality."
S8 -"We can develop many low-resolution prototypes using our own equipment, but if we want high-quality prototypes we might have to order 10 different parts from 2 to 3 suppliers." To deal with their inability to quickly develop prototypes, the startups tried to be flexible on the software side of their products. Since software can be frequently updated and tested by customers, they focused on developing a simple interface between hardware and the software directly accessing the hardware. In this way they could achieve more parallel and independent development of hardware and software. They mainly tried to reuse software, as hardware components were easier to reuse with more refined prototypes.

S4 -"We have developed a simple interface between hardware and software so that the development can happen individually."
S3 -"When we outsourced software development, changes took a lot of time... In software we need to make changes weekly. In hardware it is okay that things take a bit more time." S2 -"We prefer making changes in the software or firmware. To facilitate this, we have a clearly defined interface between software and hardware." Adoption of tools and components. Among the investigated startups there was a more extensive reuse of software than hardware. Hardware and mechanical components were easier to reuse with more refined prototypes than early low-resolution prototypes. The startups made little use of mock-up tools, and so throwaway prototypes seem to take little part of the prototyping stage of hardware startups.
S2 -"We try to reuse as much as possible from each prototype. We divide the code into different modules, so that if we replace any hardware component we only need to change that specific part of the code." S7 -"We tried to reuse the electronics, but it was harder than expected. So the physical components are usually substituted for each prototype... The software is more easily reusable." Having access to prototyping equipment will be an important asset, reducing both development time and prototyping cost. With 3D-printers startups can do a lot of the prototyping themselves, and make rapid changes based on customer feedback. This enables faster problem space testing.
S2 -"With a 3D-printer we can make products that look and feel real. This is a huge advantage. We can literally do almost everything apart from the electronics production ourselves and put it together almost for free." S9 -"We have done a lot of 3D-printing. Without access to useful equipment prototyping would have been very expensive and taken more time." Optimizing manufacturing and logistic process. The most timeconsuming process of hardware prototyping is the long production and shipping times, as production usually is located in China or other countries in southeast Asia. This means that not only will the delivery time of necessary parts depend on the vendor's own schedule, but also the shipping method used. Several of the investigated startups spent a significant amount of money on speeding up production and shipping time of manufactured components.

S8 -"All parts of the prototypes must be ordered, mostly from China, with long delivery times. We spend a lot of money making delivery times shorter."
Several startups experienced quality issues working with their external partners. Manufacturing defects of crucial prototype components caused extra delays, which is critical considering the valuable time already spent waiting for the components. Cooperating with professional actors can decrease the risk of quality issues, and enhance communication.

S4 -"We have outsourced production of mechanical parts and circuit boards. Some of the components we have received from the manufacturer have been in bad condition and with significant defects."
As high-tech prototyping is a time demanding process, there might go several years from the startup is founded to the time a finalized product is ready to be released to the market. This implies that vendors' dependability also is of importance. Choosing components that with certainty will be available the entire prototyping stage is crucial.

S12 -"The first version of the screen went out of production. This was the most important component and it took a lot of time to fix the problem."
To achieve speed, product quality often gets low priority in startups. However, because of the vendor dependency of hardware startups, hardware development should receive higher focus on quality. Making shortcuts in hardware design, and not assuring that the design is of sufficient quality before sending the specifications for production might be costly. Initial findings suggest that hardware startups focus on ensuring the quality of core hardware components, as low-cost solutions may inhibit progress in the long-run. Findings from S12 and S1 indicate that hardware startups should put great effort into ensuring the quality of hardware components, as low-cost solutions can inhibit the long-term evolution of their prototypes. S1 -"We spent more than $500 on a single component we could not use. In addition we had to spend more time redesigning the board, and wait for it to be produced." Because of pressured financial resources and small production batches it can be hard for startups to receive commitment from professional manufacturers. Working with vendors producing components of high quality at an affordable cost will be an advantage. The big geographical distance, and the difference in language and culture may also challenge the communication skills of the team, as effective communication is important to receive service as paid for and maintain product development speed. S10 -"As we have grown, we have been able to work with better suppliers producing at higher quality, which in turn has helped us prototype faster." S2 -"We are building on networks from earlier startup experience... Previously, we chose the cheapest suppliers, but then we also got components in bad condition, there were communication problems, and it usually took more than 4 weeks to get the products." Combining documentation with Agile methods . On the software side of the product, the common perception is that since the developers work on the code-base every day, documentation activities lead to additional overhead. Tacit knowledge seem to be a common practice in hardware startups.

S3 -"We spend less time on documentation to speed things up, development is our main focus. It is also because software development is in-house. We work on it daily and understand the code."
High-tech products include a lot of different sub-systems and technologies, and so product complexity increases fast. This implies that documentation of components should receive a bigger attention in hardware startups. In worst case, lack of quality and documentation can put all development on hold.
S2 -"Instead of updating documentation and quality, we did things as fast as possible, which eventually led to a lot of extra work." The prototyping stage in hardware development is often significantly longer than that of software development. Since it might take years before hardware startups have a functioning product ready for the market, there's a great probability of people quitting the project before it is finished. As to this there should be increased focus on documentation in hardware startups, since knowledge often accompanies the person quitting.

S4 -"Sometimes it becomes challenging to keep the knowledge of people who quit, the knowledge often accompanies that person. This leads to extra costs and effort."
The choice of outsourcing companies can greatly impact the amount of documentation. Good partners usually provide welldocumented solutions and components, which can help manage technical debt.

S3 -"We received an 80-page user manual from the consultants who developed the hardware."
To help startups perform documentation, there exist multiple tools lowering the barriers for writing documentation. Examples of tools include Wikis, Google Spreadsheets, and Confluence. Utilizing tools can help decrease the amount of rework in the long run. Also thorough documentation can allow for more efficient integration of new employees in the development process.
S2 -"Previously we have spent a lot of extra time due to a lack of documentation. Instead of stopping, we did things as fast as pos-sible without performing documentation. This eventually lead to a lot of extra work."

S4 -"We have a wiki for internal documentation. It is quite low effort t o write something."
Accepting technical debt as an intrinsic attribute. Technical debt has been illustrated by Brown et al. (2010) , stating that "developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt" on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project". Finding the correct balance between learning goals and quality is therefore important in order to minimize waste and to manage technical debt ( Terho et al., 2016 ).
By accepting that time to market is more important than product quality, hardware startups incur intentional technical debt. Business experimentation to build new features is performed in small iterative cycles with minimal effort on product quality to receive fast customer feedback. Corresponding to software startups technical debt mainly manifests itself on the software side of the product in hardware startups. Since software can be changed quickly, shortcuts and workarounds are more easily taken on the software side than on the hardware side of the product. The development team prioritizes implementing new functionality over improving the quality of the codebase.
S2 -"Software changes all the time... To make things work straight away, we'd rather take a shortcut and fix it later. We know we're building up technical debt, but it's on purpose to be able to test the product on customers as quickly as possible." Hardware startups do not accumulate technical debt for their hardware components similarly as for their software components. As the concept of technical debt is built on erosion of systems from frequent low-quality changes, this is not as easily manifested in hardware components. Refactoring delivered or released hardware is a difficult and rarely performed endeavour. However, poor hardware design might eventually lead to the hardware needing to be redesigned. As hardware components often are reused between low-resolution prototypes, bad design might imply that the hardware needs redesign on an earlier iteration of the product than intended. Early lifetime design decisions might propagate throughout the lifetime of the product, and may eventually become part of the final product. These poorly made design decisions will then be discovered after the product is released. Hence, temporary lowquality solutions in both hardware and software will eventually lead to accumulation of technical debt in hardware startups Outsourced manual testing. Outsourcing includes the choices of both local consultant companies and aboard contracting vendors. Hardware development requires a significant amount of testing to ensure product quality. This applies already at the prototype stage, and for demonstration. Among the companies, some outsourced their manual testing (i.e., testing the final release at different execution environments, and testing the integration between developed components and known services or products). Outsourcing manual testing can save time and effort for startups to focus on innovation and core value creation activities. S10 -"In software we have a great focus on testing. When software is modified, we run automatic tests to ensure that everything works... In hardware we test that the product functions in different climates, and perform various mechanical tests... We have also outsourced much manual testing to a company to check more parts of the product." 4.4. Quality aspect of hardware startups Quality-driven prototyping for core components. Testing is central to hardware startups. High quality in hardware development is important both because of the cost associated with mistakes from production, but also as quality greatly affects the perceived functionality of the product. In contrast to software products, it is challenging to implement changes and make improvements to the quality after the product has been produced and assembled. As a consequence, focus on non-functional attributes at the prototyping stage is essential. We observed many startups that implemented a test-driven approach for developing the core components of their prototypes.
S4 -"We have a test setup to ensure that the subsystems work as intended, and that allows us to analyze different metrics and data. For the most critical components and features we usually define detailed test plans in advance of development." Towards more frequent user testing. To achieve quick development speed in early stages, low-level testing activities generally receive little focus in hardware startups. Before a feature is guaranteed to be part of the final product, it is more important to verify that the feature adds value to the customers. Until then, the time spent on testing activities is minimized. This is also evident in software startups, where developers avoid wasting time on improvements of not-validated functionalities ( Giardino et al., 2016 ).

S2 -"We prefer to work fast, as writing tests can double the development time... If parts are to be replaced, then we think there's no point in spending time on testing."
In S3 and S6, the CEO highlighted the importance of having frequent feedback from their customers and users on the prototypes. This would be critical for the design and development of a product that later is sought to a mass market.
Several startups faced the challenge of testing their product in realistic environments because of legal restrictions related to privacy and public safety. Simulations and dummy-data can be alternatives to early testing.

S4 -"Setting up a foundation for doing robust tests is a challenge.
When developing drones it is not easy to perform testing, it requires specific experience and knowledge." Lack of financial resources and long delivery times make it challenging to test the product on a broader spectrum of customers. Physical prototypes are resource-intensive to develop, and in contrast to pure software products, one cannot necessarily deliver a new digital software update to customers. The investigated startups relied on a small set of customers for frequent feedback.
Partly automated testing. The hardware startups relied on each individual developer to test features as they were implemented. In that way the person responsible for the code was also responsible for its quality and functioning with the rest of the system. A frequently used testing activity among the startups was manual smoke tests (i.e., ensuring that major functionality work before undertaking more formal testing procedures). Prototypes were manually tested by internal employees to identify the most prominent defects before testing prototypes with early adopters or customers.
S8 -"We test the subsystems ourselves, but do not have a structured system for testing... The person responsible for delivery is also responsible for testing the feature to make sure it works." S1 -"People inside the startup who have experience with similar solutions test the product before it is tested with pilot customers." Software engineers tends to optimize the integration and operation of software components by adopting automated testing. This is reported to be done in some part of the product. Simulation as an aid for unit and component testing. For hardware development, simulation is very helpful to ensure certain quality attributes of physical products. Hardware simulations can help determine the precise operation of hardware without producing an expensive prototype, and enable testing of the hardware-software co-operation ( Ronkainen et al., 2002 ). Several startups found it challenging to test their product in realistic environments, both due to memory and performance constraints and because of privacy and public safety issues. Since planning is difficult in the startup context, test plans were often changed, hence these were often neglected. Simulations helped testing the product and code base before production, postponing the split between hardware and software functionality.
S4 -"At an early stage, things don't always go as planned. Other things than what you test for fail, so test and project plans often change a lot... In addition to performing many simulations, we use basic tuning of attitude control to avoid simple mathematical errors." Among the investigated startups we found that startups in later lifecycle stages implemented more systematic testing activities. As they got more customers, quality and testing activities became more important. Established customers have stricter demands than pilot customers. To deal with increased quality requirements, the startups implemented formal processes for testing. Regulation as a guide for early quality assurance. For some startups working under regulated domains, such as healthcare and automotive, market regulations and standards infer a strict guideline for product development. This has been used to guide the quality assurance activities since the prototyping phases. Besides, companies operating in the market will need to document all parts of their product and meet the high standards of quality required. Hence, market segment will greatly affect the severity of technical debt and infers an early debt management.
S6 -"We are weak on processes and document management, it is very ad-hoc. Soon we will introduce a process tool and a document management tool. This is necessary if we are to meet the ISO standard requirements and get it approved as a medical product." S13 -"The documentation is part of the development process... We have an ISO certification that says we are certified according to that quality process. They have strict requirements on how documentation should be kept, including the flow of the documentation and what kind of documentation to write."

Achieving agility in hardware-related product development
Agility is an essential part of startups in general ( Pantiuchina et al., 2017 ), and should thus be considered as an attribute of early stage hardware startups. Hardware startups' need for speed often sacrifice product quality. Instead of applying best engineering principles, we found that development teams prefer simple solutions to achieve rapid business growth. Speedrelated activities lead to the accumulation of technical debt, which eventually inhibit further business growth ( Giardino et al., 2016 ). Achieving agility in hardware startups is not as straightforward as adopting Agile practices or rapid prototyping in software startups.
It is evident that iterative development with middle-term planning is used in hardware startups because hardware development usually requires more time than software development does. As non-functional attributes need to be assured at the prototyping stage ( Nguyen-Duc et al., 2018 ), and hardware startups deal with third-party dependency, release frequency is low compared to soft-ware startups. This limited the ability of continuous experimentation as observed in software startups ( Fagerholm et al., 2014 ).
The investigated hardware startups achieved agility by facilitating for simultaneous work on multiple possible solutions. Implementation of ready-made or outsourced components can be a significant struggle as hardware startups rarely develop all components themselves. System design and architectural decisions are made in advance of development, and may greatly affect later system integration of components. As development in hardware startups can be considered a test of feasibility, development methods should facilitate for experimentation of multiple solution methods.
One of the key practices to achieve agility is efficient management of external dependency. By increasing the knowledge of external components in the system, developing reliable relationships with external partners, startups can reduce the time wasted on fixing issues that are not under the startup's team control.
The nature of hardware development makes embedded systems sensitive to rapid changes in hardware or hardware-related software ( Ronkainen and Abrahamsson, 2003 ). Preliminary architecture design is necessary to facilitate iterative development, and flexibility to handle rapid changes. As hardware startups intentionally try to force changes on the software side, neglecting up-front design may cause bugs that are not easily detected. Early investments in up-front system design can make the product more robust to changes, and facilitate for streamlined development in later stages.
Testing must ensure conformance between hardware and hardware-related software. However, the test-driven approach is problematic because of the severe memory and performance constraints of embedded systems ( Ronkainen and Abrahamsson, 2003 ), in addition to the restricted resources of hardware startups. To achieve quick development speed in early stages, low-level testing activities generally receive little focus in hardware startups. The startups were first and foremost interested in ensuring that included features provide value to customers.
Refactoring is basically the object-oriented variant of restructuring, "the process of changing a [object-oriented] software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure" ( Fowler, 2018 ). Our research indicates that regular refactoring is not practiced in hardware startups, neither for software or hardware development. Prototyping consists to a large degree of shortcuts and workarounds, especially for the software components. The nature of hardware development is not compatible with regular refactoring, as frequently redesigning components involves significant costs. This relates to software startups as well. Research states that refactoring rarely is implemented in the early stages of the startup, but as the startup grows, returning the accumulated technical debt is needed to meet more quality-demanding customers and scalability issues ( Giardino et al., 2016 ).
The mentioned practices extend the list of Agile methods for embedded systems development and in general hardware-related products (i.e., embedded hardware, wearable devices, Internet-ofthings systems, and robotics) ( Kaisti et al., 2013 ). The environmental conditions that make the practices particularly relevant include limited resources, market-driven requirements, and the temporary and exploratory nature of process management.

Assuring product quality
The complexities and uniqueness of hardware development imply that hardware startups need to prioritize product quality differently from software startups in order to speed-up development. The investigated startups tried to facilitate for changes in their software parts while keeping the amount of hardware rework minimum, due to the rigid nature of hardware development. Hardware quality is often necessary to meet real-time performance requirements of embedded systems ( Ronkainen and Abrahamsson, 2003 ). Enabling the hardware-software co-operation is an intricate process due to the complex control and testing support required over hardware, and the fast time-to-market cycles require simultaneous software and hardware design ( Ronkainen et al., 2002 ). The hardware startups invested in a simple interface combined with a skilled team to increase the amount of parallel development, facilitating for two largely independent development processes of hardware and software.
While forcing rapid changes on the flexible software side, the hardware startups incurred intentional technical debt. Since the software developers constantly worked with the code base, they relied on tacit knowledge instead of formal documentation. Hardware documentation seemed to be of higher importance due to the many stakeholders involved in hardware development. Intentional technical debt is a frequent problem in software startups, but can be even more harmful for hardware startups due to the change-sensitivity of the numerous complex hardware-software interactions ( Ronkainen and Abrahamsson, 2003 ). Refactoring of code base can cause changes in system behaviour or even jeopardize system operation. Even if software shortcuts make sense in the short-run, our findings indicate that the complex nature of high-tech products may cause a severe amount of rework in the long-run. Hardware startups should invest in documentation tools to lower the barriers for formal documentation. Adoption of Agile methods has proven to be efficient in reducing error rates ( Albuquerque et al., 2012 ), however current usage of such is restricted to a subset of Agile practices customized the individual needs of hardware startups.
The investigated hardware startups incurred unintentional technical debt due to the difficulty of testing problem space. They performed usability and acceptance tests on a small group of pilot customers, as a lack of financial resources and third-party dependencies (e.g., delivery times) made it challenging to test the product on a broader spectre of customers. By immediately building a physical prototype, the startups focused on validating, as they focused on making their customer acquisition processes more efficient rather than testing the demand for a functional product. The hardware startups' inability to produce many prototypes inhibited business experimentation and lead to feature creep. Feature creep in hardware startups may similarly to software startups be harmful to the production and maintenance of core functionality ( Nguyen-Duc et al., 2017 ).
Testing is central to embedded system development, as hardware startups need to assure non-functional attributes at an early stage. We found that testing practices were implemented to various extent among the hardware startups, among other things, because the testing environment was different from the development environment. Memory and performance constraints can also affect hardware startups' testing ability ( Ronkainen and Abrahamsson, 2003 ). The investigated startups relied on individual developers' effort s to ensure quality of new functionality. Manual smoke tests and simulations were favored to professional engineering activities. Findings indicate that rigorous low-level testing practices were not implemented before later life-cycle stages.
The investigated startups followed a quality-driven development approach, where performance and quality criteria of core components were verified through frequent user testing. Beyond functional testing as in software development, specific test plans are needed for hardware and hardware-software integration interfaces. The found practices can be applied to a cost and qualitydriven environment similar to what ( Peters et al., 2014 ) reported.

Balancing agility and quality in high-tech product development
The conflicting requirements for quality and agility mean development methods will need a hybrid process that balances both strict hardware development while allowing speed and flexibility as in software development. We extend knowledge about possible integrative approaches for agility and quality in hardware development ( Jha et al., 2016 ). Tactics for achieving agility (i.e., outsourcing, rapid prototyping, Sprint-based development) related to speed are commonly used by most startups, however, we see that hardware startups' overall strategy is to spend more time on qualityassuring activities.
A previous study reports five types of Agile practices that influence software quality, which are teamwork, engineering, documentation, testing, and management ( Arcos-Medina and Mauricio, 2019 ). The startups in our study illustrate the implementation of simple quality-aware practices in their development process with the focus on frequent user testing, early customer feedback, collaborative decision making, adoption of low-level documentation tools, and model-based engineering.
Working with limited resources, finding alternative ways to ensure product quality in early stages can be of high value. Realistic testing environments may be restricted, and as the early stages should not only be about failing fast, but failing cheap, computer simulations may provide early product validation. As documentation and component testing usually is the responsibility of each developer it should be easy to produce light documentation. Finding a sufficient approach to Agile documentation in startups that does not disrupt the informal workflow of the team is important. Simple and useful documentation will spare later effort.
Particular for the startup context, hardware and software teams are not always co-located or communicating in an effective manner. We see hardware-software integration meetings as an important practice for providing agility and quality to the development process, supporting team decision making. As observed in most startups, managing the interface between hardware and software is a necessity for speed that allows for distributed development teams simultaneously working on multiple solutions and technologies.
Existing research addresses the combination between agility and quality at requirement engineering, architecture, and implementation level ( Jha et al., 2016;Arcos-Medina and Mauricio, 2019;Franch et al., 2019 ). Our study offers a comprehensive view on adopting agility and quality-aware practices across product development activities. We also observe that all startups to some extent were familiar with Agile and it's concepts, however its' applicability to the hardware startup context were of different perception. Although quality-aware Agile practices are useful, there is still a lack of know-how to establish and bring these practices into actual usage. Hardware startups need a specific set of quality-aware practices in order to manage technical debt and attain the level of quality required for all stages of their development process.

Conclusion
Hardware startups develop physical products with mixed hardware and software components, requiring expertise within a broad range of technological fields. In addition to software development hardware startups deal with production and logistics issues, factors implying higher initial financial and human investments than what is experienced by software startups. From a qualitative exploratory study investigating 13 hardware startups, this paper presents the role of engineering activities from idea conceptualization to a launched product, and factors influencing agility and quality. Our research results indicate that hardware startups achieve rapid prototyping through evolutionary approaches, hardware-software decomposition strategies, and opportunistic Agile practices. The level of agility in prototyping and production varies depending on team competence, funding and various external constraints. Hardware startups incur technical debt as an unavoidable part of the evolution. The state-of-practice testing, with informal and partial quality assurance approaches, does not help to reduce the overall level of technical debt. The competitive environment of hardware startups makes speed inevitable, where investing in hardware quality will be necessary for bringing products fast to market. The study explains the priorities of hardware startups' engineering approach, and the specific need for process in managing the relationship between quality and speed. We provide practitioners with a better understanding and awareness of their own context, helping them make technical and business-related decisions of sustainable character. It is also evident that quality and agility is balanced with the mean of quality-aware Agile processes with an effective management of third-party vendors.
This study provides early empirical evidence into prototyping and engineering practices in hardware startups. However, the study highlights the compromise hardware startups make between quality and speed. Quality is of higher significance, and more research should be provided identifying valuable activities and approaches for hardware startups dealing with restricted resources. We encourage researchers to explore the long-term effects of technical debt, as our results are based on a small sample of earlystage hardware startups. In addition, future research should investigate how hardware startups can ensure safety and security standards when developing highly safe systems, following standards like IEC61508 ( Japan, 2012 ). The results are partly based on managerial viewpoints, hence missing important links to everyday testing activities performed by engineers and developers. Future work should verify the results with other startup companies to find its applicability in other environments, enabling generalization to a larger startup audience. More investigations should be undertaken to understand the role of scope in the engineering activities of hardware startups.
Our integrative model of agility and quality also implies the focus on mindsets, strategies, and practices for each product development activity. Future research should focus on defining qualitydriven practices that contribute to agility, and further simplify the introduction of quality in startups. As hardware startups need more attention to hardware quality to allow for evolutionary prototyping and speed, there should be engineering strategies describing how hardware startups can manage the relationship between restricted resources and increased quality demands. Future research can also focus on strategies and mindsets to support longterm quality in the startup context. Hardware startups need specific guidelines for performing problem space testing, and research should verify the consequences of its absence. There are identified several limitations to this study. Having based our study on qualitative measures, results and implications are subject to bias. To mitigate the risk of misunderstandings or wrong interpretations, two researchers attended all interviews. Whenever possible, interviews were performed face-to-face on-site. Recordings were transcribed and translated shortly after each interview to ensure respondents' meanings were preserved. Another limitation is the insufficient knowledge on technical decisions and product development challenges provided by some interviewees (i.e., knowledge of business executives is often based on managerial viewpoints). The results would benefit from a greater amount of participants providing insights into every-day engineering activities of hardware startups. Another shortcoming to the study is the diversity of the investigated startups, as the selection constituted early-stage European hardware startups. The study would profit from a wider collection of data, both to discover more relevant themes and to ensure credible conclusions (i.e., generalizability of the results). Further investigations of hardware startups operating in different markets, lifecycle stages, and various geographical locations can improve the reliability of the research results.

Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.