Product-Focused Software Process Improvement

Product owners in the Scrum framework – respectively the on-site customer when applying eXtreme Programming – have an important role in the development process. They are responsible for the requirements and backlog deciding about the next steps within the development process. However, many companies face the difficulty of defining the tasks and the responsibilities of a product owner on their way towards an agile work environment.While literature addresses the tailoring of the product owner’s role in general, research does not particularly consider the specifics of this role in the context of a systems development as we find for example in the oil and gas industry. Consequently, the question arises whether there are any differences between these two areas. In order to answer this question, we investigated on the current state of characteristics and tasks of product owners at Baker Hughes, a GE company (BHGE).In this position paper, we present initial results based on an online survey with answers of ten active product owners within the technical software department of BHGE. The results indicate that current product owners at BHGE primarily act as a nexus between all ends. While technical tasks are performed scarcely, communication skills seem even more important for product owners in a system development organization. However, to obtain more reliable results additional research in this area is required.

Agile methods have been largely used for many years to provide developers with a flexible software development process leading to software quality improvement. To get the best results and eliminate unnecessary efforts, the development team should select the most appropriate methods and techniques. The fundamental core of an agile method has to be well-understood before deciding which parts of the method need to be adopted. We believe that the quickest way to do so is to understand the prescripts of the Agile Manifesto. Many researches have proposed different tailoring approaches based on the relation and straight-forward interpretation between each agile practice and agile values or principles. We however have observed that agile practitioners do not dedicate the necessary attention to the Agile Manifesto before adopting agile methods or practices and directly use them. It is because the importance of Agile Manifesto in tailoring context is not obvious enough to the community. This study aims at doing a systematic literature review on the existing case studies, to verify the relation between the Agile Manifesto and agile practice selection.

Smaller software companies, such as start-ups do not often follow an explicit process, but rather develop in a more or less unstructured way. Especially when they grow or customer involvement increases. This development without any structured process results in problems. Thus, our objective was the improvement of the current development process of one software start-up by introducing appropriate agile practices and eliciting their effects. For this reason, we performed a pre and post process assessment using interviews. Based on the initial assessment, agile practices were selected and implemented. Finally, the post assessment and additional code metrics served as controlling mechanism to check whether weak points are addressed. The comparison of the two assessments showed that 13 ISO 29110 base practices have been improved by the introduced eight agile practices. Thus, even more aspects have casually been improved than initially planned. Finally, the additional retrospective with company employees showed how the introduced agile practices positively influenced their work.

Context: The term “serverless” defines applications that use elements of Function as a Service or Backend as a Service cloud models in their architectures. Serverless promises infrastructure and operations cost reduction, faster software development, and automatic application scalability. Although many practitioners agree that Serverless simplifies operations part of DevOps, it still requires a new approach to automation practices because of the differences in its design and development workflow. Goal: The goal of this paper is to explore how Serverless affects DevOps practices and demonstrate a DevOps pipeline implementation for a Serverless case project. Method: As the method, we use the design science research, where the resulting artefact is a release and monitoring pipeline designed and implemented according to the requirements of the case organization. Results: The result of the study is an automated DevOps pipeline with an implementation of Continuous Integration, Continuous Delivery and Monitoring practices as required by the Serverless approach of the case project. Conclusions: The outcome shows how strongly the Serverless approach affects some automation practices such as test execution, deployment and monitoring of the application. In total, 18 out of 27 implemented practices were influenced by the Serverless-specific features of the project.

In recent years, the use of complex embedded systems in critical domains has become increasingly widespread, driven by the emergence of Industry 4.0, Smart Grid or Smart Health Care paradigms. These latest trends require the development of smart, innovative and dependable complex systems, that combine multiple engineering disciplines, to achieve their challenging goals. In order to assist developers, researchers and designers in this development process, this paper presents a iterative prototyping methodology focused on facing challenges derived from: (i) uncertainties and risks entailed while generating new products based on novel technologies, (ii) unforeseeable interactions intrinsic to system complexity and heterogeneity (e.g.: software, hardware, chemistry, photonics, mechanics, etc.), (iii) operation dependability and regulatory requirements, and (iv) increasing importance of reducing time to market and project cost. The proposed methodology provides a complete solution based on New Product Development processes, dependability and safety standards, and Statistical Process Control (SPC) and Key Performance Indicator (KPI) techniques. Special attention is paid to the adaptation and integration of SPC and KPI techniques in the development process, as a mechanism to improve the system’s functionality and dependability. Finally, the development of an innovative real-time photonic sensor for analysing lubricant quality in industrial critical applications is presented as a case study.

