Skip to content

Continuous development

Understand how small changes, testing and safe releases turn faster coding into reliable delivery. A shared foundation for engineers and their product and design partners.

Who it is for

Stream Teams

The whole Stream Team, because releasing safely is a team habit.

Duration
1 day

Inside the module

What the module covers

Faster coding helps only when changes reach customers in small, safe steps.

This module gives a Stream Team a shared picture of how a validated solution is sliced, built on a single trunk behind feature toggles, deployed automatically, and watched in production. The cohort examines its own path from commit to production and leaves knowing which blocker to remove first.

By the end, participants have practiced how to

  • Slice a validated solution into end-to-end releases with user story mapping, where the first release is the minimum that tests the key assumptions
  • Separate commodity components to buy from differentiators to build using a Wardley map
  • Explain trunk-based development with short-lived branches and feature toggles, and what it demands of tests and continuous integration
  • Write acceptance tests as a whole team before building, and describe the red, green, refactor cycle of test-driven development
  • Map their own path to production and identify the manual steps, handovers, and review queues that add lead time
  • Plan a safe release using a phased rollout behind a toggle, alert thresholds, automatic rollback, and a blameless postmortem when something fails

Module outline

How the time is spent

Each part ends with a short exercise, on your own work where you have it and on a prepared case where you do not. We adapt the examples and emphasis to the people in the room.

  1. Slice the solution

    Breaking a solution into small releases that each reach customers, so feedback arrives before the full feature is built.

    Put it into practice

    Build a user story map for one solution you are about to build and draw the first release swimlane: the smallest slice that reaches customers and tests the key assumption. Close with a blink estimate as a go or no-go on that slice.

    Topics covered

    • User story mapping: user journey, feature tasks, release swimlanes
    • First release as the minimum that tests key assumptions
    • Technical task mapping and single-day tasks
    • Wardley Mapping for build-versus-buy decisions
    • Blink Estimation as a go or no-go feasibility check

  2. Integrate continuously

    Keeping everyone on the latest code and building quality in while the code is written, including code produced with AI assistance.

    Put it into practice

    Participants trace one recent change from first commit to merge using the history someone brought, noting branch lifetime and review wait, then write two or three acceptance tests together for the first slice from session one.

    Topics covered

    • Trunk-based development compared with Git Flow and long-lived branches
    • Hardcoded feature flags, runtime feature toggles, and retiring them
    • Test-driven and acceptance test-driven development
    • Code review trade-offs: pull requests, pairing, and teaming
    • Guardrails for AI-assisted code: short rules files of current constraints

  3. Pipeline and deployment

    What an automated path to production contains and how teams deploy without downtime or a manual gate.

    Put it into practice

    Map your current path to production step by step, mark every manual step, handover, and approval, and choose the one to automate or remove first.

    Topics covered

    • Continuous integration: automated build, tests, and immediate feedback
    • Test types: unit, integration, end-to-end, and performance
    • Fitness functions as automated architecture checks in the pipeline
    • Deployment approaches: blue/green, rolling, canary, and feature toggles
    • Database changes with backward-compatible and expand-and-contract patterns

  4. Operate and recover

    Separating deployment from release and favoring fast recovery over a blocking test phase.

    Put it into practice

    For the first slice, participants write a release and recovery plan: the toggle, rollout stages, metrics to watch, alert thresholds, rollback trigger, and who owns each.

    Topics covered

    • Dark launching and testing in production behind toggles
    • Instrumentation and alert thresholds tied to service level objectives
    • Automatic rollbacks and speed of recovery
    • Blameless postmortems and root cause analysis methods
    • Four DORA metrics as a view of delivery health

Practical results

What the cohort leaves with

  • A user story map for one real solution with the first release slice agreed
  • A worked Wardley map example, with a build-versus-buy pass on your own solution as the first task of the week after
  • A map of the current path to production with the blockers ranked for removal
  • A release and recovery plan for the first slice, covering toggle, rollout stages, alert thresholds, and rollback trigger
  • Team agreements on branching, review through pairing or pull requests, and retiring feature toggles

Before the module

Bring one solution the team is about to build or has in flight, and someone who can describe the current route from commit to production: branching model, test suite, deployment steps, and monitoring. Screenshots of the pipeline and recent deployment history are enough.

The company learning plan

Where this module fits

Part of the Stream Teams courses, taken at the Equip the pilot team stage of the implementation.

See all company courses →

Stream Teams

Explore the supporting documentation