Search

Most organizations have begun to adopt agile methods to pursue successful software development. However, the adoption and implementation of agile approaches are facing various challenges. The success of agile software development depends on Critical Success Factors (CSFs), which this study aims to identify and classify based on their relative importance. Through an extensive literature review, these factors are summarized, screened, and categorized into six dimensions. Their evolution is also outlined and analyzed. Then, the factors are illustrated through a bubble chart. Furthermore, this study determines the relevant CFSs that have a significant impact on how effectively can agile software development be implemented in China. The findings suggest certain recommendations to ensure that agile software projects are efficiently implemented in China, maximizing the chances of project success, providing valuable insights and practical guidance. [ABSTRACT FROM AUTHOR]

Currently, there are no adequate methods for dealing with changes in the healthcare system brought about by electronic health applications (eHealth) or the associated ethical implications in practice. This can be attributed to the lack of comprehensive interdisciplinary approaches that could support teams in integrating ethical considerations into the agile software development process. To close this gap, the DARE approach has been developed and tested in interdisciplinary collaborative research. The DARE method is a modular system designed to improve the development of ethically sound software in a deliberative, agile, and responsive manner. [ABSTRACT FROM AUTHOR]

Test-driven development (TDD) is an agile practice of writing test code before production code, following three stages: red, green, and refactor. In the red stage, the test code is written; in the green stage, the minimum code necessary to make the test pass is implemented, and in the refactor stage, improvements are made to the code. This practice is widespread across the industry, and various studies have been conducted to understand its benefits and impacts on the software development process. Despite its popularity, TDD studies often focus on the technical aspects of the practice, such as the external/internal quality of the code, productivity, test smells, and code comprehension, rather than the context in which it is practiced. In this paper, we present a systematic literature review using Scopus, Web of Science, and Google Scholar that focuses on the TDD practice and the influences that lead to the introduction of test smells/anti-patterns in the test code. The findings suggest that organizational structure influences the testing strategy. Additionally, there is a tendency to use test smells and TDD anti-patterns interchangeably, and test smells negatively impact code comprehension. Furthermore, TDD styles and the relationship between TDD practice and the generation of test smells are frequently overlooked in the literature. [ABSTRACT FROM AUTHOR]

In a competitive environment, continually improving new products and services requires new knowledge and novel solutions. Managing projects also requires the careful control of resources for effective delivery. Ambidexterity, the simultaneous achievement of novelty through exploration and efficiency through exploitation, is challenging to achieve in practice. The ways in which companies can achieve ambidexterity are context dependent. It is especially hard to promote new and uncertain concepts in situations where lives are at stake. This article reports on a case study of a safety-critical IT development project that successfully achieved ambidexterity. Leadership behaviors that support ambidexterity in this setting are critical. We highlight four leadership behaviors key to developing an environment where creative solutions can flourish. [ABSTRACT FROM AUTHOR]

Domain-specific standards and documents heavily regulate safety-critical systems. One example is the DO-178C standard for aerospace, which guides organizations to achieve system safety and evidence for their certification. Under such regulated contexts, most organizations use traditional development processes, in contrast to the massive adoption of Agile in the software industry. Among other benefits, Agile methods promise faster delivery and better flexibility to address customer needs. Adopting Agile methods and practices are possible in aerospace because the DO-178C standard does not prescribe concrete software development methods. In spite of that, Agile development is not used in DO-178C contexts. To help change that, our research aims to understand whether and how organizations engineering safety-critical software systems for aerospace may benefit from Agile methods and practices. We analyzed the DO-178C standard and confirm that it is compatible with Agile methods. Then, we present a systematic literature mapping of adopting Agile in software development for aerospace, where we identified significant concerns, recurrent issues, and several challenges. Some real industry aerospace projects provided us with important data and the perspective of domain experts about the pros and cons of Agile methods in this context. We conclude by proposing an agenda of research opportunities to improve safety-critical software development towards agility that we consider worthy of further research, application and confirmation in wider contexts.

