Autonomous agile teams: Challenges and future directions for research

According to the principles articulated in the agile manifesto, motivated and empowered software developers relying on technical excellence and simple designs, create business value by delivering working software to users at regular short intervals. These principles have spawned many practices. At the core of these practices is the idea of autonomous, self-managing, or self-organizing teams whose members work at a pace that sustains their creativity and productivity. This article summarizes the main challenges faced when implementing autonomous teams and the topics and research questions that future research should address

Everyone’s Going to be an Architect: Design Principles for Architectural Thinking in Agile Organizations

Organizational agility is a prominent aim for companies to thrive in today’s volatile business environments. One common building block of agility are (semi-) autonomous teams for continuously fulfilling and surpassing customers’ needs. However, these teams still need to see the enterprise’s ‘big picture’ of strategic objectives, business processes, and IT landscape to prevent organizational inertia or technical debt. This requires architectural thinking to inform these ‘non’-architects’ decision-making. To aid companies towards achieving sustainable agility, we propose six design principles as underlying logic on how to realize architectural thinking in agile organizations. The results are based on insights from interviews with sixteen employees and consultants with expertise on architecture management and organizational agility across several industries. Our work closes a gap in the agility literature, which so far mainly focused on non-generalizable blueprints for agile setups without showing their underlying logics, or approaches and role set-ups for enterprise-level architecture management

A Lean Enterprise Architecture Approach as an Enabler for Organizational Agility : Case: Metso Outotec

In the era where delivery speed is perceived more important than IT landscape integration, consistency and long-term planning, different architectural approaches have become important considerations of information systems management. Moreover, recent studies have shown that the need for a holistic EA is often overlooked, when organizations try to apply agile development models, which may lead to several problems, such as technical debt, redundant rework, inconsistent communication, decentralized and siloed architecture design, unsustainable architecture, and inconsistence in coding style. Hence, with the growing deployment of scaling agile methods there is a need for purpose-fit approaches to integrate EA frameworks to enable organization agility while maintaining long-term vision. This study aims to explore how EA activities are put into practices in a company deploying large-scale agile development methods – namely EA deliverables, EA benefits, EA concerns and EA enablers. In total, 13 semi-structured interviews were conducted from a case company, and an analysis was done using the Gioia method. As a result, EA deliverables (business objective deliverables, intentional architecture deliverables, and emergent design deliverables), EA benefits (organizational agility and organizational robustness), EA concerns (immaturity, disengagement, urgency, and resistance and anti-patterns), and EA enablers (communication and collaboration, Lean EA, and EA culture) were identified. The enterprise architecture practices used by the case company were in line with the guidelines and best practices recommended by the literature and industry experts. Moreover, a literature review provided some theoretical constructs and suggestions, namely the Lean EA development (LEAD) method and the design principles of architectural thinking for supporting organizational agility, which can be recommended to be applied by the case company or any other organization scaling agile

AGILE PORTFOLIO MANAGEMENT: DESIGN GOALS AND PRINCIPLES

Digital transformation and the resulting volatile and unpredictable business environments challenge traditional enterprises to continuously fulfill and surpass customers’ expectations. They need to become agile in its organization by proactively sensing the unpredictable change and responding accordingly with speed and dexterity. While many organizations are quite advanced in realizing adaptivity at the operational level, strategic agility in general and in portfolio management in particular as linking op-erations and strategy for satisfying the customer needs is in its nascence. To identify the baseline for portfolio management for achieving agility, we derive four design goals for an effective agile portfolio management system, six design principles on how to achieve these goals and show an exemplary setup with design features. Our results are based on a research study with empirical insights from six com-panies and theoretical input from thirteen existing case studies and eight frameworks for scaling agility to the portfolio level. By deriving design principles for an agile portfolio management system, our work closes a gap in existing research, which focuses on principles for adaptive IT portfolio management processes instead of proactive enterprise systems, insights on individual portfolio practices or non-generalizable blueprints for an agile organizational setup without showing alternative approaches

Human factors in developing automated vehicles: A requirements engineering perspective

Automated Vehicle (AV) technology has evolved significantly both in complexity and impact and is expected to ultimately change urban transportation. Due to this evolution, the development of AVs challenges the current state of automotive engineering practice, as automotive companies increasingly include agile ways of working in their plan-driven systems engineering—or even transition completely to scaled-agile approaches. However, it is unclear how knowledge about human factors (HF) and technological knowledge related to the development of AVs can be brought together in a way that effectively supports today\u27s rapid release cycles and agile development approaches. Based on semi-structured interviews with ten experts from industry and two experts from academia, this qualitative, exploratory case study investigates the relationship between HF and AV development. The study reveals relevant properties of agile system development and HF, as well as the implications of these properties for integrating agile work, HF, and requirements engineering. According to the findings, which were evaluated in a workshop with experts from academia and industry, a culture that values HF knowledge in engineering is key. These results promise to improve the integration of HF knowledge into agile development as well as to facilitate HF research impact and time to market

