An Industrial Case Study on Test Cases as Requirements

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.

This paper presents a case study using Orthogonal Defect Classification (ODC) as a diagnostic tool to understand the quality and productivity issues in a Agile enterprise web development project. The project spanned a little over two years and had an effort in the range of 100,000 hours. The use of Agile was new to this engineering team. However, the senior people in the team had several years of experience with different process models. The project used a Scrum development model and ran three week Sprints. The objective of the ODC analysis was to understand the dynamics of the development as it actually occurred - as opposed to what was on paper or believed to have been implemented. We also wanted to understand the quality of the product produced, its stability and causes of customer pain. The development process had a separate Quality Assurance (QA) function, and a development led test and inspection effort. We wanted to understand their individual effectiveness, and how the structure effected production level quality. This case study was conducted by the senior engineering team along with ODC expertise from our firm. A subset of the application (around 4 major components) were chosen for this study. This allowed for an examination of component level issues, versus systemic issues across the entire application.

It has been noted that software localization does not always fit well into agile software development. This poster aims to illustrate the relationship between the two by examining how localization issues occur in agile projects. A list of common localization issues is presented and examined as to where and why they can be caused during development and if there is a connection to agile methodologies. The poster serves as an introduction to our research in this area.

Throughout the automotive industry, the direction of projects being developed using Agile methodologies is growing while the demand from the original equipment manufacturers to follow quality standards such as automotive SPICE is also growing and becoming a normal quality requirement for all the automotive suppliers to achieve. The integration of Automotive SPICE (ASPICE) into agile development projects poses unique challenges and opportunities. This paper explores these challenges, such as documentation overhead, synchronization issues, and cultural mismatches, and presents potential solutions through strategic alignment of ASPICE practices with agile frameworks. This paper also outlines strategies to align ASPICE processes with agile methodologies, aiming to enhance software quality, compliance, and team agility. Key focus areas include process tailoring, capability level alignment, and hybrid model implementations. Figures and tables illustrate key conflict areas and resolutions.

This research examines the impact of agile project management on organisations. To investigate this issue, a case study and an additional external survey were conducted. The impact has been identified according to the aggregated enterprise agility dimensions, which are interconnected. Based on the survey, it can be stated that the impact depends on the number of interfaces into the organisation and the management commitment. The impact, however, can be a double-edged sword, as when the agile mindset is fostered, conflicts can arise when people are released, after agile projects, back into the old structures of the organisation. The survey also revealed that practitioners believe that after an agile project, there is the need for an agile support team in order to avoid a break in the agile supply chain. Furthermore, agile project management impacts the HR-processes, as the competence profiles of the employees are influenced. Consequently, agile project management can be seen as the gem cell for agility in (parts of) an organisation, whether this is wanted or not, due to its influence. Depending on the amount of agile project work, the organisation has to handle the VUCA-environment accordingly, where agile project management can help to learn and transfer agility into the organisation step by step until the desired and required need. Nonetheless, change management should be applied in any cases to ensure the right outcome.

The more dynamic and unpredictable the development constraints, the more agile the development project should be to cope with and utilize inherent change. Especially in such contexts, aligning with the project's mission and vision, committing to next steps, and documenting the development path is challenging. To support the decision making process of self-organized agile development teams with an overview, a recent research paper proposes the Progress Map. The investigation at hand applies the Progress Map in semi-industrial development projects to empirically validate its applicability and performance in the form of a multi-case study. The results indicate that, given future refinements, this instrument can be valuable to plan, document, and communicate the progress of an agile development project.