In software engineering, technical debt (TD) has been widely investigated, but debt regarding social issues, people, and processes has not been explored as much. It should be noted here that we use nontechnical debt (NTD) as an umbrella term to cover social, process, and people debts. Although the number of studies on NTD in software is increasing, the majority of them are descriptive rather than rigorous, and there is no systematic development of cumulative knowledge. As a result, identifying the fundamental causes of NTD and the associated mitigation techniques in software engineering is challenging. Therefore, this study investigates the scientific evidence regarding NTD till date by conducting a systematic mapping review of software engineering research between January 2000 and October 2021. The search strategy resulted in 175 studies, 17 of which were identified as unique and relevant primary papers. The primary studies show that NTD and TD are inextricably linked. In addition, this study also captured a plethora of causes and mitigation strategies for managing NTD and thus makes four important contributions: (i) highlighting state‐of‐the‐art NTD research; (ii) identification of the reported causes and mitigation strategies in the primary papers; and (iii) determination of opportunities for future NTD research. [ABSTRACT FROM AUTHOR]

This study compares the reliability of estimation, productivity, and defect rate metrics for sprints driven by a specific instance of the agile approach (i.e., scrum) and an agile model-Bbased software engineering (MBSE) approach called the integrated Scrum Model-Based System Architecture Process (sMBSAP) when developing a software system. The quasi-experimental study conducted ten sprints using each approach. The approaches were then evaluated based on their effectiveness in helping the product development team estimate the backlog items that they could build during a time-boxed sprint and deliver more product backlog items (PBI) with fewer defects. The commitment reliability (CR) was calculated to compare the reliability of estimation with a measured average scrum-driven value of 0.81 versus a statistically different average sMBSAP-driven value of 0.94. Similarly, the average sprint velocity (SV) for the scrum-driven sprints was 26.8 versus 31.8 for the MBSAP-driven sprints. The average defect density (DD) for the scrum-driven sprints was 0.91, while that of the sMBSAP-driven sprints was 0.63. The average defect leakage (DL) for the scrum-driven sprints was 0.20, while that of the sMBSAP-driven sprints was 0.15. The t-test analysis concluded that the sMBSAP-driven sprints were associated with a statistically significant larger mean CR, SV, DD, and DL than that of the scrum-driven sprints. The overall results demonstrate formal quantitative benefits of an agile MBSE approach compared to an agile alone, thereby strengthening the case for considering agile MBSE methods within the software development community. Future work might include comparing agile and agile MBSE methods using alternative research designs and further software development objectives, techniques, and metrics.

Restrictive Scrum assumptions make the effectiveness of this approach debatable in projects deviating from typical execution conditions. This article delivers a comprehensive software development approach for both academic and commercial Information Technology (IT) projects effectuated by teams that are hampered by significantly unsystematic participation of project members and mercurial internal communication. The nature of ‘ad-hoc’ projects imposes another level of difficulty in terms of both managing the conduct of such a project and ensuring the quality of the end product. Multicyclic action research enabled a gradual adaptation of the Scrum approach to support such project conditions. This study introduces major alterations to Sprint implementation and minor enhancements within the documentation process to streamline knowledge sharing among Development Team members. Proposed key alterations include the evolution of Daily Scrum towards Weekly Scrum, the possibility of extending Sprints length, the eventuality to switch team members during Sprint due to substantial failure to meet deadlines, having at least two team members responsible for a single Product Backlog Item (PBI) at all times, as well as exclusion of Burndown Chart in favor for Development Team members updating their working time. Positive validation of enhancements in mixed settings confirms that the generic Scrum framework can be adapted to support highly volatile projects. The proposed approach is suitable not only for carrying out software development initiatives that rely heavily on the skills of external experts and/or volunteers. It also supports traditional Scrum teams that seek to reduce their exposure to risk arising from organizational changes.