System Capability Feedback-Cycles in Automotive Software Development

Context: The automotive industry is currently going through rapid change, driven by new technology; for example, electrification, autonomous driving, and connected cars. This new technology is largely based on electronics and software, and vehicles are increasingly becoming software-intensive systems. This affects how vehicles are developed, as automotive companies seek to adopt processes used in development of software-only systems, to gain the benefits of development speed and quick learning cycles possible in software development. Where sequential processes were previously the norm, automotive companies now aim to use agile methods at company-scale. Given the safety-critical nature of vehicles, and the mix software, hardware, and mechanical parts, this is challenging.Objective: This thesis explores how system-level feedback capabilities can be achieved in development of automotive systems.Method: To investigate a real-world setting, empirical methods are a natural choice. As an overarching research strategy, field studies are conducted at automotive companies. Over four studies, qualitative data is collected through semi-structured and structured interviews, focus groups, and workshops. The data is analyzed using adaptable methods, such as thematic coding. These qualitative approaches allow for open-ended questions, which are suitable for exploratory research.Findings: Transitioning towards agility changes the role of architecture, requirements, and in general of system-level artifacts previously finalized during early development phases. Nevertheless, what is covered by architecture and requirements still needs to be handled. They contain accumulated expertise, and fundamental concerns, such as safety, remain. However, automotive companies need to handle an increased importance of software for new feature development. Continuing business-as-usual is not an option.Conclusion: To achieve feedback capabilities on the system-level, there is a need for tools and methods allowing artifacts on higher levels of abstraction, for example architecture descriptions and requirements, to be modified and evolve over the entire course of development

Microservice Transition and its Granularity Problem: A Systematic Mapping Study

Microservices have gained wide recognition and acceptance in software industries as an emerging architectural style for autonomic, scalable, and more reliable computing. The transition to microservices has been highly motivated by the need for better alignment of technical design decisions with improving value potentials of architectures. Despite microservices' popularity, research still lacks disciplined understanding of transition and consensus on the principles and activities underlying "micro-ing" architectures. In this paper, we report on a systematic mapping study that consolidates various views, approaches and activities that commonly assist in the transition to microservices. The study aims to provide a better understanding of the transition; it also contributes a working definition of the transition and technical activities underlying it. We term the transition and technical activities leading to microservice architectures as microservitization. We then shed light on a fundamental problem of microservitization: microservice granularity and reasoning about its adaptation as first-class entities. This study reviews state-of-the-art and -practice related to reasoning about microservice granularity; it reviews modelling approaches, aspects considered, guidelines and processes used to reason about microservice granularity. This study identifies opportunities for future research and development related to reasoning about microservice granularity.Comment: 36 pages including references, 6 figures, and 3 table

Living Boundary Objects to Support Agile Inter-Team Coordination at Scale

Context: In the last decades, large-scale agile development has received increasing attention, as also organizations with many stakeholders and large systems aim for higher development speed and focus on customer value. A recognized research challenge in large-scale agile development relates to inter-team coordination. To coordinate effectively, organizations need to identify what knowledge is required across team borders and how it can be managed over time. Knowledge is potentially manifested in boundary objects – artifacts that create a shared understanding between teams (e.g., requirements or architecture descriptions). Traceability between artifacts is a key necessity to manage change in agile contexts. Moreover, agile practitioners aim to reduce the documentation effort to absolutely crucial artifacts and trace links.Objective: This thesis aims to improve how practitioners can manage knowledge for inter-team coordination in large-scale agile development. We focus especially on how knowledge can be made explicit in artifacts and trace links that are evolved over time. Method: We empirically investigated problems and developed solutions using a research approach that was inspired by design science. Case studies, an in-depth design science study, a mixed methods study, and surveys were performed. Using this mix of research methods, we leveraged both qualitative and quantitative data. Results: We coined the concept of living boundary objects to manage knowledge for inter-team coordination. Living boundary objects are boundary objects that are traced to other artifacts, kept up to date, and serve for inter-team coordination. They should be established early in the lifecycle to create a common understanding of the product to be developed. We scrutinized architecture descriptions, interfaces, and requirements and traceability information models as examples of concrete boundary objects. We recommend establishing alignment using a common high-level structure, but also supporting diverse knowledge management practices to fulfill the individual needs of agile teams. Conclusions: Our contributions help to establish knowledge management practices that are considered beneficial by practitioners and focus on the crucial aspects to align agile teams on. We suggest concepts and requirements for knowledge management tools that take the distinct role of living boundary objects into consideration and can be adjusted as organizations\u27 needs evolve

Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry