The software development industry is growing tremendously, which results in a shift from traditional in-house development to distributed software development (DSD) (Stol et al., 2017b). However, software engineering is a human activity more than a technical activity (Capretz, 2014; Siegmund, 2024). Previously, software houses used a traditional in-house approach where the colocated team was physically present at the site of work. This approach offers advantages such as control, immediate collaboration, and direct resource access (Colomo-Palacios et al., 2014). However, scalability issues and restricted access to diverse skill sets are its limitations. These limitations affect organizations' ability to cope with evolving market demands and emerging technologies (Colomo-Palacios et al., 2014). To overcome these challenges, organizations have increasingly turned to distributed software development methodologies, such as global software development (GSD) (Jabangwe et al., 2016) and offshoring (Mukherjee et al., 2023). GSD and offshoring have the benefits such as cost-effectiveness and access to specialized resources. Some challenges such as cultural differences, communication barriers, and coordination complexities are among the hurdles that organizations may face during GSD and offshoring (Mukherjee et al., 2023). GSD is an emerging approach for software development, where software development companies offshore or outsource development tasks to teams located across the globe. Some of the challenges of GSD are communication issues among remotely located teams (Yasin et al., 2023), coordination among teams, and team management (Shameem et al., 2015). DevOps, a methodology designed to enhance collaboration between development and operations teams, that emerged as the response to these shortcomings, too has many shortcomings (Laukkanen et al., 2017). While DevOps proves useful for collaboration and integration challenges in distributed development, a need to optimize the process is still realized by organizations. A 1 + 5 model has been proposed that helps realize business problems and cooperates with IT systems, to cater to the main focus of DevOps, which is continuous integration, delivery, and deployment (Górski, 2021a). Another great example is the node deployment packages for blockchain systems. To achieve reliable software development, a deployment framework for the automation of blockchain has been introduced that also offers UML modeling support (Górski, 2021b). A pipeline approach for solving the problem of continuous integration and continuous delivery is proposed, which helps in the deployments of various kinds of applications (Donca et al., 2022).

Crowdsourcing software development (CSSD) has emerged as a trending approach that leverages global skills through social media platforms (Asiegbu Baldwin et al., 2017). Crowdsourcing was initially defined by Howe (2006). According to him, it involves outsourcing to an unknown group of people through an open call (Howe, 2006). Crowdsourcing involves unknown people rather than companies or contractual employees, which makes it different from outsourcing (Stol et al., 2017a). There are three main components in crowdsourcing, requester worker, and platform. Requester makes requests through an online platform to which workers reply and get the job after completing some task. However Howe (2006) defines crowdsourcing as follows:

CSSD enables organizations to find diverse talent and expertise for the swift development of complex problems (Ruhe and Wohlin, 2014; Khan et al., 2019b), and this is enabled using online platforms (Mao et al., 2017). CSSD is known for the development of open-source software. Some projects such as Linux, Mozilla Firefox, and WordPress are good examples of it (Moslehi et al., 2016).

In addition to these approaches, Agile is also widely used in organizations. Agile has many benefits as quick delivery of service, teamness, and adaptation to change. Agile is mostly considered suitable for collocated teams as it emphasizes team building and collaboration among teams. Agile is a lightweight process and is known for its frequent delivery of services in a flexible manner (Mao et al., 2017). The underlying benefits of ASD include increased communication, coordination, trust, and support among team members, self-organized teams, and face-to-face communication (Erich et al., 2017). Interestingly, Agile is also followed by many software development companies that contribute to global software development (GSD) (Agerfalk et al., 2005; Niazi et al., 2016).

Despite having contradicting characteristics of these approaches, Agile software development is believed to have solved many challenges of GSD (Beecham et al., 2021). Specifically, Scrum is beneficial for reducing GSD barriers (Alsahli et al., 2017). In a geographically located approach, like GSD, daily scrum meetings are very helpful in managing communication and coordination among teams (Kausar et al., 2021), team productivity, trust between team members (Verwijs and Russo, 2023), team involvement, project management (Prasetio et al., 2021), and prioritizing customers' requirements (Khan et al., 2019a). Scrum of Scrums can reduce coordination, temporal, and other geographical challenges (Kausar et al., 2021).