An innovating organization faces the challenge of how to prioritize distinct goals of novelty and value, both of which underlie innovation. Popular practitioner frameworks like Agile management suggest that organizations can adopt an iterative approach of frequent meetings to prioritize between these goals, a practice we refer to as iterative coordination. Despite iterative coordination's widespread use in innovation management, its effects on novelty and value in innovation remain unknown. With the information technology firm Google, we embed a field experiment within a hackathon software development competition to identify the effect of iterative coordination on innovation. We find that iterative coordination causes firms to implicitly prioritize value in innovation: Although iteratively coordinating firms develop more valuable products, these products are simultaneously less novel. Furthermore, by tracking software code, we find that iteratively coordinating firms favor integration at the cost of knowledge-creating specialization. A follow-on laboratory study documents that increasing the frequency and opportunities to reprioritize goals in iterative coordination meetings reinforces value and integration, while reducing novelty and specialization. This article offers three key contributions: highlighting how processes to prioritize among multiple performance goals may implicitly favor certain outcomes; introducing a new empirical methodology of software code version tracking for measuring the innovation process; and leveraging the emergent phenomenon of hackathons to study new methods of organizing. History: This paper has been accepted for the Organization Science Special Issue on Experiments in Organizational Theory. Funding: The authors gratefully acknowledge financial support from Google LLC, the Harvard Business School Division of Research and Faculty Development, and the National Science Foundation [Grant 1122374]. Supplemental Material: The online appendix is available at https://doi.org/10.1287/orsc.2021.1499. [ABSTRACT FROM AUTHOR]

Restrictive Scrum assumptions make the effectiveness of this approach debatable in projects deviating from typical execution conditions. This article delivers a comprehensive software development approach for both academic and commercial Information Technology (IT) projects effectuated by teams that are hampered by significantly unsystematic participation of project members and mercurial internal communication. The nature of ‘ad-hoc’ projects imposes another level of difficulty in terms of both managing the conduct of such a project and ensuring the quality of the end product. Multicyclic action research enabled a gradual adaptation of the Scrum approach to support such project conditions. This study introduces major alterations to Sprint implementation and minor enhancements within the documentation process to streamline knowledge sharing among Development Team members. Proposed key alterations include the evolution of Daily Scrum towards Weekly Scrum, the possibility of extending Sprints length, the eventuality to switch team members during Sprint due to substantial failure to meet deadlines, having at least two team members responsible for a single Product Backlog Item (PBI) at all times, as well as exclusion of Burndown Chart in favor of Development Team members updating their working time. Positive validation of enhancements in mixed settings confirms that the generic Scrum framework can be adapted to support highly volatile projects. The proposed approach is suitable not only for carrying out software development initiatives that rely heavily on the skills of external experts and/or volunteers. It also supports traditional Scrum teams that seek to reduce their exposure to risk arising from organizational changes. [ABSTRACT FROM AUTHOR]

Various approaches toward the development of sustainable software systems have been proposed by the requirements engineering community over the last decade. We conducted a systematic mapping study, analyzed 55 publications, and identified 29 approaches that have been published since the year 2000. We analyzed how the approaches evolved over time and how the publications and authors are influenced by each other. Furthermore, the approaches are analyzed in terms of their supported requirements engineering activities, along with the evidence provided in the publications. Additionally, we also analyzed which sustainability definitions have been used, if an iterative application of the approaches is discussed, and if the approaches also provide a tool-support for practitioners. We noticed an increase of publications on requirements engineering approaches toward sustainability in the last years, whereas a majority discuss sustainability based on the same multi-dimensional concept. Although different case studies have been already conducted, we noticed a lack of an industrial application. Our main findings concern the need of an evaluation on how the proposed requirements engineering approaches can also be applied in agile software development processes. Additionally, we also promote the development of supporting software tools to support practitioners in adapting the proposed approaches. [ABSTRACT FROM AUTHOR]

This study compares the reliability of estimation, productivity, and defect rate metrics for sprints driven by a specific instance of the agile approach (i.e., scrum) and an agile model-Bbased software engineering (MBSE) approach called the integrated Scrum Model-Based System Architecture Process (sMBSAP) when developing a software system. The quasi-experimental study conducted ten sprints using each approach. The approaches were then evaluated based on their effectiveness in helping the product development team estimate the backlog items that they could build during a time-boxed sprint and deliver more product backlog items (PBI) with fewer defects. The commitment reliability ( C R ) was calculated to compare the reliability of estimation with a measured average scrum-driven value of 0.81 versus a statistically different average sMBSAP-driven value of 0.94. Similarly, the average sprint velocity ( S V ) for the scrum-driven sprints was 26.8 versus 31.8 for the MBSAP-driven sprints. The average defect density ( D D ) for the scrum-driven sprints was 0.91, while that of the sMBSAP-driven sprints was 0.63. The average defect leakage ( D L ) for the scrum-driven sprints was 0.20, while that of the sMBSAP-driven sprints was 0.15. The t-test analysis concluded that the sMBSAP-driven sprints were associated with a statistically significant larger mean C R , S V , D D , and D L than that of the scrum-driven sprints. The overall results demonstrate formal quantitative benefits of an agile MBSE approach compared to an agile alone, thereby strengthening the case for considering agile MBSE methods within the software development community. Future work might include comparing agile and agile MBSE methods using alternative research designs and further software development objectives, techniques, and metrics. [ABSTRACT FROM AUTHOR]