Security has been recognized as a leading barrier for IoT adoption. The growing number of connected devices and reported software vulnerabilities increases the importance firmware updates. Maturity models for software security do include parts of this, but are lacking in several aspects. This paper presents and evaluates a maturity model (HAVOSS) for handling vulnerabilities in third party OSS and COTS components. The maturity model was designed by first reviewing industry interviews, current best practice guidelines and other maturity models. After that, the practices were refined through industry interviews, resulting in six capability areas covering in total 21 practices. These were then evaluated based on their importance according to industry experts. It is shown that the practices are seen as highly important, indicating that the model can be seen as a valuable tool when assessing strengths and weaknesses in an organization’s ability to handle firmware updates.

Software and software systems are increasingly connected today, and the trend is continuing. The development of such systems requires competencies that go beyond classic software engineering. Key challenges are cross-domain work, increasing complexity with shorter time to market, shared responsibility and control across multiple companies, as well as the ever-increasing demands regarding security, user experience, and other qualities. In this publication, we share our software development experiences from the Digital Villages project. The major goal in this project is to support rural areas with digital services running on a platform. While typical software engineering activities such as design, implementation, or testing are, of course, necessary further on, evaluation and incorporating feedback from users play a far more important role when going towards digital ecosystems. Our results are based on a current project runtime of three years, and might provide background for others who want to shift towards developing such systems.

Companies have been increasing the amount of data that they collect from their systems and processes, considering the decrease in the cost of memory and storage technologies in recent years. The emergence of technologies such as Big Data, Cloud Computing, E-Science, and the growing complexity of information systems made evident that traceability and provenance are promising approaches. Provenance has been successfully used in complex domains, like health sciences, chemical industries, and scientific computing, considering that these areas require a comprehensive semantic traceability mechanism. Based on these, we investigate the use of provenance in the context of Software Process (SP) and introduce a novel approach based on provenance concepts to model and represent SP data. It addresses SP provenance data capturing, storing, new information inferencing and visualization. The main contribution of our approach is PROV-SwProcess, a provenance model to deal with the specificities of SP and its ability in supporting process managers to deal with vast amounts of execution data during the process analysis and data-driven decision-making. A set of analysis possibilities were derived from this model, using SP goals and questions. A case study was conducted in collaboration with a software development company to instantiate the PROV-SwProcess model (using the proposed approach) with real-word process data. This study showed that 87.5% of the analysis possibilities using real data was correct and can assist in decision-making, while 62.5% of them are not possible to be performed by the process manager using his currently dashboard or process management tool.

Software Engineering as an industry is highly diverse in terms of development methods and practices. Practitioners employ a myriad of methods and tend to further tailor them by e.g. omitting some practices or rules. This diversity in development methods poses a challenge for software engineering education, creating a gap between education and industry. General theories such as the Essence Theory of Software Engineering can help bridge this gap by presenting software engineering students with higher-level frameworks upon which to build an understanding of software engineering methods and practical project work. In this paper, we study Essence in an educational setting to evaluate its usefulness for software engineering students while also investigating barriers to its adoption in this context. To this end, we observe 102 student teams utilize Essence in practical software engineering projects during a semester long, project-based course.

