Full-Lifecycle Delivery

Definition

Mainstream agile methods (Scrum, XP) focus almost exclusively on construction—the iterative building of working software. DAD extends the agile lifecycle to encompass three phases: Inception (project initiation and vision-setting), Construction (iterative development), and Transition (deployment into production). Each phase has distinct goals, activities, and exit criteria. Inception is not waterfall requirements gathering; it is goal-driven envisioning. Transition is not handoff-to-operations; it is collaborative deployment. Together, they complete the end-to-end value delivery journey from idea to delighted stakeholder.

In the Book

Chapter 1 introduces the three-phase lifecycle; Chapters 6–12 detail Inception (identifying vision, initial scope, technical strategy, release plan, team formation), Chapters 13–17 detail Construction (iterative sprints, daily standups, demos, retrospectives), and Chapters 18–19 detail Transition (production readiness testing, deployment, stakeholder training, go-live support).

Inception (Chapters 6–7): Teams collaboratively establish the project's vision, not by writing a spec in isolation but through conversation with stakeholders, domain experts, and architects. Initial scope and technical strategy are envisioned at appropriate levels of detail—heavy enough to reduce major unknowns, light enough not to over-commit. Initial release planning estimates cost, schedule, and risks. The phase ends with stakeholder consensus: do we actually agree on what we're building?

Construction (Chapters 13–17): Teams follow the familiar agile sprint rhythm—planning, daily standups, pair programming and code review, test-driven development, continuous integration, demos, retrospectives. What differs from core Scrum is the explicit architecture-proving activities, the inclusion of initial requirements envisioning and modeling, and the attention to producing solutions (not just software)—documentation, operational readiness, training materials, data migration scripts.

Transition (Chapters 18–19): Not a ceremonial handoff but an active collaboration. Activities include end-of-lifecycle testing (final regression suite run, production integration testing), pilot or beta testing with real users, data migration or cutover planning, stakeholder training, operations environment hardening, and support procedures. The phase lengths vary wildly—a web application might transition in one week; a regulated healthcare system might take months. The book estimates an average transition of 4.6 weeks across surveyed organizations.

The book explicitly discusses the common pattern of doing transition work during construction iterations (testing, documentation, training) to shorten the Transition phase. However, reality often requires a final Transition period: many organizations insist on end-of-lifecycle testing even if iterative testing has been solid, there are last-minute fixes and tweaks, and there are regulatory or operational sign-offs that cannot happen until the final build is candidate for production.

Why It Matters

Full-lifecycle delivery closes the gap between agile's construction excellence and the organizational realities of projects. A team cannot be truly agile if inception is waterfall (six months of planning with no input from developers) or transition is chaos (developers throw code over the wall, operations spends months getting it into production, and users train on the original spec, not what was actually built). By making Inception agile (collaborative, lightweight, goal-driven) and Transition agile (team-inclusive, iterative, stakeholder-focused), DAD ensures that the entire delivery journey can be adaptive and responsive. This is especially critical in enterprises where governance, architectural coherence, and operational readiness are not optional, but addressing them with agile practices avoids the cost and risk of the waterfall-scrum-fall pattern common in large organizations.