The implementation of digital transformation programs requires careful allocation of software developers to a variety of digital products and services with different levels of modularity. This paper investigates how deadline orientation (an individual‐level preference of developers for completing work close to deadlines) and architectural modularity (a characteristic of products) influence central outcomes in software development. We argue that architectural modularity positively interacts with deadline orientation to influence software quality and the job satisfaction of developers. Our empirical analyses, using rare and high‐quality data from 131 software developers and 29 product owners working at a captive software development center in India of a leading global software firm, confirm our hypotheses. We contribute to the literature on software development by showing that the fit between the technological characteristics of the software product (i.e., architectural modularity) and people factors (i.e., the temporal work style preferences of developers) plays an important role in shaping both software quality and job satisfaction. Our study has wider implications for the literature on software development, temporal work styles, and architectural modularity. It is instructive for practitioners tasked with hiring or allocating software developers for software products with varying technological characteristics in their digital transformation efforts. Highlights: The success of digital transformation efforts often requires the development of new software in a quick and iterative manner with high quality and the ability to retain software developers through high job satisfaction.The study considers two key factors in software development: deadline orientation, defined as the preference for doing work shortly before deadlines versus an alternative approach of doing most of the work either upfront or with a steady pace throughout, and software modularity.The study finds that ensuring a fit between developers' deadline orientation and software modularity is important, as deadline‐oriented developers will produce higher‐quality software and will be more satisfied with their job in regard to software with high architectural modularity. [ABSTRACT FROM AUTHOR]

In today's rapidly evolving information technology sectors, agile methodologies have been employed by software development organizations to facilitate the large-scale, efficient, and swift development of digital products. Notably, it is a widely accepted principle that an increase in project delivery predictability results from more effective portfolio management. Despite the abundant resources within software engineering that address project management and agile development performance, the measurement of portfolio delivery performance integrating sustainability principles is under-researched. This paper aims to underline a solution to bridge this gap by proposing a data-driven scoring model explicitly designed for software firms to integrate sustainability metrics into their project and portfolio performance assessment. The model is primarily aimed at monitoring and enhancing delivery performance while also reinforcing the sustainability of the software development lifecycle. A thorough literature review was conducted to discern gaps in existing practices, followed by development of a scoring model melded with delivery and sustainability metrics seamlessly. Validated through a case study, the findings reveal that the model influences the performance and sustainability dynamics within software development entities. The insights gained from this study underscore the pivotal role of a harmonized delivery and sustainability metrics system in enhancing the sustainability and efficiency of software development undertakings. [ABSTRACT FROM AUTHOR]

Model-Based Software Engineering (MBSE) is an architecture-based software development approach. Agile, on the other hand, is a light system development approach that originated in software development. To bring together the benefits of both approaches, this article proposes an integrated Agile MBSE approach that adopts a specific instance of the Agile approach (i.e., Scrum) in combination with a specific instance of an MBSE approach (i.e., Model-Based System Architecture Process—“MBSAP”) to create an Agile MBSE approach called the integrated Scrum Model-Based System Architecture Process (sMBSAP). The proposed approach was validated through a pilot study that developed a health technology system over one year, successfully producing the desired software product. This work focuses on determining whether the proposed sMBSAP approach can deliver the desired Product Increments with the support of an MBSE process. The interaction of the Product Development Team with the MBSE tool, the generation of the system model, and the delivery of the Product Increments were observed. The preliminary results showed that the proposed approach contributed to achieving the desired system development outcomes and, at the same time, generated complete system architecture artifacts that would not have been developed if Agile had been used alone. Therefore, the main contribution of this research lies in introducing a practical and operational method for merging Agile and MBSE. In parallel, the results suggest that sMBSAP is a middle ground that is more aligned with federal and state regulations, as it addresses the technical debt concerns. Future work will analyze the results of a quasi-experiment on this approach focused on measuring system development performance through common metrics.