The types and characteristics of software products as well as the characteristics of development organizations that build those products contribute to the context in which software development professionals operate. To better understand this context in the software development sector, we explored the context of software development professionals in New Zealand, an example of a small but growing and vibrant software industry. In this paper, we present preliminary findings of a questionnaire-based survey with professionals. In contrast to other studies on software development in industry (which tend to focus on processes and practices), we explore non-technical product-related and organizational characteristics. We found that software development professionals in New Zealand mostly work on long-living (but frequently released) products for specific customers (rather than products developed for a broader market). Also, software development professionals mostly work in organizations that have existed for quite a while and that aim at a global customer base. Very small and very large organizations are uncommon. Based on these characteristics, we can compare different software industries. Also, this concrete characterization of context allows researchers and practitioners implement more focused process improvement initiatives.

In requirements engineering (RE), knowledge is mainly communicated via written specifications. This practice is cumbersome due to its low communication richness and effectiveness. In contrast, videos can transfer knowledge more richly and effectively. However, video is still a neglected medium in RE. We investigate if software professionals perceive video as a medium that can contribute to RE. We focus on their attitudes towards video as a medium in RE including its strengths, weaknesses, opportunities, and threats. We conducted a survey to explore these attitudes with a questionnaire. 64 out of 106 software professionals completed the survey. The respondents’ overall attitude towards video is positive. 59 of them stated that video has the potential to improve RE. However, 34 respondents also mentioned threats of videos for RE. We identified the strengths, weaknesses, opportunities, and threats of videos for RE from the point of view of software professionals. Video is a medium with a neglected potential. Software professionals do not fundamentally reject videos in RE. Despite the strengths and opportunities of video, the stated weaknesses and threats impede its application. Based on our findings, we conclude that software professionals need guidance on how to produce and use videos for visual communication to take full advantage of the currently neglected potential.

In this paper, we explore the extent to which a set of over 12000 refactorings fell into one of four re-test categories defined by van Deursen and Moonen; the ‘least disruptive’ of the four categories contains refactorings requiring only minimal re-test. The ‘most disruptive’ category of refactorings on the other hand requires significant re-test effort. We used multiple versions of three open-source systems to answer one research question: Do developers prefer to undertake refactorings in the least disruptive categories or in the most disruptive? The simple answer is that they prefer to do both. We provide insights into these refactoring patterns across the systems and highlight a fundamental weakness with software metrics trying to capture the refactoring process.

Software Engineering (SE) experiments are traditionally analyzed with statistical tests (e.g., t-tests, ANOVAs, etc.) that assume equally spread data across groups (i.e., the homogeneity of variances assumption). Differences across groups’ variances in SE are not seen as an opportunity to gain insights on technology performance, but instead, as a hindrance to analyze the data. We have studied the role of variance in mature experimental disciplines such as medicine. We illustrate the extent to which variance may inform on technology performance by means of simulation. We analyze a real-life industrial experiment on Test-Driven Development (TDD) where variance may impact technology desirability. Evaluating the performance of technologies just based on means—as traditionally done in SE—may be misleading. Technologies that make developers obtain similar performance (i.e., technologies with smaller variances) may be more suitable if the aim is minimizing the risk of adopting them in real practice.

Accurate prioritization of efforts in product and services development is critical to the success of every company. Online controlled experiments, also known as A/B tests, enable software companies to establish causal relationships between changes in their systems and the movements in the metrics. By experimenting, product development can be directed towards identifying and delivering value. Previous research stresses the need for data-driven development and experimentation. However, the level of granularity in which existing models explain the experimentation process is neither sufficient, in terms of details, nor scalable, in terms of how to increase number and run different types of experiments, in an online setting. Based on a case study of multiple products running online controlled experiments at Microsoft, we provide an experimentation framework composed of two detailed experimentation models focused on two main aspects; the experimentation activities and the experimentation metrics. This work intends to provide guidelines to companies and practitioners on how to set and organize experimentation activities for running trustworthy online controlled experiments.