Technical Debt is a term coined by Ward Cunningham to denote the amount of rework required to put a piece of software into that state which it should have had from the beginning. The term outdates the agile revolution. Technical debt can occur using any development approach, but since agile development has become wide spread the notion of “technical debt” has gained much more attention. That is because if agile development is not done properly, technical debt accrues very fast and threatens to strangle the project. In this paper the author describes how technical debt comes to being, how it can be measured and what can be done to prevent it in agile development. The emphasis of the paper is on how to prevent it. What measures are necessary in an agile development project to keep technical debt from accruing over time? The paper lists out a number of measures which can be taken – organizational, procedural and technical. Automated tools play an important role in the struggle against technical debt. Samples are given how a tool can be helpful in identifying and removing problems before they get out of hand. Also important is an external auditing agency which monitors projects in progress with the aide of automated tools. In the end a case study is presented which illustrates the monitoring of technical debt within an agile development and what counter measures are required to stop it.KeywordsTechnical debtcode qualityproduct documentationsoftware defectsrefactoringsoftware metricsagile team organizationagile testing

Agile Project Management methods have gained phenomenal success in the IT software world in managing projects of high complexity and uncertainty. However, Agile projects come with their unique set of risks. This paper seeks to explore the risks posed by human factors to complex Agile Scrum projects in large enterprises. Project Risk Management is crucial in determining the future performance of a complex project. Increasing project complexity makes it more and more difficult to anticipate potential events that could affect the project and to make effective decisions to reduce project risk exposure. This is even more true for Agile projects that promote immediate and frequent visibility of risk factors and distributed decision making in projects. A dominant reason for failure of complex Agile projects are the risks caused by human and organization factors. This paper will analyze the delivery risks posed by human factors and the traditionally hierarchical decision making in large enterprise systems.

This study aims to examine the influence of new software product efficiency and effectiveness on agile software development project success, with a particular focus on the mediating roles of market information capabilities, customer involvement, and R&D capabilities within IT companies operating in Portugal. Data were collected using purposive and convenience sampling from 418 employees across various IT SMEs in Portugal. The analysis was conducted using Partial Least Squares Structural Equation Modeling (PLS-SEM) with SmartPLS v.4 software. The study found that both software product efficiency and effectiveness significantly and positively influence agile software development project success. Furthermore, R&D capabilities and market information management capabilities (MIMC) positively mediate these relationships, whereas customer involvement (CI) has a significant but negative mediating effect. These findings are highly relevant to agile practitioners, suggesting that for agile development projects to succeed, managers should focus on assembling capable teams and fostering effective customer collaboration and interaction, while also leveraging R&D and market information strengths. This research offers a novel framework integrating technical performance metrics with organizational capabilities to explain agile project success. It provides new insights into how different mediating factors influence the relationship between product characteristics and project outcomes in agile software environments.

The fourth industrial revolution utilizes artificial intelligence by automating large quantities of numbers to increase the chances of project success. The Project Management Institute lists examples of project outcomes, including but not limited to the Pyramids of Giza, the Great Wall of China, the Panama Canal, and the placement of the International Space Station into Earth's orbit. This chapter highlights how the fourth industrial revolution (Industry 4.0) impacted the evolution of agile project management practices. It discusses how these could be applied in conjunction with traditional waterfall project management or as a standalone approach. Topics discussed include a definition and elements of project management, waterfall vs. agile project management, transitioning to agile methods, developments in agile project management, agile practices, and leading agile projects and project managers.

This book will help you get started with agile project management using Microsofts latest releases of its market-leading Team Foundation Server (TFS) 2015, and Visual Studio Team Services (VSTS). The book demonstrates agile concepts and how to implement them using TFS/VSTS. Many organizations are using agile practices today. Agility has become a key enabler for running better projects with more successful end results and high quality output. At the same time, adoption of TFS/VSTS has increased dramatically, from being just a new version control system in the very beginning to becoming the fully-featured market leader it is today. In order to benefit the most from agile practices you need an Application Lifecycle Management (ALM) toolset that supports your way of working. With TFS/VSTS, Microsoft has provided a powerful tool that is very customizable. This book shows you how you can use TFS/VSTS to implement many agile practices and how they fit into a well-thought-out ALM implementation. The book also shows how an agile product owner can work with TFS/VSTS to setup an agile project from scratch and how to continue using TFS/VSTS throughout the whole project to track progress, create and refine the backlog, and work with Kanban and Scrum Task boards. Keeping track of progress is important in any project. TFS/VSO includes many tools which will help you to track key metrics in an agile project. Many useful reports are available out of the box, and the TFS extensibility offers several ways to further customize reporting to fit your needs. What You Will Learn: Agile Concepts and Processes How TFS/VSO supports agile processes end to end How you can customize TFS/VSO to better support your processes How to set up an agile project from scratch and manage it over its lifecycle

