Re-Evaluating Media Richness Theory in Software Development Settings

Enterprise designers need to continuously re-design their enterprise, re-evaluating the technologies that are available to digitize their operations. Although light-weight agile software development approaches are favored by software development service providers, additional requirements elicitation practices should be incorporated when scaling factors apply, since design team members need to have a shared understanding of the operating context and high-level requirements. Research indicated that the organization construction diagram (OCD) could be useful to create a shared context for enterprise operation, linking detailed functional requirements to this shared context during software development. Although the OCD is concise, its associated concepts are abstract and an additional story-card method (SCM) is needed to transform existing enterprise implementations into an OCD. Since additional evaluation of the SCM was required, this study focused on a real-world demonstration of the SCM at a Fintech company where an agile software development approach is applied. The results indicate that the SCM is useful when incorporated within an agile software development approach.

Bridging knowledge boundaries among project team members is essential to prevent delays or complete failure of software development projects. Prior researchers have reported that software prototypes can be used to help bridge knowledge boundaries between team members in traditional software development settings, yet their use in an agile development setting remains unexplored. Agile development centers the interactions between team members on emerging representations of the prototype whose properties are prone to change over time. Therefore, we conducted an in‐depth study of an agile development project to enhance our understanding on how software prototypes are used as boundary objects in a distributed team setting. Our analyses of team member interactions during 46 virtual meetings that took place over a period of 6 months revealed four different prototype use practices (exemplifying, contrasting, relating, framing) that were effective in bridging syntactic, semantic, or pragmatic knowledge boundaries. We also provide empirically grounded evidence of how variations in object properties can afford different use practices, how the use practices take advantage of these properties, and how object properties are reshaped through these use practices as different types of knowledge boundaries are bridged. These findings bear important implications for research on prototypes as boundary objects in software development in particular and boundary object use in general.

Offhand, the agile and the disciplined software development approaches seem contradicting. More and more, software development organizations however strive at implementing an agile software development approach while still being compliant to a quality assurance standard. Researchers are discussing the combinability and compatibility of these two approaches. Through a review of the literature, the purpose of this chapter is to determine whether the agile and the disciplined software development approaches are combinable or just compatible, in particular to identify the main challenges of using an agile software development approach in a disciplined setting. The review shows that the agile and the disciplined approaches are compatible, but not combinable. It is possible to implement agile practices and principles in a development process compliant with a quality standard, but the regulations of the standard makes it impossible to implement a full agile software development process without compromising the agility. The main challenges, when balancing the agility and discipline in a project, are how to determine the right level of documentation and how to overcome the differences in the way requirements are handled.

The increasing popularity of agile software development has significantly changed the way organizations plan, design, and implement software applications. However, considering the complexity involved with software development, the decision to choose an agile approach over the traditional waterfall approach is not straightforward. Organizations should carefully evaluate a variety of factors when choosing a development approach. In this teaching case study, the authors provide a discussion case to facilitate the students’ learning of using agile vs. traditional approaches in software development. This case study is developed based on experiences of multiple real-world software development projects and the literature on software development. It is designed to reflect the complexities students are likely to encounter in actual software development projects. The case can be used in undergraduate or graduate level management information systems courses that cover agile software development approaches. Students can gain an understanding of factors to consider when choosing a development approach, which tailors to the organization, the project environment, and the project team.

Software development procedures are constantly evolving to monitor and evaluate the quality and to save money and time. Numerous organizations are migrating away from traditional business models and toward agile methodologies. The purpose of this paper is to illustrate both traditional and agile software development approaches and the numerous techniques associated with them. This analysis conducted identical investigations into two radically different ways of thinking about product development: traditional methods and agile approaches. The paper is supported by several studies commissioned by various organizations to determine the transition from the traditional to the agile paradigm. The follow-up and data analysis explore and reveal changes and emerging trends that arose announcement of the agile technique which is mentioned in this paper, and also has gained increasing prominence in agile in product development over the last couple of years.

