Context: Early-stage software startups, despite their strong innovative potential, experience high failure rates due to factors such as inexperience, limited resources, and market uncertainty. Generative AI technologies, particularly Large Language Models (LLMs), offer promising support opportunities; however, effective strategies for their integration into startup practices remain underexplored. Objective: This study investigates how prompt engineering and system instruction design can enhance the utility of LLMs in addressing the specific needs and challenges faced by early-stage software startups. Methods: A Design Science Research (DSR) methodology was adopted, structured into three iterative cycles. In the first cycle, use cases for LLM adoption within the startup context were identified. The second cycle experimented with various prompt patterns to optimize LLM responses for the defined use cases. The third cycle developed “StartupGPT”, an LLM-based assistant tailored for startups, exploring system instruction designs. The solution was evaluated with 25 startup practitioners through a combination of qualitative feedback and quantitative metrics. Results: The findings show that tailored prompt patterns and system instructions significantly enhance user perceptions of LLM support in real-world startup scenarios. StartupGPT received strong evaluation scores across key dimensions: satisfaction (93.33%), effectiveness (80%), efficiency (80%), and reliability (86.67%). Nonetheless, areas for improvement were identified, particularly in context retention, personalization of suggestions, communication tone, and sourcing external references. Conclusion: This study empirically validates the applicability of LLMs in early-stage software startups. It offers actionable guidelines for prompt and system instruction design and contributes both theoretical insights and a practical artifact — StartupGPT — that supports startup operations without necessitating costly LLM retraining.

Context: Generative AI (GenAI) is argued to transform software engineering (SE) in various ways, and GenAI tools show promise for various SE tasks. Software organizations across the globe are currently exploring the use of GenAI for SE. Objective: While numerous studies have recently been published on GenAI, few studies have looked at the adoption of these tools and their usage from an organizational point of view, focusing instead on individual users. Our objective is to understand how organizations adopt these tools and what their impacts are in industrial contexts, with a focus on the European perspective. Method: We conducted a multiple case study of seven European companies. We collected data through semi-structured interviews (n=15), as well as through longitudinal observation in one case company. All data were analyzed using thematic analysis. Results: We analyzed 28 transcripts, resulting in 456 quotations and 557 code occurrences split between 66 individual codes that were categorized under 6 high-level themes. We identified 25 types of tasks GenAI was currently being used for in our case organizations. We identified 12 benefits for GenAI in SE and 10 adoption and use challenges. Key adoption challenges for organizations include data privacy and legislative concerns, the emerging and fast-moving market of GenAI tools, difficulty of measuring the positive impact of the tools, and potential change resistance. For individuals, the key challenges are related to prompting, such as understanding what a good prompt is, and how to write prompts for specific tasks. Conclusion: GenAI adoption is becoming widespread in SE, but good practices and use cases are still emerging. While GenAI can potentially produce various benefits in SE, companies and individual users are facing various challenges in making the most of GenAI in SE. Our results provide insights into the current state of practice.

ABSTRACT Context Generative artificial intelligence (GenAI) tools have become increasingly prevalent in software development, offering assistance to various managerial and technical project activities. Notable examples of these tools include OpenAI's ChatGPT, GitHub Copilot, and Amazon CodeWhisperer. Objective Although many recent publications have explored and evaluated the application of GenAI, a comprehensive understanding of the current development, applications, limitations, and open challenges remains unclear to many. Particularly, we do not have an overall picture of the current state of GenAI technology in practical software engineering usage scenarios. Method We conducted a literature review and focus groups for a duration of five months to develop a research agenda on GenAI for software engineering. Results We identified 78 open research questions (RQs) in 11 areas of software engineering. Our results show that it is possible to explore the adoption of GenAI in partial automation and support decision‐making in all software development activities. While the current literature is skewed toward software implementation, quality assurance and software maintenance, other areas, such as requirements engineering, software design, and software engineering education, would need further research attention. Common considerations when implementing GenAI include industry‐level assessment, dependability and accuracy, data accessibility, transparency, and sustainability aspects associated with the technology. Conclusions GenAI is bringing significant changes to the field of software engineering. Nevertheless, the state of research on the topic still remains immature. We believe that this research agenda holds significance and practical value for informing both researchers and practitioners about current applications and guiding future research.