Changing the development process of an organization is one of the toughest and riskiest decisions. This is particularly true if the known experiences and practices of the new considered ways of working are relative and subject to contextual assumptions. Spotify engineering culture is deemed as a new agile software development method which increasingly attracts large-scale organizations. The method relies on several small cross-functional self-organized teams (i.e., a squads). The squad autonomy is a key driver in Spotify method, where a squad decides what to do and how to do it. To enable effective squad autonomy, each squad shall be aligned with a mission, strategy, short-term goals and other squads. Since a little known about Spotify method, there is a need to answer the question of: How can organizations work out and maintain the alignment to enable loosely coupled and tightly aligned squads?In this paper, we identify factors to support the alignment that are actually performed in practice but have never been discussed before in terms of Spotify method. We also present Spotify Tailoring by highlighting the modified and newly introduced processes to the method. Our work is based on a longitudinal embedded case study which was conducted in a real-world large-scale offshore software intensive organization that maintains mission-critical systems. According to the confidentiality agreement by the organization in question, we are not allowed to reveal detailed description of the features of the explored project.

In this paper, we present experiences from eight years of developing a financial transaction engine, using what can be described as an integration-test-centric software development process. We discuss the product and the relation between three different categories of its software and how the relative weight of these artifacts has varied over the years. In addition to the presentation, some challenges and future research directions are discussed.

Test-Driven Development (TDD) has been claimed to increase external software quality. However, the extent to which TDD increases external quality has been seldom studied in industrial experiments. We conduct four industrial experiments in two different companies to evaluate the performance of TDD on external quality. We study whether the performance of TDD holds across the premises of the same company and across companies. We identify participant-level characteristics impacting results. Iterative-Test Last (ITL), the reverse approach of TDD, outperforms TDD in three out of four premises. ITL outperforms TDD in both companies. The larger the experience with unit testing and testing tools, the larger the difference in performance between ITL and TDD (in favour of ITL). Technological environment (i.e., programming language and testing tool) seems not to impact results. Evaluating participant-level characteristics impacting results in industrial experiments may ease the understanding of TDD’s performance in realistic settings.

A classical heuristic in software testing is to reward diversity, which implies that a higher priority must be assigned to test cases that differ the most from those already prioritized. This approach is commonly known as similarity-based test prioritization (SBTP) and can be realized using a variety of techniques. The objective of our study is to investigate whether SBTP is more effective at finding defects than random permutation, as well as determine which SBTP implementations lead to better results. To achieve our objective, we implemented five different techniques from the literature and conducted an experiment using the defects4j dataset, which contains 395 real faults from six real-world open-source Java programs. Findings indicate that running the most dissimilar test cases early in the process is largely more effective than random permutation (Vargha–Delaney A [VDA]: 0.76–0.99 observed using normalized compression distance). No technique was found to be superior with respect to the effectiveness. Locality-sensitive hashing was, to a small extent, less effective than other SBTP techniques (VDA: 0.38 observed in comparison to normalized compression distance), but its speed largely outperformed the other techniques (i.e., it was approximately 5–111 times faster). Our results bring to mind the well-known adage, “don’t put all your eggs in one basket”. To effectively consume a limited testing budget, one should spread it evenly across different parts of the system by running the most dissimilar test cases early in the testing process.

Continuous software engineering relies on explicit user feedback for the development and improvement of features. The frequent release of feature increments fosters the application of usage monitoring, which promises a broad range of insights. However, it remains a challenge to relate monitored usage data to changes that were introduced by an increment and thereby to a particular specific of a feature.We introduce Feature Crumbs, a lightweight, code-based concept to specify a feature’s run-time characteristics. This enables monitored usage data to be allocated to a feature increment. In addition, we analyze the implications for the overall development process. We outline the reference implementation of a platform for collecting, managing, and assessing feature crumbs. We report an evaluation of both the feature crumb concept and the reference implementation in a university capstone course.Feature crumbs and their changes to the development process contribute to the product quality; they enable feature increment assessment in combination with additional knowledge sources, such as decision knowledge.

