Experimentation in organizations often starts with the marketing department hiring an agency to raise the ROI of their marketing efforts. Scaling experimentation in the whole organization leads to a larger quantity of experiments, preventing changes without testing, thus making better decisions, and reducing risk. However, we have learned that broadly scaling experimentation has negative effects on the marketing departments KPI of more revenue, which is preventing experimentation from scaling up.

The main objective of this paper is to make organizations aware of this Catch-22 when starting experimentation with the scope of raising ROI. We want to convince marketing departments, their agencies, and their vendors that if experimentation starts at marketing, then they need to create more awareness for the full power of experimentation by presenting all the results including the more common inconclusive and negative outcomes of experiments.

Our learnings suggest that this awareness must lead to budget and resources for a stand-alone experimentation Center of Excellence (CoE) outside of the marketing department, that different (not ROI focused) KPIs are needed when scaling up experimentation, and that specific organizational conditions must be met to maintain a future-proof set-up.

Ruben de Boer

Online Dialogue

Netherlands

Shirley van Haalem

Online Dialogue

Netherlands

Desiree van der Horst

Online dialogue

Netherlands

Ton Wesseling

Online Dialogue

Netherlands

no description available

David Issa Mattos

Volvo Cars

Sweden

Yuchu Liu

Volvo Cars

Sweden

no description available

Ali Shahrokni

Systemite AB

Sweden

Patrizio Pelliccione

Gran Sasso Science Institute, L'Aquila, Italy

Italy

When developers collaborate on a software project, the style of the code should be consistent across the codebase. However, as developers do not always concur on code style practices, achieving a consensus can be burdensome. Even when code style guidelines are defined for a project, developers often have difficulties adhering to them. Additionally, when working on several projects with diverse guidelines, following different styles can become a frustrating, error-prone, and time-consuming task for a developer. This work presents experiences from adopting two development workflow patterns that automatically ensure that code’s layout and formatting are consistent in a project’s repository while enabling each developer to utilize their preferences locally. From our experience, using any of these two patterns provides a successful way for collaborative software development that allows developers to relocate their time and concerns from code formatting to more valuable matters.

Tjaša Heričko

University of Maribor

Slovenia

Boštjan Šumak

University of Maribor

Slovenia

no description available

Agnė Reklaitė

Vinted

Lithuania

Jevgenij Gamper

Vinted

Lithuania