Building In Quality — Incremental Delivery, Verification, and Continuous Integration

Agile's quality toolkit is commonly grouped into four buckets: incremental development and delivery, Definition of Done, proactive quality assurance, and reactive quality assurance. This chapter covers the first bucket plus continuous integration; Definition of Done and the proactive/reactive practices follow in the next two chapters.

Incremental Development and Delivery rests on three key points: short iterations, frequent verification and validation, and continuous integration.

Short Iterations — iterative means repeated cycles; incremental means delivering in small portions. Each cycle comprises planning, developing, testing, reviewing, and deploying, and the team learns something in each iteration and implements that learning in the upcoming one. Each increment provides a usable, viable product on top of the previous increment — value accumulates rather than arriving all at once at the very end. A practical tip: defining the optimal iteration length means considering the team's velocity, the feasibility of delivering something real in that window, the need for usable increments, and the minimum viable product (MVP) the team is working toward.

Frequent Verification and Validation — early and frequent testing, both internal to the team and external with real users, with the specific aim of reducing the overall cost of quality. Frequent (internal) verification asks whether the product meets the stated requirements and specifications — "are we building it right" — and typically happens through peer review and inspection. Frequent (external) validation asks whether the product actually meets the customer's real needs — "are we building the right thing" — typically through acceptance criteria, regular feedback, requirements workshops, and backlog grooming. Many teams also run a hardening iteration — focused verification and validation just before release — as a final safety net, not a substitute for doing V&V throughout.

Agile's approach to V&V is proactive, not reactive: issues are handled before the cost of fixing them becomes too large, problems are identified daily and in every iteration, lessons from mistakes are implemented immediately rather than logged for later, and feedback is treated as integral to every form of verification and validation — not an afterthought. A long list of agile practices feed this loop: iteration and release planning, backlog grooming, pair programming and coding guidelines, code reviews and increment reviews, regular collaboration, unit/regression/exploratory/usability testing, continuous integration, TDD, ATDD, the daily standup, refactoring, Definition of Done, and acceptance criteria.

Continuous Integration (CI) — developers check code into a shared repository several times a day. Each check-in gets verified two ways: by the repository itself, which checks for incompatible changes (conflicts) in the same codebase, and by an automatic build, which tests the system's sanity and confirms the check-in hasn't broken already-working functionality. A proper CI setup needs a source-code repository with version control (e.g. a CVS-style tool), check-in/check-out facilities, automated build-compilation-verification-deployment tooling, an automated sanity and regression test suite, the ability to schedule automatic builds and tests, and a way to receive build results with special notification on failures.

CI's benefits are significant: integrations stay easy because they happen with every small change rather than in one large batch; the whole team works off the latest code; issues are detected and resolved early; the team becomes aware of a broken build immediately, with no scary pile-up of hundreds of unresolved integration conflicts; it builds a solid foundation; and it enables rapid delivery since no time is wasted on the painful, delayed integration that happens when teams merge infrequently. Its real limitations are also worth knowing: it needs a separate setup effort (often an "Iteration 0"), and real cost, time, and effort to build out the automated test suite it depends on.

Study focus: the exam often frames CI as a mindset as much as a toolset — the best CI practices listed are "work in small units, one at a time" and "integrate several times a day." A team with perfect CI tooling that still batches a week's worth of changes into one check-in hasn't actually adopted continuous integration.