Existing scientific literature highlights the importance of metrics in Agile Software Development (ASD). Still, empirical investigation into metrics in ASD is scarce, particularly in identifying the rationale and the operational challenges associated with metrics. Under the Q-Rapids project (Horizon 2020), we conducted a multiple case study at four Agile companies, using the Goal Question Metric (GQM) approach, to investigate the rationale explaining the choice of process metrics in ASD, and challenges faced in operationalizing them. Results reflect that companies are interested in assessing process aspects like velocity, testing performance, and estimation accuracy, and they prefer custom metrics for these assessments. Companies use metrics as a means to access and even capitalize on the data, erstwhile inaccessible due to technical or process constraints. However, development context of a company can hinder metrics operationalization, manifesting primarily as unavailability of the data required to measure metrics. The other challenge is the uncertain potential of metrics to help derive actionable inputs to facilitate decision-making. Essentially, development context has a strong influence over a company’s choice of process metrics, rationale, and challenges to operationalize these metrics.

Space projects, and development of software embedded in these systems, are complex, sometimes costing hundreds of millions of Euros and involving several tiers of suppliers. An important means of improving mutual understanding is to increase transparency of the development status between customers and suppliers. We raise the problem of transparency in complex projects to the reader’s attention, and, relying on results of a small survey of practitioners, propose to use ECSS software metrics/KPIs as a mitigation. We present our metrication infrastructure, and describe issues to be considered when implementing an early metrication programme in a real-world, industry space project.

Drivers for globalization are significant where today’s organizations look for cheaper and faster ways to develop software as well as ways to satisfy quality and investment requirements imposed by customers, shareholders, and governments. Given these needs, Global Software Development (GSD) has become a “normal” way of doing business. Working in GSD often require teams of different cultures to work together. A poor understanding of cultural differences can create barriers to trust or missed opportunities. The literature on culture in GSD is either outdated or disparate, requiring practitioners to read many papers to get an overview of how to manage multi-cultural teams. In this study, we aim to highlight how to increase cultural awareness within teams, avoid potential conflict and harness differences for improved team spirit. To answer our research question, “How should cultural differences be managed, identified and communicated to a GSD team?”, we conducted a systematic literature review of the GSD literature. A synthesis of solutions found in nineteen studies provided 12 distinct practices that organizations can implement, to include, “provide a cultural knowledge base”, “understand and make team members aware of cultural differences” and “plan responses to mitigate occurrences of cultural misunderstandings”. These implementable cultural practices go some way to providing solutions to managing multi-cultural development teams, and thus to support one of the problem dimensions in GSD and embrace cultural differences.

Context: Networking in a distributed large-scale project is complex because of many reasons: time zone problems can make it challenging to reach remote contacts, teams rarely meet face-to-face which means that remote project members are often unfamiliar with each other, and applying activities for growing the network across sites is also challenging. At the same time, networking is one of the primary ways to share and receive knowledge and information important for developing software tasks and coordinating project activities.Objective: The purpose of this paper is to explore the actual networks of teams working in large-scale distributed software development projects and project characteristics that might impact their need for networking.Method: We conducted a multi-case study with three project cases in two companies, with software development teams as embedded units of analysis. We organized 20 individual interviews to characterize the development projects and surveyed 96 members from the total of 14 teams to draw the actual teams networks.Results: Our results show that teams in large-scale projects network in order to acquire knowledge from experts, and to coordinate tasks with other teams. We also learned that regardless of project characteristics, networking between sites in distributed projects is relatively low.Conclusions: Our study emphasizes the importance of networking. Therefore, we suggest that similar companies should pay extra attention for cultivating a networking culture in the large to strengthen their cross-site communication.

Over the past few years, the Scaled Agile Framework (SAFe) has been adopted by a large number of organizations to scale agile to large enterprises. At the moment, SAFe seems to be the most predominant agile scaling framework. Despite the current popularity of SAFe in the software intensive industry, there exists surprisingly little scientific research on the benefits and challenges of SAFe adoption. To collect the existing knowledge on this topic, we conducted a multivocal literature review, which includes both peer-reviewed and non-peer reviewed case studies and experience reports on organizations that have adopted SAFe. We identified 52 unique organisations adopting SAFe, five from the scientific literature and 47 from the grey literature.The most salient benefit categories were: transparency, alignment, productivity, predictability and time to market. The most frequently mentioned challenge categories were: change resistance, challenges with the first program increment planning and moving away from agile.