Purpose The literature has not yet delved sufficiently deeper into the holistic relationship between organisational culture and agile project management. This paper aims to address this literature gap by delineating the specifics of why and how organisational culture affects agile project management. Design/methodology/approach This paper addresses this literature gap by conducting a systematic literature review of empirical research investigating how organisational culture affects agile project management. This paper draws on the competing values framework to explain how various dimensions of organisational culture influence the technical and social streams of agile project management. Findings The findings underscored the detrimental effects of hierarchical culture, characterised by rigid organisational structures, formal communication with management and resistance to change acceptance, on both the technical and social aspects of agile projects. In contrast, the positive impact of group culture on the social aspect was evident through employee empowerment and teamwork. Moreover, the rational culture dimension demonstrated favourable effects on both streams, emphasising market knowledge, financial development and business opportunities. Finally, the developmental culture dimension supported customer collaboration, knowledge sharing and innovation. Originality/value The focus on the “mutability” of organisational culture has led to four research propositions delineating specific ways of cultivating organisational culture to be more conducive to agile projects, marking a first in the academic literature.

Building self-organizing teams in agile projects is considered an important job for project leaders. However, the reality is that building self-organized teams lacks focus as many go back to managing tasks because it is more concrete and tangible. While there are an excessive number of studies proving that developing self-organized teams has a positive contribution to project success, there is a lack of knowledge about the consequences of not doing it. This study, therefore, explores the impact inadequate self-organizing teams has on agile project success. Results have identified five failure areas in a self-organizing team that have a negative impact on three success factors in agile projects. Due to a weak direct link between success factors and success criteria, conclusions are limited to a universally applicable impact on success factors. Further research is recommended to generate a universal checklist for success criteria in agile projects that can have a direct link to the identified success factors.

© 27th European Conference on Information Systems - Information Systems for a Sharing Society, ECIS 2019. All rights reserved. The importance of information security in software development projects is long recognised, with many comprehensive standards and procedures in use to provide assurance of information security. The agile development paradigm conflicts with traditional security assurance by emphasising the delivery of functional requirements and a reduction in structured and linear development styles. Through a series of thirteen qualitative interviews, this study identifies practices that address this problem which have been successfully adopted by agile practitioners. The findings present four categories of practices - organisational, team, project, and technical - and twelve critical success factors that should be explicitly considered by practitioners to assure agile security. The critical success factors provide a foundation for practitioners to strategically identify and develop best practices to embed information security in agile development projects. The identified categories also highlight the importance of agile security practices centring around individuals and culture and contributes to the literature by providing a representation of agile security practices that encompasses a broad range of focal areas.

Agile project management (APM) is supposed to facilitate the response to rapid changes in complex and dynamic environments by applying an iterative planning approach, close customer involvement, and self-organizing teams. The literature has often considered the choice between APM and traditional project management (TPM) as binary and equated the use of APM methods with the desired outcome, i.e. project agility. In this paper, we challenge the assumption of binarity of APM and TPM and focus on project agility as an outcome. We argue that project agility is a matter of degree and is influenced by internal and external determinants. Building on Qumer and Henderson-Sellers’ (2008) four-dimensional analysis tool (4-DAT) framework, we develop a set of hypotheses of the determinants of project agility that are tested empirically using a cross-industry sample of project managers in Nordic countries. In line with the existing literature, we find customer involvement, organizational culture, and less upfront project planning to be positively related to the degree of agility in projects. However, we do not find significant effects of team size and complexity of the environment.