Source: InfoQ — Adopting Continuous Delivery at teamplay, Siemens Healthineers
Overview
Continuous Delivery (CD) is the practice of keeping software in a releasable state throughout its entire development lifecycle. While the idea sounds simple, achieving it requires rethinking every aspect of a traditional software development process — from requirements engineering through to deployment.
This article describes how the teamplay development organisation at Siemens Healthineers began a transformation toward Continuous Delivery. It covers the strategy and tactics used to gradually and safely change a development process operating within a regulated medical domain.
About teamplay
teamplay is a cloud-based performance management solution for medical institutions developed by Siemens Healthineers. It connects healthcare professionals, imaging devices and institutions to help radiology and cardiology departments tackle large-scale data challenges and manage increasing cost pressure.
Once a healthcare institution is connected to the teamplay network, its imaging scanners continuously send data to the cloud. Two representative applications built on the platform are:
- teamplay Usage — monitors scores and trends such as patient changeover times and the number of examinations performed across different imaging scanners.
- teamplay Dose — provides insight into radiation dose levels and highlights deviations from internal and national thresholds.
Third-party developers can also integrate with teamplay via public APIs, and the number of such integrations was growing steadily at the time of writing.
The Technology Stack
teamplay services run on Microsoft Azure. The user interface is implemented as a Single Page Application in AngularJS. Frontend integration for third-party applications is handled via iFrames, which gives external developers the freedom to use their own technology choices while still plugging into the platform.
The Problem: Improving the Development Process
At the start of the transformation, teamplay releases were shipped on a quarterly cadence. The development team identified several goals for improvement:
- Release features more frequently and respond faster to user demand.
- Reduce batch sizes to lower the risk of each change.
- Eliminate — or significantly reduce — the stabilisation phase that preceded every release.
- Improve release-date predictability by increasing quality throughout the process.
The team’s first move was to automate development deployments and add automated sanity tests that checked core application functionality immediately after each deployment. This brought a meaningful improvement in product stability, but frequent releases and a shorter stabilisation phase remained difficult to achieve.
Adopting Continuous Delivery
Continuous Delivery is far more than deployment automation and automated testing. The goal is to maintain software in a releasable state throughout its development — a requirement that spans both technical engineering and requirements engineering. To help with this transformation, the teamplay team engaged Dave Farley (co-author of the book Continuous Delivery) as an advisor and coach.
Safety was a non-negotiable constraint. teamplay software is used within healthcare and is subject to medical device regulation, making high quality and compliance essential rather than aspirational.
The fundamental objectives of the transformation were:
- Increase the quality and frequency of feedback — so that teams and individuals can see the outcomes of their decisions quickly.
- Improve collaboration — across a geographically distributed organisation, enabling decisions to be made close to the work.
- Shift toward a disciplined engineering culture — using training, coaching and hands-on pairing to embed new practices.
The approach combined formal training in CD philosophy with hands-on coaching, pairing experienced practitioners alongside teams as they learned. Technical work focused on better automated tests, more efficient deployment pipelines, story mapping for requirements, and the use of Domain Specific Languages (DSLs) to create executable specifications.
Choosing a Pipeline Strategy
A critical early decision was how to reduce feedback cycle time. At the start of the transformation, the team waited between 24 and 48 hours to learn the outcome of a test run. The target was to reduce that to approximately one hour.
Three architectural options were considered:
- Optimise the existing monolithic pipeline — scale build servers, introduce incremental compilation, and run only tests affected by a given change.
- Decompose into microservices — create a dedicated pipeline per microservice, requiring backwards-compatible contracts between services.
- A middle-ground: one pipeline per teamplay application — making each application independently releasable without requiring a full microservice decomposition.
The team chose the middle-ground option. It avoided the complexity of optimising a monolithic pipeline and deferred the engineering investment required for a full microservice architecture. The microservice approach was noted as a possible future direction.
The Continuous Delivery Model
Through workshops, coaching sessions and training courses, the team established a visual model for Continuous Delivery that maps the complete journey from idea to production deployment.
The model identifies which role is responsible for each step and which methodology — TDD, BDD, DDD, or Pair Programming — applies at each stage. Roles include Product Owner (PO), Business Analyst (BA), Designer, Architect, Developer and Operations Engineer.
The pipeline itself has four stages: Accept 1 → Accept 2 → Staging → Production.
Process Walk-Through: From Idea to Commit
1. Hypothesis
Every new feature begins with a stated hypothesis in the form:
- We believe that this <capability>
- Will result in this <outcome>
- We will know we have succeeded when we see a <measurable signal>
The hypothesis scopes the work: only as much functionality and production instrumentation as needed to test the hypothesis should be built.
2. Low-Fidelity Prototype
The Product Owner and Designer create a low-fidelity prototype — a paper sketch or quick wireframe — to communicate the idea to other roles and gather early customer feedback before significant investment is made.
3. Story Mapping
The whole team — POs, Architects, BAs, Designers and Developers — collaborates to create a User Story Map. The map represents user journeys hierarchically, including steps performed outside the product where relevant. From the story map, the team identifies a Minimal Viable Product (MVP) slice and selects a single story for refinement.
4. BDD Scenarios
Stories are refined using BDD Scenarios written in Gherkin (Given / When / Then). Each role contributes scenarios from their perspective:
- PO — functional scenarios from a user perspective.
- Architect — scenarios covering load and security concerns.
- Operations Engineers — scenarios related to monitoring and logging.
- Business Analyst — ensures all “ilities” (reliability, scalability, maintainability, etc.) are covered.
Stories should be kept small. If a story produces more than roughly six scenarios it is likely too large and should be split. Crucially, scenarios must not contain implementation details or UI references — they should read as if written for first-level customer support.
BDD, DSL and Acceptance Testing
Once BDD scenarios are agreed, the team builds a Test DSL (Domain Specific Language) to express those scenarios in an executable and reusable form. The DSL is inspired by Domain-Driven Design, ensuring that the same language is used from initial discussion through to production code.
Dave Farley’s recommended four-layer acceptance test architecture provides the structural foundation:
- Layer 1 — Test Cases: Written in the abstract DSL, capturing user intent without implementation details.
- Layer 2 — DSL Implementation: Shared domain-level concepts reusable across many test cases (e.g.
AddScannerToHospital,CalculateRadiationDoseByScan). - Layer 3 — Protocol Adapters: Translate DSL concepts into real interactions with the system under test (REST calls, UI interactions, etc.).
- Layer 4 — System Under Test.
This separation means test cases are loosely coupled to the system. When implementation details change, only the Protocol Adapters need updating — the Test Cases and DSL remain stable. Tests are also functionally isolated, enabling parallel execution and shorter feedback cycles.
For a detailed description of this approach, see: Acceptance Testing for Continuous Delivery — Dave Farley (InfoQ).
Using Executable Specifications to Guide TDD
Once an Acceptance Test is written it is expected to fail immediately — there is no product code yet. The team follows a strict Red → Green → Refactor → Commit cycle:
- Red: Write the test. It fails because the production code does not exist.
- Green: Write just enough production code to make the test pass.
- Refactor: Clean up the code while keeping the test green.
- Commit: Push the change into the pipeline.
Within that cycle, developers also apply TDD at the unit test level — writing a failing unit test first, then the production code slice that satisfies it. This means each piece of functionality is tested at two distinct levels: the acceptance test level (what the system does) and the unit test level (how individual components behave).
Pair Programming
All programming tasks — DSL writing, acceptance tests, TDD, production code, pipeline work — are performed in pairs using the Driver-Navigator model:
- Driver: Types code and focuses on syntax and constructs.
- Navigator: Guides direction at a slightly higher conceptual level.
Roles switch regularly. Pairs are typically disbanded after completing a user story, with developers joining new pairs. This promotes shared code ownership, resilience against team attrition, faster onboarding of new members and faster recovery from test failures because many people understand each area of the codebase.
Pair programming can appear costly but it consistently delivers higher quality work and is a highly effective mechanism for embedding new techniques and culture within a team.
The Build and Deployment Pipeline
Once a commit enters the pipeline it passes through five stages:
- Build Agent (~5 minutes): Runs all unit tests and static code analysis. The 5-minute target is deliberate — it is roughly the time a developer pair can take a short break without switching context. Any failure at this stage rejects the commit.
- Accept 1 (~1 hour total for Accept 1 + Accept 2): Deploys the team’s component in isolation and runs all its Acceptance Tests. Any failure rejects the change.
- Accept 2: Deploys the component alongside its dependencies from other teams and runs Contract Integration Tests against integration points. If contracts between teams become sufficiently solid, this environment may be retired in future.
- Staging (Cut): A customer acceptance environment where selected customers can use the release candidate and provide real feedback. Production-grade monitoring and alerting are applied here.
- Production: Final deployment, also monitored with production-grade alerting.
A Team Information Radiator displays commit flow and environment state at a glance. Failures appear in red and immediately prompt developer action.
Why Short Feedback Cycles Matter
The relationship between feedback speed and software quality is direct. In a CD model, any failing test means the software is not in a releasable state. Long feedback cycles — say six hours — force developers to patch environments directly rather than re-committing a fix, because a full pipeline run would not complete until the following business day. This degrades discipline and erodes quality over time.
Targeting a one-hour feedback cycle from Accept 1 and Accept 2 enables developer pairs to make multiple commits per day. If a failure occurs, there are still multiple opportunities within the same working day to fix it, re-commit and see it pass cleanly.
Beyond the immediate benefit, driving toward short feedback cycles forces systemic improvements:
- Better team structures
- Improved automation
- Greater modularity
- Better automated testing
- Elimination of manual bottlenecks
- Improved requirements processes
- Better software design
Adoption Across Teams
Different teams adopted the CD model at different rates, which was expected. Key observations from the rollout:
- User Story Mapping was adopted by nearly all teams and proved particularly useful for making release prioritisation transparent and collaborative.
- TDD and Pairing were in regular use on some teams and being applied to selected features on others.
- BDD was being applied selectively, with teams growing confidence by experimenting on individual user stories before extending the practice more broadly.
- Team Pipelines were implemented by some teams, with ongoing work to optimise feedback cycle times.
- Kanban and #NoEstimates saw the fastest organic adoption — the majority of teams switched from Scrum and sprint estimates to Kanban and #NoEstimates voluntarily within weeks of being given the choice.
A key enablement mechanism was a CD Maturity Model that allowed teams to self-assess their adoption monthly and identify incremental improvements. Automatically generated dashboards surfaced CD metrics related to deployment stability, helping to guide the transformation in concrete terms.
Some teams dedicated a day per fortnight to learning — experimenting with new methodologies at small scale (a single user story) before scaling practices across all stories once confidence was established.
Conclusions
The teamplay CD transformation was explicitly framed as a long-term, incremental process — not a big-bang change. Even at an early stage, measurable results emerged. Applying TDD and Pair Programming to a new feature in a historically bug-prone area of the codebase enabled the team to deliver that feature with no production bugs.
The broader ambition is to become an experimental organisation — one that continuously runs small business and technical experiments in production to validate assumptions, rather than executing against plans built on assumptions alone. Continuous Delivery is the foundation that makes that kind of organisation technically and culturally possible.
Original article published on InfoQ. This summary was prepared for a DevOps engineering audience.