Lately, it has been reported that various software companies following ASD also adopt the CSSD approach to get their projects developed from the crowd (Dwarakanath et al., 2015). Requirements gathering via crowd is also practiced (Khan J. A. et al., 2022). It has been developed in research that the integration of these two approaches, CSSD and ASD, is trivial. However, both approaches have contradicting characteristics, which makes it challenging for practitioners to follow (Stol et al., 2017a). Stol (Agerfalk et al., 2005) emphasized the effective integration of Agile software development and CSSD. Literature shows that software industries follow both ASD and CSSD; however, there is scarce literature available on the integration of ASD and CSSD (Agerfalk et al., 2005).

Research on the effective integration of ASD and CSSD is still novel and scarce. CSSD being a distributed approach has many characteristics that contradict the principles and practices of Agile methodology. Agile advocates face-to-face communication, contradicting the practice in CSSD, where workers do not know each other. Because of the heterogeneous nature of CSSD, team management and coordination also become challenging, which are otherwise strongly recommended in Agile. Thus, it is challenging for software development companies to follow crowdsourcing while working in an Agile environment (Qayyum et al., 2020). It is deemed important to understand the challenges that are faced by the software industry practitioners that follow ASD and CSSD together (Agerfalk et al., 2005). It is known that human factors play a great role in software engineering (Lenberg et al., 2015; Siegmund, 2024). Some factors such as organizational change, communication, and involvement in solutions are some of the challenges in software engineering, as software development is a team activity, so the challenges faced by the team can impact the software (Lenberg et al., 2015). As the integration of ASD and CSSD creates some challenges for the people involved in software development, understanding their challenges and providing strategies for them is important for effective software development (Qayyum et al., 2020).

Despite having scarce literature on the integration of these two approaches, the integration of ASD in GSD is a great motivation for researchers as ASD is believed to overcome many shortcomings of GSD (Beecham et al., 2014). Certainly, CSSD and GSD are different approaches, especially regarding team formation. In GSD, there are designated teams, whereas CSSD workers are not designated employees of the organization; rather, they are a large group of unknown people who do not know each other (Li et al., 2015). Agile approaches help in successful software development by emphasizing the needs and challenges of people involved in software development. Communication is one of the greatest human factors in software engineering that affects the software engineering process (Lenberg et al., 2015), and agile emphasizes the communication and collaboration of people involved for effective software development (Barros et al., 2024). However, if Agile practices benefit GSD, they can be integrated and used during CSSD for effective software development. The research intends to find the human factors in Crowd–Agile development. These are the challenges faced by industry practitioners who follow Agile and CSSD. Research also aimed to find strategies to solve and reduce these challenges. This research contributes valuable insights to industry practitioners, researchers, and organizations in various ways. This study contributes to the existing body of knowledge by providing knowledge about the challenges of Crowd–Agile development. Industry practitioners can follow this research to learn how they can overcome the challenges to effectively develop software. This leads to the formulation of two research questions:

The rest of the article is structured as follows. Section 2 covers the related work. Section 3 contains the proposed methodology. Section 4 contains survey design and execution. Section 5 covers the survey analysis. Statistical analysis of the survey is presented in Section 6. Research findings are discussed in Section 7. Section 8 covers the discussion and limitations of this research, and Section 9 concludes the manuscript.