Test-driven development (TDD) is an agile practice of writing test code before production code, following three stages: red, green, and refactor. In the red stage, the test code is written; in the green stage, the minimum code necessary to make the test pass is implemented, and in the refactor stage, improvements are made to the code. This practice is widespread across the industry, and various studies have been conducted to understand its benefits and impacts on the software development process. Despite its popularity, TDD studies often focus on the technical aspects of the practice, such as the external/internal quality of the code, productivity, test smells, and code comprehension, rather than the context in which it is practiced. In this paper, we present a systematic literature review using Scopus, Web of Science, and Google Scholar that focuses on the TDD practice and the influences that lead to the introduction of test smells/anti-patterns in the test code. The findings suggest that organizational structure influences the testing strategy. Additionally, there is a tendency to use test smells and TDD anti-patterns interchangeably, and test smells negatively impact code comprehension. Furthermore, TDD styles and the relationship between TDD practice and the generation of test smells are frequently overlooked in the literature.

Communication is a powerful, universal, everyday activity that impacts many, if not all, aspects of our lives. The importance and complexities of communication are however still often overlooked. Inadequate communication during software development projects at a medium-sized enterprise, Company-GIS (CGIS), caused delays in project tasks, negatively impacting quality, on-time delivery, and delivery within budget. In this study, we argue that a collaborative methodology was required to ensure adequate diagnosis of the problem, creating multiple artefacts to address the communication problems. We argue that a recent research methodology called action design research (ADR) is best suited for a practice-inspired problem. Acknowledging the latest developments within the ADR discipline, we believe that the elaborated action design research (eADR) process model addressed the need to explicitly show our knowledge contributions in the form of two artefacts: (1) An Agile requirement engineering solution (ARES) to address the communication problems, the primary artefact; and (2) A taxonomy of perceived communication problems, a secondary artefact. In this experience report, we indicate that the eADR process model was instrumental in facilitating diagnosis, followed by design, implementation, and evolution of the primary artefact, the ARES. The practical demonstration of ARES also highlighted the need for further evolution of the eADR as a method artefact. Based on our reflections on applying the eADR, we suggest changes to the eADR including an additional design cycle phase, suggestion, between problem formulation and artefact creation, as well as merging reflection and learning into a single phase. [ABSTRACT FROM AUTHOR]

Model-Based Software Engineering (MBSE) is an architecture-based software development approach. Agile, on the other hand, is a light system development approach that originated in software development. To bring together the benefits of both approaches, this article proposes an integrated Agile MBSE approach that adopts a specific instance of the Agile approach (i.e., Scrum) in combination with a specific instance of an MBSE approach (i.e., Model-Based System Architecture Process—"MBSAP") to create an Agile MBSE approach called the integrated Scrum Model-Based System Architecture Process (sMBSAP). The proposed approach was validated through a pilot study that developed a health technology system over one year, successfully producing the desired software product. This work focuses on determining whether the proposed sMBSAP approach can deliver the desired Product Increments with the support of an MBSE process. The interaction of the Product Development Team with the MBSE tool, the generation of the system model, and the delivery of the Product Increments were observed. The preliminary results showed that the proposed approach contributed to achieving the desired system development outcomes and, at the same time, generated complete system architecture artifacts that would not have been developed if Agile had been used alone. Therefore, the main contribution of this research lies in introducing a practical and operational method for merging Agile and MBSE. In parallel, the results suggest that sMBSAP is a middle ground that is more aligned with federal and state regulations, as it addresses the technical debt concerns. Future work will analyze the results of a quasi-experiment on this approach focused on measuring system development performance through common metrics. [ABSTRACT FROM AUTHOR]

