Continuous Integration? I Don't Think That Word Means What You Think It Means

Continuous Integration has become synonymous with CI-Servers and the concept of CI/CD-Pipelines. Unfortunately, you can have continuous delivery without continuous integration. Just as you can check in directly to 'production' without having trunk-based development. (And shouldn't trunk-based development should be called master based development nowadays?).
This session aims to debunk several misconceptions about good engineering practices and proposes some ways to get from cargo-cult agile (aka in-name-only-agile) to tangible results today.

Target Audience: Developers, Manager, Scrum Masters, Process Coaches, Team Leads
Prerequisites: None
Level: Introductory

Extended Abstract
The origin of continuous integration seems to be tightly coupled to the olden days of eXtreme Programming (XP), and looking up the original documentation from that time it becomes evident that it is not so much about building the system, but making sure that the work is both technologically as well as logically integrated. An automated set of tools that drives all the steps from marking something as complete as a developer until all necessary artifacts are created and delivered to the production environment (sometimes called a CI/CD-Pipeline) can be very helpful. But it can also have the opposite effect and detach engineers from the result of their work and lead to a fragmented pseudo-integration.
This session shows the pitfalls of automated CI/CD-approaches as well as some actionable ways around them.