The Agile Difference for SCM

iterations last at least as long as what had previously been their waterfall-based development phases. A typical iteration was several months or several weeks long, and the basic waterfall or "V" model still applied to the phases within an iteration.

In agile development however, iterations are typically much shorter, usually between 1-4 weeks in length. When iterations last several days or a few weeks, the experience is drastically different from iterations that last several weeks or months. The time-box compression is 4X-5X shorter (e.g. from one month down to one week, or from 3-4 months down to 3-4 weeks). Phases that were previously at least a few weeks or a month are now only a few days or at most one week.

At this short time-span, the boundaries between phases become increasingly blurred as greater cross-phase collaboration is emphasized. It becomes less statistically significant to look at the individual phases within an iteration than it does to look at the iteration itself as a whole. Such phase compression and collaboration "dilation" is reminiscent of the time-dilation effect of special relativity in the sense that:

• The phase-based frame of reference for the waterfall view "breaks down" in the collaborative set-based frame of reference for the highly iterative view. Each perceives the passing of time (and cost-of-change due to rework) very differently from one another. Trying to compare them side-by-side is like trying to compare "apples and oranges."
• This "changes the rules" for how to compute/measure and communicate/report our results (be they the rules of "Newtonian mechanics" for summing velocities, or the rules of "Phase-containment" and the cost-of-change curve for calculating rework costs).

Microscopic Incrementalism: Continuous Integration, TDD, TBD and TLC

The timebox-compression and collaboration-dilation effects of agile development don’t stop at iteration boundaries. The relative size and duration of development features and tasks becomes smaller as well. Particularly in an environment where Continuous Integration is practiced, the granule of change for a Task-Level Commit  may shrink from being weeks or days to instead being days or hours (or even shorter). This is the effect of test-driven development or TDD, upon task-based development.

• The test for a piece of code is written before the code itself is written.

• Developers write only "just enough" code to pass the next test, and then rebuild and retest their code before trying to make any further changes.
• To avoid becoming out-of-sync with the current configuration of the codeline, developers try to integrate their changes with the codeline as soon as each change is coded, correct, and consistent (using Workspace Update and/or Task-Level Commit ).

Coding is Designing (not Construction)

Another important way in which Agile methods differ from traditional waterfall-based methods is in how they regard the activity of writing source code using a programming language:

• Agile methods view programming source code as a design activity: it requires creativity and innovation, and is collaborative and unpredictable in scope/schedule.
• Waterfall-based methods view programming source code as a construction activity: it requires translation and elaboration of detailed designs, and should be straightforward and predictable in scope/schedule if the designs are specified in enough detail.

In most agile methods, the "construction" portion of the development cycle really begins with the build, where compilers and linkers and code-generators literally "construct" the executable. Programming languages have evolved enough in the past 2-3 decades that modern programming languages like C++, Java, C#, Ada, and even many popular scripting languages (to say nothing of their available libraries and frameworks) are a quantum leap more expressive than the likes of machine-language, assembler, FORTRAN, and C.

Even the pseudo-code that was considered the detailed design