The success of agile in software development (SD) has sparked the application of agile in non-SD domains such as business management to improve operational efficiency and innovation. Despite the rising industry demands for agile talents in the non-SD domains, agile education falls short of client-sponsored projects, calling into question the sustainability of agile education. This study makes up for the gap and illustrates an eight-month endeavor where scrum practices and values were imbued in a client-sponsored project. The analysis of qualitative and quantitative data gathered throughout the eight-month project illustrates a large disparity among students in their scrum application, reveals top challenges faced by students in their scrum application, and suggests the impact of the scrum application on the quality of student work. The findings of the study set a solid foundation based on which future agile education could be enhanced to strengthen the sustainability of agile education to meet industries' rising demands for agile talents in non-SD domains. [ABSTRACT FROM AUTHOR]

The market for software development projects is dynamic and complex. The stakeholders involved in the software development process come from different organisational positions and therefore have varying interests and expectations from the product. Effective project management practices enable successful on-time delivery of high-quality product. It is essential to identify the stakeholder roles and responsibilities to effectively manage the development practices within the organisation. Elucidating the stakeholder roles will enable stakeholder management via effective communication and sustainable practices that reflect stakeholder interests. This study elucidates the roles and responsibilities of the stakeholders associated with Agile software development projects. The study identifies that for effective stakeholder management practices understanding of the stakeholder roles and interests is vital. Additionally, application of Agile software development methodology would result in successful development of high-quality software solutions.

Proses bisnis pada bisnis toko Sepatu Kaki Kaki pada bagian produk dan manajemen transaksi belum memaksimalkan sistem aplikasi yang ada. Hal ini membuat proses bisnis yang dilakukan oleh toko menjadi kurang efisien. Metodologi yang digunakan yaitu Scrum, salah satu model agile. Kelebihannya antara lain persyaratan yang fleksibel, waktu produksi aplikasi yang lebih cepat, dan anggota tim yang tidak banyak. Tujuan dari penelitian ini adalah untuk mengelola produk secara efektif dan membantu menganalisis penjualan berdasarkan tujuan yang diharapkan di masa depan. Bahasa pemrograman Kotlin - Android Native dengan BaaS (Backend as a Service) Firebase digunakan untuk mengembangkan aplikasi ini. Adapun penelitian ini akan menghasilkan sebuah aplikasi android yang mempercepat dan mempermudah pengelolaan produk, mengetahui persediaan produk terbaru.

Developing sustainable software for the scientific community requires expertise in software engineering and domain science. This can be challenging due to the unique needs of scientific software, the insufficient resources for software engineering practices in the scientific community, and the complexity of developing for evolving scientific contexts. While open‐source software can partially address these concerns, it can introduce complicating dependencies and delay development. These issues can be reduced if scientists and software developers collaborate. We present a case study wherein scientists from the SuperNova Early Warning System collaborated with software developers from the Scalable Cyberinfrastructure for Multi‐Messenger Astrophysics project. The collaboration addressed the difficulties of open‐source software development, but presented additional risks to each team. For the scientists, there was a concern of relying on external systems and lacking control in the development process. For the developers, there was a risk in supporting a user‐group while maintaining core development. These issues were mitigated by creating a second Agile Scrum framework in parallel with the developers' ongoing Agile Scrum process. This Agile collaboration promoted communication, ensured that the scientists had an active role in development, and allowed the developers to evaluate and implement the scientists' software requirements. The collaboration provided benefits for each group: the scientists actuated their development by using an existing platform, and the developers utilized the scientists' use‐case to improve their systems. This case study suggests that scientists and software developers can avoid scientific computing issues by collaborating and that Agile Scrum methods can address emergent concerns. [ABSTRACT FROM AUTHOR]

Agile development is known for efficient software development practices that enable teams to quickly develop software to cope with changing requirements. Although there is evidence that agile practices are helpful in such environments, the literature does not inform us as to whether agile practices can also be beneficial in hyper-agile environments. Such environments are characterized by an extremely fast pace of change with fluid requirements. COVID-19 vaccine distribution is one such problem that governments have had to deal with. To solve this problem, governments need to come up with robust responses by formulating teams that have the capability to provide software solutions enabling information visibility into the vaccine distribution process. Such emergent teams need to quickly understand the distribution process, oftentimes define the process itself because it might be non-existent, and build software systems to solve the problem in a matter of days. Not much is known about how systems can be developed at such a fast pace. We adopt a clinical research methodology and employ agile software development practices to develop such a mission-critical system. In the process of building the system, we learn important lessons that can be used to adapt and extend agile methodologies to be used in hyper-agile development environments. We offer these lessons as important first steps to understanding the best practices needed to develop software systems that have the capability to provide visibility into the unprecedented health challenge of distribution of life-saving COVID-19 vaccine. [ABSTRACT FROM AUTHOR]