With the growing number of incidents, the topic security gains more and more attention across all domains. Organizations realize their lack of state-of-the-art security practices, however, they struggle to improve their software lifecycle in terms of security. In this talk, we introduce the concept of security by design that implements security practices within the whole software lifecycle. Based on our practical experience from industry projects in the regulated industrial automation and unregulated classical IT domain, we explain how to perform a threat analysis and how to integrate it into the software lifecycle.

Processes cannot just be judged as “good” or“efficient”—they must be appropriate for the type of project. As the type of a project changes over time, the processes must adjust in order to stay efficient and appropriate. We accompanied the transformation of a large and fast-growing project, using agile development methods and cloud-native technologies, from the very first steps of a prototype to the development of a customer-ready product. This experience report shows patterns we found on the way. It argues that systematic process evolution can be done without documentation overhead or relying on questionable process KPIs. We only used information which is available anyway; this includes our archive of sprint retro boards which allows to create a clear picture of the project’s evolution, regarding both the process and the product quality.

The 19th International Conference on Product-Focused Software Process Improvement (PROFES 2018) hosted two workshops and three tutorials. The workshops and tutorials complemented and enhanced the main conference program, offering a wider knowledge perspective around the conference topics. The topics of the two workshops were Hybrid Development Approaches in Software Systems Development (HELENA) and Managing Quality in Agile & Rapid Software Development Processes (QUaSD). The topics of the tutorials were The human factor in agile transitions – Using the personas concept in agile coaching, Process Management 4.0 – Best Practices, and Domain-specific languages for specification, development, and testing of autonomous systems.The workshop organizers would like to thank all persons that organized the workshop or contributed to the workshops as well as the presenters of the tutorials. The workshops and tutorials provided interesting forums for discussing ideas, presenting novel work, learning and networking. In the following the workshop and tutorials are summarized based on the content of the respective workshop and tutorial web descriptions.

The QuASD workshop aims at investigating product and process quality in the context of agile and rapid software development. The objective of the workshop is to exchange challenges, experiences, and solutions among researchers and practitioners to bring agile and rapid software development processes a step further to seamless integrating quality management activities into their practices. In this second edition of the workshop we expect to foster the exchange of ideas between researchers and industry and consolidate a research agenda and collaborations.

Mobile apps have penetrated the market and are used everywhere. The success of apps also depends on user feedback as this enables users to influence other potential customers and provides new opportunities for identifying features. An efficient development process including quality assurance is obligatory for app-developing companies. However, developers also face challenges, such as short time to market, many release cycles, or low budgets for quality assurance. Therefore, we present a lightweight approach that considers textual feedback from users and a corresponding tool chain. With this, quality can be monitored and development and quality assurance decisions for upcoming sprints can be made fast and easily. Furthermore, examples of such textual analyses show how the approach can provide information to improve apps.

Agile methodologies gave teams more autonomy regarding planning tasks and executing them. As a result, coordination gets more flexible, but much relevant knowledge remains undocumented and inside teams’ borders, due to informal communication and reduced development documentation. Since knowledge plays an essential role in software development, it is important to have effective knowledge management (KM) practices that contribute to a better knowledge resource allocation. Several KM practices have been reported in empirical studies in Agile Software Development (ASD). However, these practices are not evaluated regarding its effectiveness or how do they affect product quality. Besides, the studies do not demonstrate connections between the KM practices in the project level and the strategic level. The lack of connection between these levels can result in deviations from the company’s corporate strategy, wasted resources and irrelevant knowledge acquisition. This paper discusses how the strategic management can contribute to an integrated approach to KM in ASD; considering the organizational structure and the corporate strategy. Based on this discussion, we propose research areas that may help with planning KM strategies that can have their effectiveness measured and contribute to product quality.