[Context]: The COVID-19 pandemic has disrupted the global market and workplace landscape. As a response, hybrid work situations have become popular in the software business sector. This way of working has an impact on software companies. [Objective]: This study investigates software companies' responses to hybrid working. [Method]: We conducted a large-scale survey to achieve our objective. Our results are based on a qualitative analysis of 124 valid responses. [Results]: The main result of our study is a taxonomy of software companies' impacts on hybrid working at individual, team and organisation levels. We found higher positive responses at individual and organisational levels than negative responses. At the team level, both positive and negative impacts obtained a uniform number of responses. [Conclusion]: The results indicate that hybrid working became credible with the wave of COVID-19, with 83 positive responses outweighing the 41 negative responses. Software company respondents witnessed better work-life balance, productivity, and efficiency in hybrid working.

Context The COVID‐19 pandemic has had a disruptive impact on how people work and collaborate across all global economic sectors, including software business. While remote working is not new for software engineers, forced WFH situations come with both limitations and opportunities. As the ‘new normal’ for working might be based on the current state of Work‐from‐home (WFH), it is useful to understand what has happened and learn from that. Objective This study aims to gain insights into how their WFH arrangement impacts project management and software engineering. We are also interested in exploring these impacts in different contexts, such as startups and established companies. Method We conducted a global‐scale, cross‐sectional survey during the spring and summer 2021. Our results are based on quantitative and qualitative analysis of 297 valid responses. Results We characterize the profile of WFH in both spatial and temporal aspects, together with a set of common collaborative tools and coordination and control mechanisms. We revealed some areas of project management that are relatively more challenging during WFH situations, such as coordination, communication and project planning. We also revealed a mixed picture of the perceived impact of WFH on different software engineering activities. Conclusion WFH is a situational phenomenon which can have both negative and positive impact on software teams. For practitioners, we suggest a unified approach to consider the context of WFH, collaborative tools, associated coordination and control approaches and a process that resolve those aspects that are sensitive to physical interaction.

Abstract Technical Debt Management (TDM) includes activities such as identifying, measuring, and prioritizing technical debt. It is mainly performed to proactively mitigate the risk of losing the maintainability and evolvability of the software product which results in reducing the team velocity. Despite the importance of TDM, its adoption in software companies remain limited. Software companies are witnessing high market demand and competition that make delivering customer value outweighs the effort invested in TDM activities. Since the impacts of technical debt are uncertain and evident only in the long run, it is more difficult for companies with very limited resources to proactively spend their resources on TDM. In this paper, we propose a lean approach to facilitate the adoption of TDM in software companies with very limited resources. Based on this approach, TDM is driven by project management metrics, such as team or sprint velocity, and velocity variance. We conducted an initial evaluation of the concept of this approach through a short survey of 43 software project/product managers. Most of the survey respondents have a positive impression about our approach, which will encourage us to proceed further using more robust empirical evaluation.

Software startups are important drivers of economy on a global scale, and have become associated with innovation and high growth. However, the overwhelming majority of startups ends in failure. Many of these startup failures ultimately stem from software engineering issues, and requirements engineering (RE) ones in particular. Despite the emphasis placed on the importance of RE activities in the startup context, many startups continue to develop software without a clear market or customer, having never had meaningful contact with their would-be customer. We develop a method aimed at early-stage startups that is intended to help startups through the initial stages of the startup process: StartCards. The method emphasizes the importance of idea and product validation activities in particular in order to tackle anti-patterns related to (a lack of) RE in startups. This method is based on existing literature, both grey and academic literature. StartCards was developed using the Canonical Action Research (CAR) approach, over the course of 4 AR cycles. During the AR process, the method was used by 44 student startup teams in a practical course setting. Data from the use of the method was collected through self-reporting in the form of modified learning diaries, mentoring meetings with the startup teams, and a qualitative survey. We consider the current version of StartCards useful for early-stage startups based on the data we have collected. The method can also be used as a pedagogical tool in startup education. The paper presents the first published version of the method. While work on the method continues, the method is deemed ready for use.