The key objective of this paper is to investigate the evolution of hybrid software development methods and highlight the main difficulties that arise with regard to information systems (IS) auditing. While technology firms today are under constant pressure to deliver software faster due to emerging needs worldwide, this continuous effort leads to innovative development models, apparently driven by practice. Since modern software development is neither pure linear phases progression nor agile, a challenge arises with regards to selecting the appropriate combination of approaches that serve to reach goals and assure value creation for organizations. [ABSTRACT FROM AUTHOR]

Background: A challenge facing researchers conducting mobile health (mHealth) research is the amount of resources required to develop mobile apps. This can be a barrier to generating relevant knowledge in a timely manner. The recent rise of "no-code" software development platforms may overcome this challenge and enable researchers to decrease the cost and time required to develop mHealth research apps. Objective: We aimed to describe the development process and the lessons learned to build Pathverse, a no-code mHealth app design platform. Methods: The study took place between November 2019 and December 2021. We used a participatory research framework to develop the mHealth app design platform. In phase 1, we worked with researchers to gather key platform feature requirements and conducted an exploratory literature search to determine needs related to this platform. In phase 2, we used an agile software framework (Scrum) to develop the platform. Each development sprint cycle was 4 weeks in length. We created a minimum viable product at the end of 7 sprint cycles. In phase 3, we used a convenience sample of adults (n=5) to gather user feedback through usability and acceptability testing. In phase 4, we further developed the platform based on user feedback, following the V-model software development process. Results: Our team consulted end users (ie, researchers) and utilized behavior change technique taxonomy and behavior change models (ie, the multi-process action control framework) to guide the development of features. The first version of the Pathverse platform included features that allowed researchers to (1) design customized multimedia app content (eg, interactive lessons), (2) set content delivery logic (eg, only show new lessons when completing the previous lesson), (3) implement customized participant surveys, (4) provide self-monitoring tools, (5) set personalized goals, and (6) customize app notifications. Usability and acceptability testing revealed that researchers found the platform easy to navigate and that the features were intuitive to use. Potential improvements include the ability to deliver adaptive interventions and add features such as community group chat. Conclusions: To our knowledge, Pathverse is the first no-code mHealth app design platform for developing mHealth interventions for behavior. We successfully used behavior change models and the behavior change technique taxonomy to inform the feature requirements of Pathverse. Overall, the use of a participatory framework, combined with the agile and hybrid-agile software development process, enabled our team to successfully develop the Pathverse platform. [ABSTRACT FROM AUTHOR]

Digital transformation requires usage of effective software development methods, techniques, and tools for innovative IT solutions development. Agile methods, that are broadly adopted in recent years, fulfil this role. The aim of this report is to point to Agile surveys conducted in the Czech Republic. First survey was focused on the state of agile method adoption in companies in the Czech Republic and was conducted in 2019. Second survey, conducted in 2020, was focused on education of agile approaches at universities in the Czech Republic. The report shows, there is a contradiction between practise needs and the status of university education in the Czech Republic which is compared to the status in the world.

Software development method, which does not have any faults or gaps in project implementation, has not been elaborated so far. Due to this reason, the authors have decided to perform this study to make it easier for the companies, which use one of the agile development methods, to better foresee potential risks and to deal with their consequences. The aim of the research is to identify and classify risks in agile software development methods and the related projects based on the obtained survey data. To achieve the goal, the authors have developed evaluation criteria, as well as implemented practical questionnaire in various software development companies. From the obtained survey data, the risks are classified according to various factors, i.e., the changing highest and lowest priorities and needs in various projects. Thus, the obtained research results can be applied in various areas of project development, changing the order of priority factors.

