Agile Delivery
Use when asked to run the delivery track of dual-track agile — building, testing, and shipping validated work via a continuous delivery pipeline — as the track that runs alongside, not after, discovery (see agile-discovery), and grounded in continuous delivery's build/test/deploy/release pipeline.
Delivery is the track in dual-track agile responsible for building, testing, and shipping the ideas Agile Discovery has already validated — running continuously alongside discovery rather than only starting once discovery is entirely finished, so validated work keeps flowing into delivery rather than arriving in one large batch.
The continuous delivery pipeline
Delivery's technical backbone is typically a continuous delivery (CD) pipeline, automating the release process end to end:
- Continuous integration — developers frequently integrate code changes into a central repository, surfacing integration issues early rather than at a big, infrequent merge.
- Build — code changes compile into a deployable artifact.
- Test — automated unit, integration, and acceptance testing (see Unit Testing, Integration Testing, Acceptance Testing) runs against the build, with results reported straight back to the team.
- Deploy — the artifact deploys automatically to a staging environment for further validation.
- Release — once validated in staging, the change releases to production, automatically and on a reliable, predictable cadence rather than as an infrequent, high-risk event.
What this requires organizationally
A high degree of automation and genuine collaboration among development, testing, and operations — relying on version control, build servers, testing frameworks, and deployment automation working together as one pipeline, not as separate handoffs between teams that each own one stage in isolation.
Why delivery runs in parallel with discovery, not after it
If delivery only starts once discovery is fully "done," the team either sits idle waiting or delivery builds unvalidated ideas under schedule pressure. Running both continuously means delivery always has a queue of validated, ready work from discovery, while discovery keeps investigating further ahead — the same parallel-track logic Agile Discovery describes from the discovery side.
Common pitfalls
- Building ahead of validated discovery — delivering polished, well-tested software for a feature nobody validated actually solves a real problem wastes the delivery pipeline's efficiency on the wrong target.
- A manual, infrequent release process — undermines continuous delivery's core value (fast, predictable, low-risk releases); if release still requires significant manual coordination, the pipeline isn't actually continuous yet.
- Weak automated test coverage feeding the pipeline — a fast delivery pipeline with thin test coverage ships defects fast rather than catching them fast; see Regression Testing and Test Driven Development for the underlying test discipline a reliable CD pipeline depends on.
- Delivery and operations as separate, uncoordinated teams — a pipeline spanning dev/test/ops needs genuine collaboration across those boundaries, not a series of handoffs each owned in isolation.
Learn more
- Agile Discovery for the parallel discovery track feeding delivery's backlog.
- Unit Testing, Integration Testing, Acceptance Testing for the test layers a CD pipeline runs.
- Regression Testing, Test Driven Development for the test discipline reliable continuous delivery depends on.