Agile practices have recently gained popularity among large number of companies as a mechanism for reducing cost and increasing ability to handle change in dynamic market conditions. Based on the principles of the Agile manifesto [1, 2], researchers and practitioners have proposed several software development approaches such as Extreme Programming, Scrum and Feature-Driven Development. These and other agile approaches have had significant impact on industrial software development practices. However, there is also a significant concern and perplexity about the role and importance of the issues related to a system’s software architecture, which is considered one of the most important initial design artefacts. It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. Many practitioners of Agile approaches appear to view software architecture in the context of the plan-driven development paradigm [3]. For them, upfront design and evaluation of software architecture requires too much work, which may have very little value to the customers of a system. Hence, they perceive architectural work as part of high ceremony processes, which usually require large amount of documentation. We maintain that these two seemingly opposing views to software engineering can be integrated but it requires that experts from both fields work together to overcome evident challenges in bridging these two paradigms together. Indeed, software architecture researchers and practitioners appear to believe that sound architectural practices cannot be followed using Agile approaches. However, these two extreme views of Agile and architecture appear to neglect that many agile experts emphasises the importance of paying attention to good design and architecture early in the development process [4, 5]. Recently, there is growing recognition of the importance of paying more attention to architectural aspects in agile approaches [3, 6, 7]. We argue that there is a vital need for devising a research agenda for identifying and dealing with architecture-centric challenges in agile software development. Such research agenda should make it possible to guide the future research on integrating architecture-centric methods in agile approaches and give advice to the software industry on dealing with architecture related challenges. Some of the questions to stimulate discussion in the workshop are: What is the role of software architecture in Agile software development? What are the key architecture-centric challenges and potential solutions in Agile software development projects? What is the strength of the evidence that attention to architectural issues can be counterproductive in Agile development or vice versa? What are the prerequisites for integrating Architecture-Centric methods in agile development and potential implications of such integration?

Many software development teams face the problem of selecting a suitable development approach fitting to their specific context. According to them, the combination of agile and traditional approaches seems to be the solution to handle this problem. However, the current state of practice with respect to hybrid approaches is not sufficiently examined. Most studies focus either on traditional or on agile methods, but the combination of both is not well investigated yet. The “Hybrid dEveLopmENt Approaches in software systems development” (HELENA) study performs a large-scale international survey in order to gain insights into the distribution of hybrid approaches. So far, the study indicates several reasons why companies combine agile and traditional approaches. The hybrid approaches aim at improving the frequency of delivery to customers, the adaptability and the flexibility of the process to react to change. Furthermore, it is the aim to increase the productivity. In this publication, we present the current state of the German results and outline the next steps.

This paper presents the arguments for creation and validation of a composite process framework (CASDPF) that would enable formal modeling and management of the application software development & integration. The arguments for this research are based on the practical understanding of the authors that no single 'type' of process appears to be suitable for software development projects. Increasingly, there appears to be a need to use high-ceremony 'waterfall' type approaches at the programme and project management level, whereas at individual level, 'agile' aspects of a process seem to help. A composite process framework has the potential for accepting this responsibility of balancing the modeling with software projects, as is argued in this paper. The development of software application systems, and management of the corresponding systems development life cycle is considered complex, time consuming and costly. This is so because, as argued by Unhelkar [5], the nature, type and size of software projects are different and so they result in differing requirements, development and implementation procedures.. Marks [3] indicates that the Waterfall model does not provide good project planning control and risk management. According to Marks [3], the iterative process has many strengths such as rapid feedback from users based on the actual system prototype, flexibility to address system evolving requirements, the rapid discovery of design flaws, and ease of deploying new functionality. An iterative project might run the risk of never ending process, due to its ability to react to continuous changes of business needs, and incomplete system documentation due to the fact that there is no scheduled period for documentation. The agile methods are suitable for projects with requirements that are rapidly changing and not very suitable for systems that have high criticality, reliability and safety requirements [2]. Agile methods are evaluated based on project criticality, size and requirements. Boehm [1] Spiral life-cycle model that combines features of the prototyping and Waterfall model [4] is favored for large, expensive, and complicated projects. The following model as shown in (Figure 1). Shows that the Waterfall approach is best for project management as it gives the project manager full control over the project life-cycle. The iterative approach is the best during the analysis, design and implementation phases since it gives the project team more flexibility to address evolving system requirements and to iterate within these phases to ensure a comprehensive analysis and design has been done. The Agile approach is best during the implementation and testing phases since it helps produce incremental small software releases within a short iterative development cycles. The Composite approach will split the project into a set of increments; each increment will consist of a set of the project life-cycle phases. For each increment, it will bring the best aspects of available software development processes (Waterfall, Iterative and Agile) together that can be used to develop and manage application software development.