Context: This full research paper presents an experience-based course designed around a semester-long external Innovation Bootcamp. Objective: We evaluated the impact of the Innovation Bootcamp on students' learning and startup formations, measuring how it affected students' perceived challenges related to technical skills, soft skills, project management, and startup-formation mindsets. Method: We conducted design-based research comprising questionnaires, interviews, and focus groups with students and stakeholders participating in the Innovation Bootcamp. In total, 44 students answered the questionnaires conducted before and after the Innovation Bootcamps in both academic years. In the second year, 12 students answered the Berkeley Innovation Index questionnaire to measure their innovation mindsets. We also conducted four individual interviews (student cohort 1), four focus group interviews (student cohort 2), and six individual interviews with stakeholders participating in the Innovation Bootcamp in both years. Results: We found that perceptions of challenges regarding soft and project-management skills declined, while perceptions of challenges regarding technical skills did not vary during the course. Students exhibited increased motivation to engage in startup formation following close collaboration with external stakeholders only after developing their first minimum viable product. Contribution: The study's outcomes contribute to validating a new team-centered model that facilitates startup formation in experience-based courses. We also intend to help educators and researchers adopt Innovation Bootcamps in experience-based, software engineering-focused courses.

Context: Customer-driven courses have been a classic approach in teaching software engineering for over four decades at the Norwegian University of Science and Technology. The main goal of these courses is close collaboration between students and customers. However, in this scope of work, the intent was to evaluate students' perception of skills acquisition, startup formation mindset, and the introduction of external activities. Objectives: Several aspects were investigated, which include how collaboration with external customers affects student skills in a customer-driven course, how collaboration with external customers affects students' motivation in startup formation, and how students perceive the introduction of an external Innovation Bootcamp activity at the start of the course. Method: Twelve semi-structured focus group interviews were conducted with 86 students. Furthermore, an inductive thematic analysis was performed, which utilized open coding of the interview transcripts. Results: Students reflected an improvement in technical, soft, and project management skills. It was found that many of the customers' projects were not eligible for becoming startups due to the nature of the project niche scope closely related to the customer needs. Motivations in startup formation rely heavily on individual students' mindsets, and many of the teams had a weak perception about startup formation within the existing course context. The overall observation from the focus group interviews was that introducing external activities such as Innovation Bootcamp could assist in the process of startup formation and elevate the projects' relevance and quality. Contribution: The study's findings contribute to the course's future improvement while introducing external activity. The outcome could promote student innovation and active participation in customer project proposals and end-product features. Educators and researchers can benefit from the findings of our study in regard to making future updates to their customer-driven courses. There is also potential to increase practitioners' awareness of positive student input in their project proposals.

Context: Approaches to teaching software engineering are becoming more interdisciplinary and team-centered, similar to a startup practice context. Therefore, educators must have an adequate framework for supporting software engineering teaching through startup practice. However, only a meager set of existing frameworks introduce startup practice to teach software engineering. Aim: Our study aims to develop and validate a framework for teaching software engineering through startup practice in higher education. Method: We developed a framework for introducing startup practices in software engineering education. We first identified the framework domains (course teaching and design perspectives, course theoretical lens, and course design and interaction practices) based on a previous literature review pinpointing lean software startups as part of software engineering education research. We further identified dimensions for each domain based on investigations in both our software engineering experience-based course and growth phase startup context. Finally, we validated the framework using a Delphi method. Results: We found that the perception of the framework dimensions was positive among the experts who, on average, rated 14 out of 19 dimensions as highly important (approximately 75%) and the rest (25%) as of average importance. From the current results, we are able to deduce that our proposed framework can provide realistic learning expectations for SE students but also for other disciplines that can relate to software engineering. Contribution: The study's outcomes contribute to developing and validating a framework for teaching software engineering through startup practice in higher education. Our framework lays a foundation for educators and researchers by successfully combining experience-based software engineering courses with lean software startup industry practices. Furthermore, our framework contributes to students acquiring adequate professional skills to address societal challenges with a mindset focused on increased innovation and startup formation.

Static Application Security Testing (SAST) is a popular quality assurance technique in software engineering. However, integrating SAST tools into industry-level product development for security assessment poses various technical and managerial challenges. In this work, we reported results from a case study of adopting SAST as a part of a human-driven security assessment process in an open-source e-government project. We described how SASTs are selected, evaluated, and combined into a novel approach and adopted by security experts for software security assessment. The approach was preliminarily evaluated using semi-structured interviews. Our results show that while some SAST tools out-perform others, it is possible to achieve better performance by combining more than one SAST tools. The combined approach has the potential to aid the security assessment process for open-source software.