This study aimed to identify the human factors involved in Crowd–Agile Software Development. These factors are the challenges faced by industry practitioners working in a Crowd–Agile setup. The study also focuses on identifying the strategies to reduce these challenges. Survey methodology is used to conduct this study. The survey has both open-ended and closed-ended questions. To design the survey instrument, existing knowledge on the possible challenges of Crowd–Agile development is used. Researchers have previously conducted a systematic literature review (SLR) to find a list of possible challenges in the Agile–Crowd integration (Qayyum et al., 2023). As there is scarce literature on the integration of Crowd–Agile, researchers have conducted SLR by studying in detail the challenges of AGSD and CSSD. The distributive nature of GSD is similar to that of CSSD, with some exceptions. This motivated researchers that many challenges faced during Agile with GSD may be faced during Crowd–Agile development. Hence, the researchers conducted SLR to find challenges of AGSD and CSSD. A list of possible challenges is produced after thematic analysis and focused coding of the challenges (Qayyum et al., 2023). It is worth mentioning that the papers selected for the SLR are according to the merit criteria of the IMT checklist (Yasin et al., 2022). However, this list is an outcome of the SLR and is considered as a possible challenge only. The authentication of these challenges is needed to be verified.

In this study, we take this opportunity to validate these challenges and identify any new challenges that are faced by practitioners working in a Crowd–Agile environment. The survey questionnaire is designed based on this list. The possible challenges from SLR are shown in Table 1. The survey is conducted to find out what challenges from this list practitioners face when using crowdsourcing while implementing the Agile software process model. The survey also identifies the strategies practitioners adopt to overcome the challenges of crowdsourcing when used with Agile. Not only the list of challenges identified from the SLR is verified during an industrial survey, but also the survey identifies some other challenges, which are not identified during SLR. The survey explores the strategies that are used by organizations to minimize the identified challenges. The survey is exploratory in nature.

The survey is self-administered. The targeted audience for the survey is software development practitioners and managers with experience in crowdsourcing and Agile software development. Any role of software development practitioners can fill this survey as we need to see different perspectives of the development team. The respondents are project managers, software developers, testers, designers, architects, quality assurance teams, business analysts, and system analysts.

For appropriate characterization of the targeted audience, the guidelines of Kasunic (2005) are followed. All the software development organizations across the world working with crowdsourcing and the Agile approach are contacted for the survey via email. For checking the quality and effectiveness of the questionnaire, a pilot study is conducted. This pilot study is conducted by representative organizations situated in Islamabad/Rawalpindi.

The population is hard to identify as no company on their website mentions that they follow crowdsourcing. For this reason, the snowballing technique is used. The snowballing technique is best used when the population is hard to find and the sample size is unknown. Crowdsourcing is a new term, so people are usually unaware of it too. This is another reason to use snowballing as it needs to be explained to each candidate respondent and then ask for their recommendations. However, there are some risks regarding this technique. Authors are not directly connected to the respondents and hence cannot have first-hand information from respondents. The reference given by participants can be based on their biasness; it is also possible that we have missed some key respondents due to the potential biasness of respondents.

The survey starts with acquaintances working as project managers in OSLO, UK, and Pakistan. Their company is performing crowdsourcing software development following Agile. They are requested to recommend some practitioners from their company to proceed with snowballing. Initially, five waves of snowballing were planned, but as the population is rare and there were no more recommendations, so snowballing process stopped at wave 3 after waiting for 2 months.

The survey questionnaire can be accessed with the following link; however, for the integrity of results, no new responses are accepted via this link. https://docs.google.com/forms/d/1wbLkrnLI2mzRwq5ETCo5YJJGEZ-36BhxAsjYCFNvN9s/edit.

The data and responses of the survey are provided in the following link: https://docs.google.com/spreadsheets/d/1vyRngAFDXz0GY64-wg95lZnXtiMXwxR7mmz8y0QTGg0/edit?usp$=$~sharing.