[Context and motivation] There are a plethora of agile practices that relate to management (e.g., Sprints, Scrum ceremonies), development (e.g., pair programming, TDD, BDD, DevOps) or strategy (e.g., Lean Startup), [Question/problem] but lack a comprehensive description on how its adoption influences requirements modeling and “You Aren’t Gonna Need It” (YAGNI) features. [Principal ideas/results] This paper presents Agile Modeling Process for Logical Architectures (AMPLA), an Agile Modeling (AM) oriented process composed by UML diagrams (namely, Sequence, Use Cases and Component). [Contributions] AMPLA uses agile practices in order to deliver small increments (of a requirements package) and to promote continuous customer feedback. The proposed AM process also includes a candidate architecture and further requirements refinement in parallel with a software increment delivery.

Context: Software product lines are widely used in automotive embedded software development. This software paradigm improves the quality of software variants by reuse. The combination of agile software development practices with software product lines promises a faster delivery of high quality software. However, the set up of an agile software product line is still challenging, especially in the automotive domain. Goal: This publication aims to evaluate to what extend agility fits to automotive product line engineering. Method: Based on previous work and two workshops, agility is mapped to software product line concerns. Results: This publication presents important principles of software product lines, and examines how agile approaches fit to those principles. Additionally, the principles are related to one of the four major concerns of software product line engineering: Business, Architecture, Process, and Organization. Conclusion: Agile software product line engineering is promising and can add value to existing development approaches. The identified commonalities and hindering factors need to be considered when defining a combined agile product line engineering approach.

Important and critical aspects of technical debt often surface at runtime only and are difficult to measure statically. This is a particular challenge for cloud applications because of their highly distributed nature. Fortunately, mature frameworks for collecting runtime data exist but need to be integrated.In this paper, we report an experience from a project that implements a cloud application within Kubernetes on Azure. To analyze the runtime data of this software system, we instrumented our services with Zipkin for distributed tracing; with Prometheus and Grafana for analyzing metrics; and with fluentd, Elasticsearch and Kibana for collecting, storing and exploring log files. However, project team members did not utilize these runtime data until we created a unified and simple access using a chat bot.We argue that even though your project collects runtime data, this is not sufficient to guarantee its usage: In order to be useful, a simple, unified access to different data sources is required that should be integrated into tools that are commonly used by team members.

Evidence shows that software development methods, frameworks, and even practices are seldom applied in companies by following the book. Combinations of different methodologies into home-grown processes are being constantly uncovered. Nonetheless, an academic understanding and investigation of this phenomenon is very limited. In 2016, the HELENA initiative was launched to research hybrid development approaches in software system development. This paper introduces the 3rd HELENA workshop and provides a detailed description of the instrument used and the available data sets.

Nowadays, hybrid software development approaches represent an important trend. By creatively combining various software development methods and techniques, companies seek to benefit from an increased flexibility in their software-intensive domains. This conceptual paper has two goals. First, it attempts to extend the concept of hybridity beyond the visible aspects of software development. Second, it introduces the concept of “institutional logic” as a cornerstone adopted from institutional theory. I propose to use this theory as a lens to improve our understanding of the waterfall/agile type of hybridity, i.e. when the logic of Traditional Software Engineering and the logic of Agile Software Development are concurrently adopted in an organization. Also, a relation between institutional logics and organizational cultures is proposed. The seeds of theory presented in this paper lead to a further theory building effort that will hopefully result in a better characterization of adoption motives and strategies related to hybrid software development.

The motivation to apply and to integrate agile methods into established development processes can be seen all over the world. However, the motivation for applying agile methods is not well understood as different objectives are possible: some organizations address the constantly changing market and customer demands, others are doing “agile” as the presumed best practice. This publication aims towards a better understanding of the motivation to apply the chosen development methods in Germany. We present preliminary results based on the data collection of the “Hybrid dEveLopmENt Approaches in software systems development” (HELENA) study. Further, we exemplary look at the role of criticality for choosing agile or traditional development methods. The results indicate that the six development methods applied most in Germany are Scrum, Kanban, DevOps, Waterfall, V-Model, and Iterative Development. However, a particular method is not necessarily chosen due to a specific goal. This indicates that as future work other influencing factors, e.g., the criticality of the final product, need to be identified and taken into account for analysis.