Software has become ubiquitous in every corner of modern societies. During the last five decades, software engineering has also changed significantly to advance the development of various types and scales of software products. In this context, Software Engineering Education plays an important role in keeping students updated with software technologies, processes, and practices that are popular in industries. We investigate from literature the extent Software Engineering Education addresses major Software Engineering Trends in the academic setting. We conducted a systematic mapping study about teaching major Software Engineering Trends in project courses. We classified 126 papers based on their investigated Software Engineering Trends, specifically Software Engineering processes and practices, teaching approaches, and the evolution of Software Engineering Trends over time. We reveal that Agile Software Development is the major trend. The other Trends, i.e., Software Implementation, Usability and Value, Global Software Engineering, and Lean Software Startup, are relatively small in the academic setting, but continuously growing in the last five years. System of Systems is the least investigated among all Trends. The study points out the possible gaps between Software Industry and Education, which implies actionable insights for researchers, educators, and practitioners.

The workshop connects to the central theme “Educating for the Future” of CSEE&T 2020 and thus explores opportunities to improve Software Engineering education and training by using Essence. Essence, an OMG Standard, delivers essential, universal elements found in all Software Engineering (SE) endeavours and a language to describe and extend these elements and their use in concrete practices to tailor SE methods to teams' needs. Its Kernel separates the stable What and Why from the more adaptable How. That way, it provides an essential thinking framework facilitating the adoption and customization of practices and methods. As such, it supports multiple ways of educating SE students as well as training practitioners for the future. The first deployments of Essence in industry and academic courses around the globe show promising results. But since it is an entirely new way to think about SE practices, methods, and their building blocks—it requires some effort and thought to dive into the standard. This workshop facilitates the adoption by sharing experiences, best practices, and lessons learned.

Software engineering courses include practical and theoretical elements that give many options for pedagogical combinations among them. In this paper, we report on two different pedagogical approaches for an undergraduate, introductory project-based software engineering course with more than 500 students working in collaborative scrum teams. We call one approach `Every Student is an Innovator', and the other `No Student Left Behind'. This SE course has been long-running, with stable learning objectives and content. However, from one year to another, we radically changed the pedagogical approach of the course along several dimensions, among them the technical framework, software tools, project topic, mentor roles, assessment form and frequency, feedback and degree of student innovativeness. We report on the perceived challenges, detailed changes, the anticipated effects on the course learning outcomes. The results showed that innovativeness and fun need freedom and flexibility with processes and technology. However, strict design requirements and systematic guidance ensure fulfillment of learning objectives. Analyzing student and staff feedback, we find that both approaches lead to students using more time than intended and worrying about unknown assessment criteria.

Context: Software startups are software-intensive early-stage companies with high growth rates. We notice little evidence in the literature concerning engineering practices when startups transition to the growth phase. Aim: Our goal is to evaluate how software startups embrace software engineering practices. Methodology: We conduct a survey guided by semi-structured interviews as an initial step, to be followed by field questionnaires as part of a future exploratory study. We use open coding to identify patterns leading to themes we use to state our hypotheses. To identify our samples, we use purposive sampling. Results: Specifically, we analyze seven startup cases during the first qualitative phase. We obtain five anti-patterns (no-documentation, no-agile, no-code intellectual property protection, cowboy programming, no-automated testing) and corresponding patterns (readable code, ad-hoc project management, private code repositories, paired and individual programming, ad-hoc testing) in adopting software engineering practices. We state 10 corresponding hypotheses we intend to corroborate by surveying a more significant number of software startups. Contribution: This study, throughout its recommendations, provides an initial road map for software startups in the growth phase, allowing future researchers and practitioners to make educated recommendations.