The purpose of this survey study is 2-fold: 1. to validate the challenges identified by the SLR study, which are already discussed in previous chapters and 2. to explore challenges not mentioned in the literature but faced by practitioners. The survey study also intends to discover the strategies practitioners follow when facing any challenges. A few strategies to overcome these challenges are identified from the SLR and are validated using the survey, and some new strategies are explored. All ethical and legal considerations are kept in mind during survey conduction. Appropriate measures are taken in this regard. Participants are informed in a disclaimer that the data will only be used for research purposes, and no identities will be disclosed. No personal information about respondents is taken during the survey. The survey has two types of questions: open-ended and closed-ended. The first section of the survey is about the demographics of the respondents. This asks about the respondent's role, experience, the methodology they follow, and platform they work with. Later on, this information is used to find different statistical analyses. In the next section, respondents are asked to mention the challenges they face. This section contains both closed-ended and open-ended questions. In Table, all challenges are categorized into five categories. Each question is related to one category. One question is about “Team-related challenges.” In this category, there are four possible challenges. A Likert scale of 1–5 is given against each challenge. Respondents are asked to rank the challenge on a scale of 1–5 depending on its frequency of occurrences. The “N/A” option is also available against each challenge which means that the challenges do not exist. At the end of these four challenges, an open-ended question is given which asks the respondents to mention any other challenges that they face related to the team/crowd. Next to this question, some possible strategies for team-related issues are given and respondents are asked to select the strategies they use to overcome their team-related challenges. In the fourth part of this question, another open-ended question is given to ask for any strategies they follow which are not present in the list. Next to team-related challenges, four parts of questions on the same pattern are designed for communication and coordination-related challenges. This category has five possible challenges. This pattern is followed to design questions for other categories too, which are organizational challenges, software project-related challenges, and task-related challenges. At the end of the survey, two open-ended questions are given. One question asks about any other challenges they face, which may not link to any of the suggested categories, and the other question asks about strategies followed to overcome these challenges.

The survey aims to identify the challenges faced by practitioners who perform crowdsource software development while staying in the Agile setup. Therefore, open-ended questions for strategies are also part of this survey. The results of the survey are analyzed using MS Excel, SPSS, and Python. Different statistical tests are run via SPSS. The Panda library of Python is used for analysis. The details are presented in this chapter.

Statistical analysis was performed to understand how challenges correlated to each other. The significance of metadata on challenges is also identified. Correlation tests and significance tests were conducted on the data. Correlations are found to check how strongly each challenge is related to others, and significant differences are found to check whether the nominal data have any significance over the challenges identified. The survey responses are saved as Excel files and imported to Jamovi for statistical analysis. Jamovi is the alternative to the SPSS tool and is used for statistical analysis.

This section provides a final list of challenges and strategies for Crowd–Agile development. Some challenges and strategies are initially identified from the SLR and validated through the survey. The details of the survey responses are discussed in the previous sections. The correlations and significance of these challenges are also discussed in previous sections. Only those challenges and strategies are included in the final list that are frequently occurring, i.e., which have a mean value of 2.5 or more and a standard deviation of <0.5. The challenges having a mean value of <2.5 are not included in the list. It is worth noting that these data are gathered from the participants who are globally dispersed, so these findings represent the opinion of a diverse group of people working across the globe. The challenges are categorized into different groups. A list of challenges and the strategies for each category is as follows:

The changing nature of software has led to different paradigms of software development. The new paradigms come with their pros and cons. Crowdsource software development is one such paradigm. However, it becomes more challenging when it is used within an Agile environment. Many software development industries perform crowdsourcing software development while following agile methodology. Contradicting characteristics of both approaches make it challenging for practitioners to follow both approaches for effective software development. This study finds the challenges from practitioners who are involved in crowdsourcing software development and agile. An online survey is conducted for this purpose. Survey questions are designed carefully based on SLR outcome, and data are also carefully analyzed. In particular, the challenges faced by practitioners are related to the trust issues among crowd members. Another main factor involved is the coordination and collaboration among crowd workers. As the collaboration among the crowd is challenging, it affects the software development. Task design and assignments for a crowd are also very challenging. Another problem faced by crowd workers is that the knowledge about the project is not shared openly with the crowd, which results in an inappropriate understanding of the project. Differences in the legal considerations of organizations also become challenging. Practitioners have shared some strategies to reduce the impact of these challenges. They have suggested that a communication protocol is to be used and crowd workers should be trained for these tools. Informal group chats and visits are encouraged. It is suggested to share the project goals and specifications with all the crowd workers for clarity. It is deemed important to design a task in such a way that they are loosely coupled. Figure 5 presents the findings of this study.

