Release Trains
Changes wait for the next scheduled release window regardless of readiness, batching unrelated work and adding artificial delay.
11 minute read
Changes wait for the next scheduled release window regardless of readiness, batching unrelated work and adding artificial delay.
11 minute read
All stories are bundled into a single end-of-sprint release, creating two-week batch deployments wearing Agile clothing.
10 minute read
Production changes are only allowed during specific hours, creating artificial queuing and batching that increases risk per deployment.
11 minute read
Branches that live for weeks or months, turning merging into a project in itself. The longer the branch, the bigger the risk.
11 minute read
The build has been red for weeks and nobody cares. “CI” means a build server exists, not that anyone actually integrates continuously.
11 minute read
Hand-selecting specific commits for release instead of deploying trunk, indicating trunk is never trusted to be deployable.
10 minute read
Maintaining multiple release branches and manually backporting fixes creates exponential overhead as branches multiply.
11 minute read
Work is organized by technical layer (“build the API,” “update the schema”) rather than by independently deliverable behavior. Nothing ships until all the pieces are assembled.
10 minute read
Work items go from product request to developer without being broken into smaller pieces. Items are as large as the feature they describe.
5 minute read
The team has no constraint on how many items can be in progress at once. Work accumulates because there is nothing to stop starting and force finishing.
5 minute read
Features are designed and built as large monolithic units with no incremental delivery - either the whole feature ships or nothing does.
11 minute read
Arbitrary deadlines override quality, scope, and sustainability. Everything is priority one. The team cuts corners to hit dates and accumulates debt that slows future delivery.
6 minute read
There is no cadence for incremental demos. Feedback on what was built arrives months after decisions were made.
3 minute read
There is no way to deploy code without activating it for users. All deployments are full releases with no controlled rollout.
3 minute read
The board shows many items in progress but few reaching done. The team is busy but not delivering.
3 minute read
Production deployments cause anxiety because they frequently fail. The team delays deployments, which increases batch size, which increases risk.
4 minute read
The team dedicates one or more sprints after “feature complete” to stabilize code before it can be released.
4 minute read
Deploying happens monthly, quarterly, or less. Each release is a large, risky event that requires war rooms and weekend work.
4 minute read
A single repository with multiple applications and no selective build tooling. Any commit triggers a full rebuild of everything.
3 minute read
Integration is a dreaded, multi-day event. Teams delay merging because it is painful, which makes the next merge even worse.
3 minute read
Something that worked before the release is broken after it. The team spends time after every release chasing down what changed and why.
4 minute read
Developers feel unsafe committing to trunk. Feature branches persist for days or weeks before merge.
4 minute read
Pipelines take 30 minutes or more. Developers stop waiting and lose the feedback loop.
3 minute read
The test suite takes 30 minutes or more. Developers stop running it locally and push without verifying.
3 minute read
Stories regularly take more than a week from start to done. Developers go days without integrating.
3 minute read