Phase 3: Optimize on MinimumCD Practice Guide

Small Batches

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Team

Batch size is the single biggest lever for improving delivery performance. This page covers what batch size means at every level - deploy frequency, commit size, and story size - and provides concrete techniques for reducing it.

Why Batch Size Matters

Large batches create large risks. When you deploy 50 changes at once, any failure could be caused by any of those 50 changes. When you deploy 1 change, the cause of any failure is obvious.

Feature Flags

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Team

Feature flags are the mechanism that makes trunk-based development and small batches safe. They let you deploy code to production without exposing it to users, enabling dark launches, gradual rollouts, and instant rollback of features without redeploying.

Feature flags are one technique among several for integrating incomplete work safely, and the most expensive one to maintain. Before reaching for a flag, work through the evolutionary coding techniques hierarchy: dark code, branch by abstraction, parallel run, and expand and contract each solve part of what a flag solves, without the lifecycle overhead. This page assumes you’ve already ruled those out.

Limiting Work in Progress

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Team

Work in progress (WIP) is inventory. Like physical inventory, it loses value the longer it sits unfinished. Limiting WIP is the most counterintuitive and most impactful practice in this entire migration: doing less work at once makes you deliver more.

Why Limiting WIP Matters

Every item of work in progress has a cost:

Context switching: Moving between tasks destroys focus. Research consistently shows that switching between two tasks reduces productive time by 20-40%.
Delayed feedback: Work that is started but not finished cannot be validated by users. The longer it sits, the more assumptions go untested.
Hidden dependencies: The more items in progress simultaneously, the more likely they are to conflict, block each other, or require coordination.
Longer cycle time: Little’s Law states that cycle time = WIP / throughput. If throughput is constant, the only way to reduce cycle time is to reduce WIP.

“Stop starting, start finishing.”

Metrics-Driven Improvement

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Team | Original content combining DORA recommendations and improvement kata

Improvement without measurement is guesswork. This page covers two types of metrics, how they relate, and how to use them together in a systematic improvement cycle.

Two Types of Metrics

Not all delivery metrics are equally useful for driving improvement. Understanding the difference prevents a common trap: tracking the wrong metrics and wondering why nothing changes.

Retrospectives

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Team

A retrospective is the team’s primary mechanism for turning observations into improvements. Without effective retrospectives, WIP limits expose problems that nobody addresses, metrics trend in the wrong direction with no response, and the CD migration stalls.

Why Retrospectives Matter for CD Migration

Every practice in this guide - trunk-based development, small batches, WIP limits, metrics-driven improvement - generates signals about what is working and what is not. Retrospectives are where the team processes those signals and decides what to change.

Architecture Decoupling

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Team + Org | Original content based on Dojo Consortium delivery journey patterns

You cannot deploy independently if your architecture requires coordinated releases. This page describes the three architecture states teams encounter on the journey to continuous deployment and provides practical strategies for moving from entangled to loosely coupled.

Why Architecture Matters for CD

Every practice in this guide - small batches, feature flags, WIP limits - assumes that your team can deploy its changes independently. But if your application is a monolith where changing one module requires retesting everything, or a set of microservices with tightly coupled APIs, independent deployment is impossible regardless of how good your practices are.

Team Alignment to Code

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Org | Teams that own a domain end-to-end can deploy independently. Teams organized around technical layers cannot.

How Team Structure Shapes Code

The way an organization communicates produces the architecture it builds. When communication flows between layers - frontend team talks to backend team, backend team talks to database team - the software reflects those communication lines. Requests for the UI layer go to one team. Requests for the API layer go to another. The result is software that is horizontally layered in the same pattern as the organization.

Hypothesis-Driven Development

Mon, 01 Jan 0001 00:00:00 +0000

Phase 3 - Optimize | Scope: Team

Hypothesis-driven development treats every change as an experiment. Instead of building features because someone asked for them and hoping they help, teams state a predicted outcome before writing code, measure the result after deployment, and use the evidence to decide what to do next. Combined with feature flags, small batches, and metrics-driven improvement, this practice closes the loop between shipping and learning.

Why Hypothesis-Driven Development

Most teams ship features without stating what outcome they expect. A product manager requests a feature, developers build it, and everyone moves on to the next item. Weeks later, nobody checks whether the feature actually helped.