There is a rapidly increasing amount of Artificial Intelligence (AI) systems developed in recent years, with much expectation on its capacity of innovation and business value generation. However, the promised value of AI systems in specific business contexts might not be understood, and further integrated into the development processes. We wanted to understand how software engineering processes and practices can be applied to develop AI systems in a fast-faced, business-driven manner. As the first step, we explored contextual factors of AI development and the connections between AI developments to business opportunities. We conducted 12 semi-structured interviews in seven companies in Brazil, Norway and Southeast Asia. Our investigation revealed different types of AI systems and different AI development approaches. However, it is common that business opportunities involving with AI systems are not validated and there is lack of business-driven metrics that guide the development of AI systems. The findings have implications for future research on business-driven AI development and supporting tools and practices.

We added a Bootcamp external activity to our experiential-based course for first-year master students of Norwegian University of Science and Technology. Students engaged with realistic challenges from stakeholders while participating in the Bootcamp. We aimed to evaluate this year’s student motivation in startup formation. We followed a mixed-methods approach combining data from a questionnaire and interviews. From the questionnaire, we found that the motivations regarding dimensions, such as startup formation increases, and the involvement of existing team members slightly decreased after Bootcamp. The interviews show that involving others–-not only the existing team members–-and having better funding opportunities are deemed crucial in future startup formations. The involvement in the startup formation of the existing stakeholders is still at a marginal level. The overall outcomes of the study help educators and researchers make educated decisions in relation to introducing startup formation within intensive software engineering experiential-based courses.

Business Model Canvas (BMC) is a tool widely used to describe startup business models. Despite the various business aspects described, BMC pays a little emphasis on team- related factors. The importance of team-related factors in software development has been acknowledged widely in literature. While not as extensively studied, the importance of teams in software startups is also known in both literature and among practitioners. In this paper, we propose potential changes to BMC to have the tool better reflect the importance of the team, especially in a software startup environment. Based on a literature review, we identify various components related to the team, which we then further support with empirical data. We do so by means of a qualitative case study of five startups.

Startups are often seen as drivers of innovation. In an attempt to leverage this potential, larger business organizations have founded internal startups as a subset of internal corporate ventures (ICV). These smaller organizations are intended to be more agile than the parent organization, in order to produce new service and product innovations using their own methods and practices independently of the organizational culture and methods of the parent organization. However, our understanding of ICVs is still lacking in terms of processes and success factors, and especially the more recent internal startups have scarcely been studied thus far. To approach this novel area of research, we take on a qualitative approach by means of a multiple case study of internal startups in large companies. Based on the data, we argue that the origin of the idea of the internal startup heavily influences the processes utilized by the internal startup, as well as the connections between the internal startup and its parent organization. We also highlight various practical implications.

Context: This full research paper presents an experience-based course designed around a semester-long external Innovation Bootcamp activity. Objective: We sought to evaluate the impact of Innovation Bootcamp on students' learning and startup formation. To this end, we measured how the Innovation Bootcamp affected students' perceived challenges related to technical, soft project management skills and the startup formation mindset. Method: We conducted a cohort study comprising questionnaires, interviews, and focus groups with both students and stakeholders participating in the Innovation Bootcamp. In total, 44 students participated in the questionnaires run before and after the Innovation Bootcamps during both academic years. Moreover, we conducted four individual interviews (student cohort 1), four focus group interviews (student cohort 2), and six individual interviews with different stakeholders participating in the Innovation Bootcamp during both years. Results: We find that perceptions of challenges regarding soft and project management skills drop, while perceptions regarding technical skills challenges do not vary during the course. Students exhibit increased motivation to engage in startup formation following close collaboration with external stakeholders only after developing their first minimum viable product. Contribution: The overall outcomes of the study contribute to validating a new course design model, which will help develop a course framework to help future educators, researchers, and practitioners adopt Innovation Bootcamp activities within a software engineering-focused experience-based course.

Moving from experiments to industrial level AI software development requires a shift from understanding AI/ ML model attributes as a standalone experiment to know-how integrating and operating AI models in a large-scale software system. It is a growing demand for adopting state-of-the-art software engineering paradigms into AI development, so that the development efforts can be aligned with business strategies in a lean and fast-paced manner. We describe AI development as an “unknown unknown” problem where both business needs and AI models evolve over time. We describe a holistic view of an iterative, continuous approach to develop industrial AI software basing on business goals, requirements and Minimum Viable Products. From this, five areas of challenges are presented with the focus on experimentation. In the end, we propose a research agenda with seven questions for future studies.

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 quality-driven 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.

