Satisfaction, Practices, and Influences in Agile Software Development

Individual empowerment of agile and non-agile software developers in small teams

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?

The lack of user engagement, the absence of user feedback, incomplete and continuously changing user requirements are among the critical concerns that cause projects to fail. User-centered design (UCD) and agile software development are two iterative approaches that have been proposed to overcome such concerns. UCD is a design process focusing on user research, user interface design and usability evaluation. Introduced by software engineering practitioners, agile refers to a number of iterative and incremental software development practices that emphasize people’s needs, communication between developers and stakeholders and the ability to adapt to change. In both the agile and UCD communities, however, a full understanding of user requirements is often seen as incompatible with early and quick development iterations. We performed a literature review aiming to identify how agile teams have integrated UCD tools into their agile software development process to a better understanding of the user requirements without losing sight of the agile values and principles. UCD tools adaptations and minimal-up-front design applied in agile development are among the approaches discovered in this study. The findings could lead to a comprehensive user-centric software engineering that will overcome inherent problems faced by agile teams to understand user needs, priorities and goals.

Obstacles to decision making in Agile software development teams

Agile development practices have been widely adopted in a variety of organizations, yet only a few tools are available to help make the practical process of managing agile teams less painful and more successful. HP Agile Manager is a purpose-built SaaS-based Agile planning tool. HP Agile Manager provides a simpler, smarter way to manage collaborative development. Liran Tal provides a practical, concise approach to using Agile Manager in a variety of settings to better plan, conduct, and manage software releases within development teams. His step-by-step approach will show you how to plan your products features, streamline the agile sprint process, work with user stories, and track defects throughout the development process. Agile Manager can work for small startups, mid-sized teams, as well as scale up for bigger organizations as a cost-effective and flexible tool to apply agile techniques to improve your software development process. What youll learnHow to apply the concepts of agile management in software development teams to better execute and increase performance and delivery How a software release cycle works, how to manage sprints, set timelines, build a products backlog, and manage day to day team tasks How to leverage agile best practices to guide your team through effective release planning and team collaboration Understand and apply agile software delivery concepts such, estimating and prioritizing user stories. Streamlining sprints planning, execution, and retrospective How to setup, and use HP Agile Manager to effectively manage software lifecycle through agile methodology, and learn how to leverage Agile Manager's flexible workflow to meet your team requirements and processes Using Agile Manager's dashboards for real-time view into the current status of releases, and sprints to gain insights and pro-actively respond to changes, as well as tracking your team progress, work-load, and keeping an eye on tasks burn-down, or cumulative flow Who this book is for Developers, quality engineers, development team leaders and new managers will find this book to serve them well in learning and applying agile methodologies in their teams.

Agile development processes such as Scrum have been successfully applied in the software industry for many years. Based on experience, industrial practitioners indicate three predominant benefits of agile development processes compared to traditional software development processes. First of all, development results better fit customers’ and other stakeholders’ needs. That is because they are intensively involved in the development process by receiving, applying and assessing functional software increments in a defined cadence throughout the development process. Secondly, agile development processes better cope with unexpected changes in the development process due to the built-in process flexibility. Lastly, development speed has significantly increased in most of the agile software development projects, resulting in a shorter time-to-market. Especially in the context of radical innovations for technical systems, manufacturing companies are striving for approaches to optimize their development processes in a similar direction. Traditional plan-oriented development approaches such as VDI 2221 or Cooper’s Stage-Gate Process turn out to be insufficiently customer oriented, too inflexible and project duration is usually too long to reach an adequate time-to-market. For that reason, a large community in academia and industrial practice is developing and implementing approaches to adapt agile software development practices for the development of technical systems. However, a current study in industrial practice reveals that out of 23 objectives, that are expected when introducing agile development processes to technical systems, the three objectives mentioned above, show the largest negative deviations from expected benefit to realized benefit. Therefore, the overall goal of this research is to address these gaps by developing an explicit methodological approach for an agile development of technical systems. It turns out, that mainly the role of prototyping and the way product specifications are handled during the development process change significantly in the course of introducing agility to development of technical systems. Agile practitioners strive to not necessarily define product specifications comprehensively upfront, as it is postulated in plan-oriented development processes. In contrast, product specifications, which are of major importance to the overall development project, are specified and validated with customers and other stakeholders in early prototypes. Therefore, prototypes are realized in a defined cadence throughout the development process to gradually specify and validate the product. However, the way product specifications are prioritized and selected in the development of technical systems has to differ substantially from the general way Scrum or other existing agile development processes propose. That is because technical systems are characterized by multiple technical interrelations, resulting in informational dependencies for the development process. For that reason, a prioritization along criteria such as customer value, development effort and risk seems too narrow in the context of technical systems. In fact, the prioritization of product specifications has to consider both, the value being generated by their realization as well as the informational dependencies towards other specifications. Furthermore, when designing a prototype, time constraints need to be particularly considered due to lead times in parts delivery and prototype production. Therefore, this paper introduces a methodology to prioritize and select technical design parameters in agile development processes. The methodology can be applied in the cyclical sprint planning that aims at defining the scope of the next prototype to be developed. As outlined above, the major paradigms of value generation, informational dependencies as well as lead-time and effort are crucial when adapting agile for technical systems and are consequently implemented in the methodology. These paradigms are operationalized to explicitly address the mentioned major objectives of agile development processes, which are currently showing are large gap between expected benefit and realized benefit in industrial practice. The methodology is applied to the real development process of an RGB laser light source for digital cinema projectors, which is summarized as a case study in the paper. Insights from this application are equally discussed as the resulting next steps in further developing and aligning the methodology to the needs of industrial practice.

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.