New methods and best practices are being used to enhance the software lifecycle because of the recent expansion of the software industry. Agile development approaches have also been widely used, and they have positively affected people's lives and the operations of enterprises. Although agility makes working with developers easier, it does not offer enough chances to collaborate with users. In early Agile formulations, User Experience (UX) was not recognized as a distinct part of software development. The tricky part is figuring out where to integrate them and how to merge them so that the two parts interact. Combining user experience with Agile approaches is the subject of this research's proposed systematic literature review (SLR). This research found ten relevant studies highlighting the growing interest and research in merging these two critical areas of software engineering. In conclusion, this research found some papers or studies integrating user experience into Agile methodologies. Many techniques are used, and all studies have different approaches to integrate them.

: The usage of agile software development methods is increasing and so is the need for enhancing the collaboration between the different stakeholders. Thus, we chose to investigate the communication tools and challenges across the different boundaries and consequently deduce implications for practitioners. This research addresses inter-team communication by exploring the practitioners' perception on the different communication tools and the challenges faced at the three different boundaries, inter-team, team and customers, and geographically separated teams. We aim to enhance the productivity of software development through enhancing the communication between the different stakeholders. In this research, we use grounded theory approach to gather data from semi-structured open-ended interviews with practitioners in a geographically separated software development company. The findings observed three main inter-team communication means (Slack, Trello, face-to-face) used by practitioners, and how the preference differs among practitioners. This study also focuses on the different challenges faced, such as absence of communication during user story dependency, unclear customer requirements, and cultural differences, when implementing agile across different geographical locations. Our study discovers how team boundaries are overcome when team members adapt to other teams’ preferred communication tool and enhance the boundary spanners’ role. Furthermore, the study highlights how novice and mature teams require a transition time to adjust to the agile methods.

Contemporary software is increasingly developed using an agile development approach, yet the supplier is generally selected as a result of a waterfall-style competitive tendering and contracting process. The procurement activity may be incompatible with an agile elaboration of requirements and development of functionality, and lead to sub-optimal outcomes. This paper examines the interaction of the procurement and software development lifecycles, explores potential causes of project or system failures and suggests some improvements based on a successful 10 year project between ADI Limited and the Australian Department of Defence.

Software maintenance is one of the most debated phases in software development process for so many years. Having reputed as the most expensive phase of software development life cycle (SDLC), it utilizes the maximum share of the overall project costs as well as time. Agile software development provides opportunities to assess the direction of a project throughout the development lifecycle. However, it does not ideally map with the existing software maintenance process. One of the highlighted issues is the difficulty for searching of information as well as lack of knowledge to solve the maintenance problems within certain time frame. Thus, the main objective of this study is to improve the governance of software maintenance process in an Agile development team. In doing so, a tool named Axita is developed to assist the software maintenance team for storing of information in central data repository and managing projects in more efficient and timely manner. Based on the literature review as well as mapping between the agile software development and the existing ISO software maintenance process, we also proposed six best practices to better govern the software maintenance process in an Agile development team, to overcome the difficulty of information finding and reduce the time spent to solve the maintenance issues. We believe that our study and findings complement the efforts that have been put forth in improving the way we manage software maintenance thus enhance the efficiency of the software development process. Â