Software Engineers work using highly diverse methods and practices, and general theories in software engineering are lacking. A recent attempt at creating a common ground in the area of software engineering methodologies has been the Essence Theory of Software Engineering. Essence is a method-agnostic progress management framework and a meta-method for Software Engineering (SE). However, tooling for Essence is still lacking. Without dedicated tools and other instruments, a meta-method such as Essence is cumbersome to utilize by practitioners and students. Indeed, Essence currently suffers from a lack of widespread practitioner adoption. In this paper, we thus present an Open Source tool for essentializing methods and practices: Essencery. We conduct a qualitative evaluation of the tool through a quasi-formal experiment and a set of semi-structured interviews. Based on this data, we improve Essencery iteratively before it is utilized in a large-scale project-based course as a proof of concept.

Internet-of-Things applications are not only the new opportunity for digital businesses but also a major driving force for the modification and creation of software systems in all industries and businesses. Compared to other types of software-intensive products, the development of Internet-of-Things applications lacks a systematic approach and guidelines. This paper aims at understanding the methodological commonalities among startups who are developing Internet-of-Things products. Using the SEMAT Essence framework, we captured common team compositions, common types of Minimum Viable Products and common way of working in early stage Internet-of-Things startups. We found that startups include various engineering and business competence, but do not cover all of what is needed. The development of Internet-of-Things applications adopts certain speed-favor approaches, i.e. rapid prototyping, iterative development and outsourcing. The finding implies some recommendations for both researchers and practitioners in the area of Internet-of-Things development.

[Context] Advancement in technologies, popularity of small-batch manufacturing and the recent trend of investing in hardware startups are among the factors leading to the rise of hardware startups nowadays. It is essential for hardware startups, companies that involve both software and hardware development, to be not only agile to develop their business but also efficient to develop the right products. [Objective] We investigate how hardware startups achieve agility when developing their products in early stages. [Methods] A qualitative research is conducted with data from 20 hardware startups. [Result] Preliminary results show that agile development is known to hardware entrepreneurs, however it is limitedly adopted. We also found four categories of tactics: (1) strategy, (2) personnel, (3) artifact and (4) resource that enable hardware startups agile in their early stage business and product development. [Conclusions] Agile methodologies should be adopted with the consideration of specific features of hardware development, such as up-front design and vendor dependencies.

Abstract -- Software startups are becoming increasingly popular in software industry as well as other sectors of economy. Startups that lack necessary competences often seek for external resources from outsourcing partners. Little is known how this outsourcing relationship works and whether it makes sense to outsource the technical competence to an external party. This is among the first investigations on the outsourcing relationships in software startups. By conducting exploratory case studies at six startups, we found a mixed experience with outsourcing. The experimental nature of an early product development makes outsourcing a feasible option, although startups often suffer from its uncertainty and managing commitments from partners. Results further propose that early contract-based activities could be transformed into a long-term partnership by adopting a startup boundary spanner's role, establishing an inter-personal relationship and maintaining a mutual commitment.1

It is essential for startups to quickly experiment business ideas by building tangible prototypes and collecting user feedback on them. As prototyping is an inevitable part of learning for early stage software startups, how fast startups can learn depends on how fast they can prototype. Despite of the importance, there is a lack of research about prototyping in software startups. In this study, we aimed at understanding what are factors influencing different types of prototyping activities. We conducted a multiple case study on twenty European software startups. The results are two folds; firstly we propose a prototype-centric learning model in early stage software startups. Secondly, we identify factors occur as barriers but also facilitators for prototyping in early stage software startups. The factors are grouped into (1) artifacts, (2) team competence, (3) collaboration, (4) customer and (5) process dimensions. To speed up a startup’s progress at the early stage, it is important to incorporate the learning objective into a well-defined collaborative approach of prototyping.

Startup process is a series of experiments before reaching a successful product. However, it is often difficult for startup founders to learn from their own experiences as well as from other startups. In order to capture the evolution of product and customer, we developed a theoretical model for early stage software startups. The model was adopted to describe five European software startups. Data was collected by interviews and documents. The model revealed the co-evolution patterns of product and customer knowledge. In addition, it discovers a common startup patterns among our cases, such as prototype-centric development and scale-up Agile. Last but not least, the model highlights signification pivots and possible relationship among them.