Software development is a complex process that requires skills in mathematics and physics. Moreover, it usually includes collaboration with other people. To get a precise understanding of the way such a process is organized, we need to understand its essence. Technical knowledge is crucially important for any developer; however, another important characteristic of any software engineer is creativity. In this article, we look at one particular artistic practice [filmmaking] that involves both these latter characteristics to determine whether insights from such a practice can be applied in the IT industry and vice versa.

Aim/Purpose: This research aims to describe layering of career-like experiences over existing curriculum to improve perceived educational value. Background: Feedback from students and regional businesses showed a clear need to increase student's exposure to career-like software development projects. The initial goal was to develop an instructor-optional project that could be used in a single midlevel programming course; however, the pilot quickly morphed into a multi-year study examining the feasibility of agile projects in a variety of settings. Methodology: Over the course of four years, an agile project was honed through repeated Design Based Research (DBR) cycles of design, implementation, testing, communication, and reflective analysis. As is common with DBR, this study did not follow single methodology design; instead, analysis of data coupled with review of literature led to exploration and testing of a variety of methodologies. The review phase of each cycle included examination of best practices and methodologies as determined by analysis of oral and written comments, weekly journals, instructor feedback, and surveys. As a result of participant feedback, the original project was expanded to a second project, which was tested in another Software Engineering (SE) course. The project included review and testing of many academic and professional methodologies, such as Student Ownership of Learning, Flipped Classroom, active learning, waterfall, agile, Scrum, and Kanban. The study was homogenous and quasi-experimental as the population consisted solely of software engineering majors taking required courses; as based on validity of homogenous studies, class sizes were small, ranging from 8 to 20 students. Close interactions between respondents and the instructor provided interview-like settings and immersive data capture in a natural environment. Further, the iterative development practices of DBR cycles, along with the inclusion of participants as active and valued stakeholders, was seen to align well with software development practitioner practices broadly known as agile. Contribution: This study is among the first to examine layering a career-like software development project on top of a course through alteration of traditional delivery, agile development, and without supplanting existing material. Findings: In response to industry recommendations for additional career-like experiences, a standalone agile capstone-like project was designed that could be layered over an existing course. Pilot data reflected positive perceptions of the project, although students did not have enough time to develop a working prototype in addition to completing existing course materials. Participant feedback led to simultaneous development of a second, similar project. DBR examination of both projects resulted in a simplified design and the ability to develop a working prototype, if and only if the instructor was willing to make adjustments to delivery. After four years, a solution was developed that is both stable and flexible. The solution met the original charge in that it required course delivery, not course material, to be adjusted. It is critical to note that when a working prototype is desired, a portion of the lecture should be flipped allowing more time for guided instruction through project-focused active learning and study group requirements. The results support agile for standalone software development projects, as long as passive delivery methods are correspondingly reduced. Recommendations for Practitioners: Based on the findings, implementation of a career-like software development project can be well received as long as active learning components are also developed. Multiple cycles of DBR are recommended if future researchers wish to customize instructional delivery and develop complex software development projects. Programming instructors are recommended to explore hybrid delivery to support development of agile career-like experiences. Small class sizes allowed the researchers to maintain an interview-like setting throughout the study and future studies with larger classes are recommended to include additional subject matter experts such as graduate students as interaction with a subject matter expert was highly valued by students. Recommendations for Researchers: Researchers are recommended to further examine career-like software development experiences that combine active learning with agile methods; more studies following agile and active learning are needed to address the challenges faced when complex software development is taught in academic settings. Further testing of standalone agile project development has now occurred in medium sized in person classes, online classes, independent studies, and creative works research settings; however, further research is needed. Future research should also examine the implementation of agile projects in larger class sizes. Increasing class size should be coupled with additional subject matter experts such as graduate students. Impact on Society: This study addresses professional recommendations for development of agile career-like experiences at the undergraduate level. This study provides empirical evidence of programming projects that can be layered over existing curriculum, with no additional cost to the students. Initial feedback from local businesses and graduates, regarding agile projects with active learning, has been positive. The area business that refused to hire our underprepared SE graduates has now hired several. Future Research: Future research should explore layering agile projects over a broader range of software development courses. Feedback from hiring professionals and former students has been positive. It is also recommended that DBR be used to develop career-like experiences for online programming courses. [ABSTRACT FROM AUTHOR]