A Framework for Analyzing Structural Mechanisms Deployed to Support Traditional and Agile Methods

People rely on structures to make their worlds orderly. This chapter conceptually probes into the problem of the differences between organizational structures deployed in traditional and agile environments. The authors develop an argument that all common forms of organizational entities can be classified by involving a two-dimensional classification scheme. Specifically, they constructed a typology to examine the issues of formal vs. informal authority, and disciplinarity vs. cross-functionality in terms of their significance for traditional and agile software development workplaces. Some examples of concrete organizational forms—including traditional project team, independent test team, self-organizing agile team and developers' community of practice—are discussed. In sum, they argue that by employing this classification scheme, they can theorize the nature of the on-going structural shift observed in conjunction with deploying agile software development methods. They acknowledge that the structures have fundamentally changed, terming the move “democratization” in the software development workplace.

Building an Ambidextrous Software Security Initiative

Improving software security in software development teams is an enduring challenge for software companies. In this chapter, the authors present one strategy for addressing this pursuit of improvement. The approach is ambidextrous in the sense that it focuses on approaching software security activities both from a top-down and a bottom-up perspective, combining elements usually found separately in software security initiatives. The approach combines (1) top-down formal regulatory mechanisms deterring breaches of protocol and enacting penalties where they occur and (2) bottom-up capacity building and persuasive encouragement of adherence to guidance by professional self-determination, implementation, and improvement support (e.g., training, stimulating, interventions). The ambidextrous governance framework illustrates distinct, yet complementary, global and local roles: (1) ensuring the adoption and implementation of software security practices, (2) enabling and (3) empowering software development teams to adapt and add to overall mandates, and (4) embedding cultures of improvement.

Challenges and Trends of Agile

Rapidly increasing of requirements of business pushed researchers to define new approaches and methodologies to meet marketing needs. Agile methodology has been created and replaced the traditional-driven development methods that focus on soliciting, documenting a complete set of requirements, and take a long time comparing to market change. On the other hand, customers need to be closer to the development process and collaborate with team development. Despite agile advantages, introducing new tools, coordination, and collaboration concepts, some challenges still need to be discussed and improved. These challenges relate to achieve balanced IT service development process in the organization. As a result, new trends have been created to facilitate new changes in software development. This chapter will study agile methodologies and different challenges with suggested solutions generated from agile philosophy itself.

Disciplined Teams vs. Agile Teams

Software development has been considered a socio-technical activity over the past decades. Particularly, in the case of software engineering, the necessity to communicate effectively with stakeholders and team members has been progressively emphasized. Human resources play a critical role in the success of software projects. Many techniques, methods, tools, models, and methodologies have been proposed, applied, and improved in order to help and ease the management of the software development process. Regardless of the software development methodology adopted, delivering a quality product in a predictable, efficient, and responsive manner is the objective for every team. Disciplined and Agile teams have different characteristics, but also share common aspects when working to accomplish their goals. The main motivation of this chapter is to present the differences and similarities of both teams in the context of software development.

Adapting Agile Practices During the Evolution of a Healthcare Software Product

Agile Software Development (ASD) can be considered the mainstream development method of choice worldwide. ASD are used due to features such as easy management and embrace of changes, where change in requirements should be taken as a positive feature. However, some domain verticals, such as medical-healthcare, are classified as critical-safety system, which usually requires traditional methods. This chapter presents a practical use case describing the evolution of a software product that was conceived as a wellness software for end-users in mobile platforms to a medical-healthcare product restricted to regulatory standard recommendations. It presents the challenges and how the ASD is compatible to standards such as ISO/IEC 82304-1.

Managing Contradictory Tensions in Agile Distributed Development

Increasingly, agile approaches are being followed in a distributed setup to develop software. An agile approach is characterised by the need to regularly welcome change requests and update the software artefact accordingly whereas distributed teams prefer to work towards following a plan to fulfil project objectives defined upfront. This results in contradictory tensions when agile is practised with teams operating in a globally distributed format. This chapter focuses on exploring the central conflict and discuss approaches to manage the conflicting forces in an agile distributed development setup. Furthermore, it presents an industry case study to provide more clarity on conflict management in such settings.

AMPLA

Software architecture design, when performed in context of agile software development (ASD), sometimes referred to as “agile architecting,” promotes the emerging and incremental design of the architectural artifact in a sense of avoiding “big design upfront” (BDUF). This chapter presents the Agile Modeling Process for Logical Architectures (AMPLA) method, an approach for supporting the emergence of a candidate (logical) architecture, rather than BDUF, the architecture in an early phase. The architecture then emerges throughout agile iterations, where AMPLA plays a key contribution for providing traceability between models, from the business need to service specifications, ranging from design stages to deployment, hence covering a software development life cycle (SDLC).

Milestone-Driven Agile Execution

This chapter introduces a hybrid software development framework, called Milestone-Driven Agile Execution, in which the empirical process control and the just-in-time planning of tasks of agile development are retained but the prioritization of the backlog is done according to a macro or strategic plan that drives the execution of the project. Selecting work items from the product backlog according to a plan instead of following the immediate concerns of a product owner adds visibility, predictability, and structure to the work of the team while preserving the adaptive advantages of agile development.

A Review of the IT Service Design Process in Agile ITSM Frameworks

The current and most used IT Service Management (ITSM) frameworks (ITIL v2011, CMMI-SVC, and ISO/IEC 20000) correspond to a rigor-oriented paradigm. However, the high dynamism in business requirements for IT services has fostered the emergence of agile-assumed ITSM frameworks. In contrast with the Software Engineering field where the rigorous and agile development paradigms co-exist because both paradigms are well-known and well-accepted, in the ITSM field, agile ITSM frameworks are practically unknown. This chapter, thus, reviews the main emergent proffered agile ITSM frameworks (Lean IT, FitSM, IT4IT, and VeriSM) focusing on the IT service design process category. This process category is relevant because an IT service is designed after its business strategic authorization and the IT service design determines the future warranty and utility metrics for the IT service. The main findings suggest the need for clear and effortless agile ITSM frameworks with agile design practices to guide potential ITSM practitioners to cope with the new digital business environment.

Disciplined or Agile?

Software requirements changes become necessary due to changes in customer requirements and changes in business rules and operating environments; hence, requirements development, which includes requirements changes, is a part of a software process. Previous studies have shown that failing to manage software requirements changes well is a main contributor to project failure. Given the importance of the subject, there is a plethora of efforts in academia and industry that discuss the management of requirements change in various directions, ways, and means. This chapter provided information about the current state-of-the-art approaches (i.e., Disciplined or Agile) for RCM and the research gaps in existing work. Benefits, risks, and difficulties associated with RCM are also made available to software practitioners who will be in a position of making better decisions on activities related to RCM. Better decisions can lead to better planning, which will increase the chance of project success.