Towards Specific Software Engineering Practices for Early-Stage Startups

In this position paper, our goal is to argue the need for specific software development practices to early-stage startups. In order to reach this goal, we discuss the consequences of innovative and market-driven contexts, which are two of the key elements when describing software startups. We also argue that these practices could be applied to innovative initiatives within established companies since they share similar characteristics and challenges as those from startups.


Introduction
The definition of a startup is blurry in scientific research. There are two systematic mapping studies (SMS) performed on the topic, and both discussed how authors had defined the term. Back in 2014, Paternoster et al. [13] analyzed 43 primary studies and, as one of their results, grouped in themes the descriptions used by papers' authors to characterize these companies. The list consisted of 15 themes where the most common were: 1. lack of resources; 2. highly reactive; 3. innovation; 4. uncertainty; 5. rapidly evolving; 6. time pressure.
In 2018, Berg et al. [3] repeated the analysis, including papers published in the period. They concluded that the rigor had increased, but there was not still a consensus on the term. However, in the period between the SMSs, the most common themes were innovation, uncertainty, small teams, lack of resources, and little or no operating history.
Startups follow a life-cycle composed of four stages: inception, stabilization, growth, and maturity [11]. Inception starts with the idea conception and ends with the first release. In the stabilization stage, the startup prepares to scale regarding technical and operational aspects. These two stages are the earlystages where the focus is on finding a relevant problem and solution. In the growth stage, the startup aims to reach the desired market participation, and, in the last stage, it progresses into an established company.
In a divisive paper, Klotins [10] argued that there is no characteristic unique to startups that are not observed in other teams developing innovative, marketdriven, software-intensive products. To reach his conclusions, he reviewed the literature regarding themes identified by Paternoster et al. [13]. Below, we oppose this argument arguing that innovation and market-driven are necessary and sufficient elements to characterize startups. Still, this combination has slightly been touched in the software engineering literature. Finally, we show that current research to tackle problems in this context is still in its infancy and which avenues could be explored further.

Necessity: Innovation and Market-Driven Context as a Challenge for Software Development in Startups
Innovation is an ambiguous term in the literature. To tackle this issue, Garcia and Calantone [7] reviewed studies on market, engineering, and new product development disciplines. The review showed that the term comprehends a discontinuity in marketing, technological, or both processes. In this context, ventures operate through several trials and errors along various dimensions of the business model [2]. This uncertain environment leads to challenges in software development like unstable requirements, compromised testing, and lack of written architecture specification [13]. These challenges exist, especially in marketdriven contexts that are characterized by the software being developed to an open market with many customers instead of according to what is dictated by a paying customer (the so-called bespoke development).
A natural choice to deal with a dynamic context is to use agile methodologies since they embrace higher rates of change [15]. Nevertheless, agile methods may not be the final answer for software startups. Agile methods tackle changes through quick iterations with customer feedback [15]. However, these contact points are not available since, many times, even the customers are not known in the early-stages of a software startup. The lack of customer availability is a known challenge for teams applying these methods in market-driven environments [1,9]. Therefore, the combination of innovation and a market-driven context leads to a situation where a specific set of practices would be useful. Figure 1 summarizes this argument.

Sufficiency: Innovation on Software-Intensive Market-Driven Products as Startups
In this section, we argue that a team developing a new innovative, softwareintensive, market-driven product is a software startup. Although this aspect contradicts common themes to describe software startups, such as lack of resources and lack of experience [13], teams in large companies formed to develop innovative products face similar problems as those from startups. Regardless of the context of the innovation process, uncertainty, time pressure, and the need to be highly reactive is always a part of the initiative. These characteristics require a particular way of tackling the idea being developed. A large organization cannot deal with uncertainty, for instance, just by adding more resources; the right approach needs to be implemented to transform the questions (or hypothesis) into facts.
To support our argument, we can mention the research on internal startups, in which teams develop innovative software-intensive products inside large companies. For instance, Edison et al. [5] investigated the use of Lean Startup in large companies, arguing that it facilitated the software product innovation in this context. That is, teams developing software-intensive innovative products, even in large companies, can use methods tailored to startups.
In this sense, we intend to formulate a set of best practices or a framework that could be applied in any scenario in which innovation on software-intensive market-driven products is being developed. We acknowledge that large organizations naturally differ from small ones. However, we can also find differences among small organizations: they may face different regulatory elements, competition, technical challenges, and so on. If the literature does not indicate that startups should apply different approaches depending on their characteristics, there is no reason not to include innovation software-intensive market-driven products or services being developed on large organizations.

Current Proposals and Future Directions
Based on the arguments above, software startups would benefit from a set of practices tailored to an innovative process. Up to now, although a broad literature on the topic are being raised in the last years [3], there are no scientific studies proposing specific practices for these companies. Academic authors focused on describing the context including currently used practices (e.g., [8,11,12]) and faced challenges (e.g., [11,14]).
Nevertheless, in the industry, some methodologies, like Lean Startup and Customer Development, are well-known. Although described based on anecdotal evidence and the authors' own experience, several academics argued the influence and importance of experimentation to the core arguments of these practices, e.g., [4,6]. Besides that, scientific studies in innovation and entrepreneurship literature have argued the value of experimentation in these contexts. Therefore, similar approaches seem a reasonable way to follow.
Our goal is to further explore our hypothesis by gathering data from initiatives in large organizations as well as from early-stage startups. By confirming our assumptions, we will work towards a set of software engineering practices for these teams. Of course, such endeavor is a huge challenge and, instead of a small team work, we expect this position paper acts as a call for the whole community to go towards this end. The literature described above will inform the creation of these practices.

Conclusions
This position paper initiated a discussion on software engineering practices tailored to early-stage startups. Based on the fact that innovation and marketdriven are usually used to define software startups, we argue that these aspects are decisive to characterize this context. Besides that, we claim that these aspects are also relevant to teams in other contexts, such as large companies. We hope that this discussion can encourage further investigation of specific practices for early-stage startups in any given context.