This is the first hand information from industry practitioners, but the study still has many limitations. The challenges and strategies identified by the practitioners need to be empirically verified. Researchers can use this list to empirically verify the list of challenges and strategies. Another limitation of this study is the limited audience; as the study was conducted till third wave of snowballing, it is suggested to identify the challenges for a larger scale and bigger projects.

The survey questionnaire is carefully designed; however, the survey may pose some construct validity threat as some information might have been missed. To overcome this, a survey was pilot-tested, and the suggestions from the participants were taken to improve survey questionnaires to remove any ambiguity. The data are gathered from the practitioners of industry, so their responses may be based on personal biases or preferences. The authors have a personal suggestion of using Distributed Ledger Technology (DLT) (Gorski and Bednarski, 2020), which is used for sharing data storage for collaborating parties. This is in line with the architecture of crowdsourcing software development. This can be helpful when crowd workers are also following Agile as suggested by the survey participants. DLT can help them store data in a decentralized manner, and the crowd working on the shared data can avoid the challenges they face due to lack of shared knowledge and data. Requirement engineering by the crowd can also be solved by gamification of requirements (Yasin et al., 2021). Gamification is a promising strategy in requirement gathering, leveraging game-like interfaces to engage users more effectively. By incorporating elements of gameplay into the process, gamification encourages greater user participation and precision in articulating their requirements. This approach has shown potential in mitigating communication barriers that can impede accurate requirements gathering. Through interactive and immersive experiences, gamification not only enhances user engagement but also facilitates clearer and more comprehensive communication, ultimately contributing to the accuracy and efficacy of the requirement-gathering process. Authors have another personal suggestion to further conduct research on how these game-based techniques can work for the crowd.

In this study, we have identified the human factors involved in Crowd–Agile software development. These factors involve the challenges that practitioners face during crowdsourcing software development while working in an agile setup. The research produces a verified list of challenges from literature and industry. It is shown that trust issue among the crowd is very challenging, which hinders knowledge sharing and affects the ultimate goal of the project. As the crowd is a group of heterogeneous people, collaboration and coordination among them is very difficult. Many large and complex projects require communication and collaboration among members, the absence of which may create issues in the project. Considering this situation task design also becomes challenging. Some challenges vary for different projects and organizations. Another challenge for crowd members is not having access to project goals and knowledge. However, practitioners also follow some strategies to reduce these challenges, such as sharing a repository of knowledge, providing communication protocols, encouraging informal chat, and making chat groups. This list of validated challenges and strategies is helpful for researchers for further research as the Agile–Crowd is relatively a new term in the literature. This is also helpful to other practitioners in Crowd–Agile development. Practitioners can use this list as a guideline to reduce the challenges they face. The challenges are grouped into categories, and strategies are also suggested against each category. Industry practitioners can identify the relevant category of the challenge they face. Within the challenge category, they can find enlisted strategies, which can help them reduce stated challenges. The research highlights the importance of embracing a pragmatic managerial approach in Crowd–Agile software development. It advises software project managers to implement the suggested strategies to address common challenges such as communication, trust, and collaboration, thereby enhancing the likelihood of project success. By adopting these strategies, managers can also harness innovative software development practices while fostering a sustainable development environment. Researchers can further use this list to empirically verify these challenges. This research can be conducted on a larger scale in future for a larger population. In future, we intend to propose a model for Crowd–Agile development. We are also working on a detailed analysis of these issues identified by the industry.

The raw data supporting the conclusions of this article will be made available by the authors, without undue reservation.

Ethical review and approval was not required for the study on human participants in accordance with the local legislation and institutional requirements. Written informed consent from the patients/participants or patients/participants' legal guardian/next of kin was not required to participate in this study in accordance with the national legislation and the institutional requirements.

SQ: Conceptualization, Data curation, Methodology, Validation, Visualization, Writing – original draft. SI: Conceptualization, Methodology, Supervision, Writing – review & editing. HH: Methodology, Supervision, Writing – review & editing. AA: Writing – review & editing. VK: Writing – review & editing.