Companies are adapting their traditional development processes, aiming for project-specific designs that are referred to as “Agile Product Development” - flexible, adaptive and accelerated processes. Implementing these principles supports developers to react to challenges such as shortened innovation cycles. For successful implementation and use of these new principles, support functions such as procurement have to be adapted to the demands of flexible, agile and accelerated processes. Complexity of tasks and impact on corporate success of procurement increased significantly in the last decades resulting in specialized stand-alone procurement departments. Being optimized for traditional development methods such as stage-gate, these departments will be challenged by agile developers demanding for highly flexible, hardly predictable procurement activities. Therefore, the authors present a scientifically derived catalog of requirements for procurement in agile product and technology development projects, e.g. shortened lead times and vague technical specification of products to be procured. Based on this catalog, options for the configuration of procurement in agile development projects, such as the organizational merging of development and procurement, are discussed. Adapting the procurement according to the requirements derived in this paper will help companies to successfully conduct procurement activities in regard to the needs of agile new product development.

Today, the most vital step is software testing, especially in product quality. Agile software development is exceedingly difficult and has contentious issues in literature and business. Since most Agile techniques place more emphasis on development than software testing activities, different people have varying opinions about how software testing fits into these methodologies. Agile places a high emphasis on frequent deliveries and tight client connections. However, software testing is complex because agile does not incorporate many destructive testing techniques typically required for a product of higher-quality. The study reveals industry-wide Agile testing procedures and the main problems that arise when Agile development is used. Additionally covered are the differences between manual and automated testing, best automation practices, and ways to lead different testing teams in an agile testing environment. This study covers every facet of the Agile software testing process. Agile development has shown that testing is not a distinct stage but rather a crucial component of software development along with the coding. The agile team employs an overall strategy to produce software products of the highest quality. As part of an agile team, testers collect customer samples of the desired behaviour and collaborate with the developer's team to help the coders translate these examples into executable specifications. Coding and testing are done iteratively and incrementally, developing every item until it is valuable enough to release in production. It addresses several testing modalities. The classification provided by its quadrants aids teams in determining and organizing the necessary tests. To increase quality assurance, this article will examine various and improved Agile Testing Processes and methodologies. Additionally, the topic of Agile development's software testing method is covered. Agile development processes can be improved and more advantageous by incorporating testing procedures.

agile information systems, flexible information systems development, distributed information systems development, global software development, software development, special issue

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.

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.

Organizations of all sorts adopt agile software development, but they rarely implement it “by the book.” Instead, agile practices evolve after initial adoption and often drift in different directions as organizations translate agile into their institutional environments. We studied the implementation of agile development in four organizations from much different institutional contexts: a startup technology company, a consulting firm, a government organization, and an industrial manufacturer. We found two core dimensions of their institutional contexts that shape agile translation: dynamism and pluralism. Dynamism refers to how fast requirements and environments change, and pluralism refers to how many diverse stakeholders are involved. These two dimensions influence the direction of agile translation. We show that agile practices evolve through a “ratcheting” process, whereby a sequence of incremental, interdependent changes gradually move teams closer to or further away from canonical agile practices. High pluralism in the institutional context, for example, tends to increase documentation, whereas low dynamism appears to slow iteration cycles. Agile software development is no longer limited to startups or software teams; it is adapted by all sorts of organizations as a way to flexibly innovate. Understanding why agile evolves differently across contexts helps managers move beyond one-size-fits-all prescriptions and set realistic expectations for agile development in their organizations.

Software quality assurance is concerned with the efficient and effective development of large, reliable, and high-quality software systems. In agile software development and maintenance, refactoring is an important phase for the continuous improvement of a software system by removing quality defects like code smells. As time is a crucial factor in agile development, not all quality defects can be removed in one refactoring phase (especially in one iteration). Documentation of quality defects that are found during automated or manual discovery activities (e.g., pair programming) is necessary to avoid wasting time by rediscovering them in later phases. Unfortunately, the documentation and handling of existing quality defects and refactoring activities is a common problem in software maintenance. To recall the rationales why changes were carried out, information has to be extracted from either proprietary documentations or software versioning systems. In this chapter, we describe a process for the recurring and sustainable discovery, handling, and treatment of quality defects in software systems. An annotation language is presented that is used to store information about quality defects found in source code and that represents the defect and treatment history of a part of a software system. The process and annotation language can not only be used to support quality defect discovery processes, but is also applicable in testing and inspection processes.

Effort estimation is an important practice in agile software development. The agile community believes that developers’ estimates get more accurate over time due to the cumulative effect of learning from short and frequent feedback. However, there is no empirical evidence of an improvement in estimation accuracy over time, nor have prior studies examined effort estimation in different development activities, which are associated with substantial costs. This study fills the knowledge gap in the field of software estimation in agile software development by investigating estimations across time and different development activities based on data collected from a large agile project. This study investigated effort estimation in various development activities, including feature development, bug fixing, and refactoring in agile software development. The results indicate that estimation of agile development does not improve over time, as claimed in the literature. Our data also indicate that no difference exists in the magnitude of estimation errors between feature tasks and bug-fixing/refactoring tasks, while bug-fixing and refactoring tasks are overestimated more frequently than feature tasks. This study also contributes to our knowledge about overestimation and underestimation patterns in agile software development.