Minimum viable product (MVP) is the main focus of both business and product development activities in software startups. We empirically explored five early stage software startups to understand how MVP are used in early stages. Data was collected from interviews, observation and documents. We looked at the MVP usage from two angles, software prototyping and boundary spanning theory. We found that roles of MVPs in startups were not fully aware by entrepreneurs. Besides supporting validated learning, MVPs are used to facilitate product design, to bridge communication gaps and to facilitate cost-effective product development activities. Entrepreneurs should consider a systematic approach to fully explore the value of MVP, as a multiple facet product (MFP). The work also implies several research directions about prototyping practices and patterns in software startups.

Software startups are increasingly important in generating innovative products and services that widely impact global economy. However, there is an insufficient research support for their innovation and engineering activities, from both theoretical and empirical perspectives. This study aims at proposing a conceptual model to understand how these activities occur and evolve in software startups. The model is constructed using a complexity theory and system design thinking. The model usage is illustrated by describing three software startup stories. The results show that our model can capture innovation generation activities and the non-linear evolution of engineering activities in software startups, which is not presentable in current software life cycle models.

[Context] With the proliferation of desktop and mobile platforms the development and maintenance of identical or similar applications on multiple platforms is urgently needed. [Goal] We study a software product deployed to more than 25 software/hardware combinations over 10 years to understand multi-platform development practices. [Method] We use semi structured interviews, project wikis, VCSs and issue tracking systems to understand and quantify these practices. [Results] We find the projects using MR cloning, MR review meeting, cross platform coordinator's role as three primary means of coordination. We find that forking code temporarily relieves the coordination needs and is driven by divergent schedule, market needs, and organizational policy. Based on our qualitative findings we propose quantitative measures of coordination, redundant work, and parallel development. [Conclusions] A model of coordination intensity suggests that it is related to the amount of paralel and redundant work. We hope that this work will provide a basis for quantitative understanding of issues faced in multi-platform software development.

Software projects are still facing with challenges of team coordination across global boundaries. Boundary spanner is an important organic coordination mechanism that is not much explored in GSD literature. This paper presents a finding from four case studies of how a boundary spanner resolve coordination gaps in organizationally distributed teams. The qualitative data were collected from 16 interviews from different types of global software projects. Boundary spanners have common characteristics of a coordinator, such as team member recognition, multiple perspective expertise, decision-making ability and work time flexibility. Task negotiation, conflict resolution, task information navigation and boundary object set-up are common activities to support team coordination. We also discussed a compound effect of other organizational roles and the impact of context factors on boundary spanner's activities.

Coordinating teams across geographical, temporal and cultural boundaries has been identified as a critical task to achieve the success of global software projects. Organizational boundary is another dimension of global distribution, which is a less visible but equally important factor that influences team coordination. This study investigates attributes of the organizational boundary that inhibits coordination and development activities. Besides, we explore a set of effective coordination practices to overcome organizational boundary. The data were collected from two projects involving four different software development organizations. We found that the variety on collaboration policy, team organization, engineering process, and development practices contributes to extra coordination efforts, insufficient communication, team awareness and mistrust. The study also highlights that coordination practices, such as face-to-face contact, process synchronization and shared collaborative development are compulsory but not sufficient for effective team coordination across organizational boundary.

Effective team coordination is crucial for successful global software projects. Although considerable research effort has been made in this area, no agreement has been reached on the influence of dispersion on team coordination and performance. The objective of this paper is to summarize the evidence on the relationship among context dispersion, team coordination and performance in global software projects. We have performed a Systematic literature review (SLR) to collect relevant studies and a thematic analysis to synthesize the extracted data. We found 28 primary studies reporting the impact of five dispersion dimensions on team performance. Previously, only two primary studies considered and distinguished all of these dispersion dimensions in studying dispersed team performance. The dispersion dimensions affect team outcomes indirectly through influencing organic and mechanistic coordination processes. Empirical evidence show that geographical dispersion impacts negatively and temporal dispersion has a mixed effect on team performance. While studies with teams working across different time zones shows a tendency that the team performance is pessimistically perceived, studies that use direct measure on task performance shows a positive association to temporal dispersion. The paper provides implications for future research and practitioners in establishing effective distributed team coordination.