Purpose – The purpose of this paper is to propose Knowledge4Scrum, a novel knowledge management tool for agile distributed teams. Agile software development (ASD) refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The two most widely used methodologies based on the agile philosophy are scrum and extreme programming. Whichever methodology is considered, agile teams usually consist of few members and are collocated under the same roof. However, nowadays, agile practices for distributed development are gaining much momentum. The main reasons behind such practice are cheaper skilled labour, minimizing production cost, reducing time to market and increasing the quality and performance of projects. Along with the benefits obtained through globally distributed development, there are, however, many difficulties faced by various organisations. These problems are caused mostly due to distance, time and cultural differences. To meet up with the level of complexity of projects, ASD also has to keep up with many challenges, especially in cases of distributed teams. Four major challenges have been identified. First, the introduction of global software development entails a number of difficulties, especially related to knowledge sharing. For instance, lack of transparency is frequently observed within such teams, whereby a team member is totally unaware of the activities of his/her colleagues. Second, the unavailability of team members due to time zone differences adds up to the list of problems confronted by distributed teams. Third, there can be misunderstanding amongst the team member due to communication problems, especially in cases where the mother language of the team members is different. Fourth, a common issue faced by distributed teams is the loss of knowledge when an employee resigns from his/her post. Design/methodology/approach – Based on the main problems outlined above, what has been proposed is Knowledge4Scrum, a novel knowledge management tool for agile distributed teams. Knowledge4Scrum will act as a global repository for knowledge sharing in Scrum distributed teams with the possibility of creating new knowledge through data mining techniques. Valid past projects data have been collected to train and test the data mining models. The research also investigates the suitability of knowledge management in Scrum distributed teams to address the various challenges addressed above. Findings – Knowledge4Scrum supports the four knowledge management processes, namely, knowledge creation/acquisition, knowledge storage, knowledge dissemination and knowledge application. It has been found that the aforementioned tool satisfactorily addressed issues of distance, time and cultural differences that crop-up in distributed development teams. Data mining has been the main aspect for the knowledge creation and application processes, whereby new knowledge has been determined by examining and extracting patterns from existing data found in the repository. Originality/value – A major feature of the Knowledge4Scrum tool lies in the knowledge creation and application section, where a number of data mining techniques have been utilised to identify trends and patterns in past data collected. When compared to the COnstructive COst MOdel to estimate project duration, Knowledge4Scrum gives more than satisfactory results. Such functionalities will actually help managers for future project planning and in decision-making.

In the past decade, there have been a number of notable changes in industrial software engineering, including the movement towards agility. The Agile Manifesto characterizes the term “agile”, and lists a set of principles that form a basis for agile methodologies [1], such as Extreme Programming (XP), OpenUP, and Scrum. There is creation, communication, and consumption of knowledge during (agile) software development [2]. For the success of an agile project, it is crucial that such knowledge be managed effectively. In doing so, an appropriate selection and use of certain tools and technologies can be helpful. In the past few years, there has been a proliferation of Social Web Applications, such as Wiki [3]. Indeed, a number of noteworthy uses of Wiki in software engineering have been reported [4]. However, these studies are largely independent of any software development methodology, and are centered mostly on collaboration. The primary reasons for selecting Wiki for agile software development include the following: (1) the deployment of agile methodologies, especially XP and Scrum, with teams that are increasingly geographically-dispersed, (2) the involvement in sustainable software development by organizations with basic infrastructure and modest budgets for resources, and (3) the need of inexpensive, mature, and widely-available tools for supporting iterative development, by almost anybody, at anytime, anywhere, using almost any device. The purpose of this research is to provide a framework for integrating Wiki for the purpose of facilitating the dynamics of knowledge during agile software development.

Despite of many criticisms, agile software development (Beck et al., Manifesto for Agile Software Development, http://agilemanifesto.org, [1]) philosophy has been proved to be quite successful to increase the project success rate up to a significant extent. The primary reasons behind the criticism of agile are the strong violation of the traditional disciplined software engineering theories, principles and practices. The goal of this research paper is to establish the fact that agility may also be achieved by following traditional process models especially with BRIDGE (Mandal, 2009 IEEE International Advance Computing Conference (IACC 2009) Patiala, India, [2]) process model. Hence, the aim of this paper is to integrate the agile and traditional disciplined software development process models and establish the compatibility between both the approaches. At the beginning, we have explored the objectives and principles of agile software development. Next, we briefly discussed the BRIDGE process model and further justified that--following BRIDGE process model, the philosophy of agile may also be achieved and conclude that BRIDGE model has both the capability of traditional software development process model as well as of the agile process.