|tangible working results in the shortest time-span|
|Minimal Meaningful Models||Models are made as simple as possible to minimize intermediate artifacts while conveying the essential system metaphors, domain abstractions, and their important relationships.|
|Minimal Marketable Features ||Features are decomposed into the smallest marketable units of useful deliverable business value, in order to fit within short iterations and ensure critical functionality is implemented first.|
|Minimal Malleable Designs||Code is structured and refactored to be as simple as possible to minimize over-engineering, redundancy, and dependencies, while maximizing clarity, modularity, and encapsulation.|
|Minimal Mergeable Change-Tasks||Changes are checked-in and committed to the codeline as task-level transactions representing the smallest-feasible unit of working/tested functionality that won’t break the build.|
|Minimal Testable Modifications||Classes/modules and their methods/functions are developed in the smallest feasible increments of testable functionality, and then tested prior to coding the next increment.|
|Minimal Perpetual Peer-Review||Work is reviewed in very-small increments as soon as feasible after it is written (possibly even as it is being written) to minimize error detection and rework, and enforce coding standards.|
The following Saturn-like diagram depicts the various levels of feedback-loops in effect for the above:
The Agile Lifecycle, Feature Inventory and Set-Based Development
Equating partially developed/tested features with inventory (as Poppendieck does is a new way of thinking to many. If all untested code, and unimplemented designs, and partially elaborated use-cases are inventory, then they are depreciable assets whose value decreases over time the longer it takes them to reach the shelf. Hence, software development should ideally proceed in a depth-first-delivery fashion, small feature-set by small feature-set (rather than breadth-first-delivery like the canonical waterfall model).
Features may require paring-down so they may be completed within the time-frame for the iteration. As a result, large features get broken down into smaller ones, with the most critical functionality developed in earlier iterations and non-critical or non-essential features deferred to later iterations. Each "feature" in an iteration’s feature-set would correspond to the smallest-possible marketable unit of deliverable business value (a minimal marketable feature ).
In Nonaka and Takeuchi’s The Knowledge-Creating Company (the book that inspired the agile method known as "Scrum"):
- The breadth-first-delivery waterfall somewhat resembles a relay race where each phase-specific role passes the baton (in the form of intermediate artifacts) to the next role in the assembly-lane (right after clearing the end-of-phase review "hurdle").
- The depth-first-delivery iterations more closely resembles a rugby match where all roles collaborate closely throughout the event, and must dynamically adjust and regroup after each short-term win (or loss).
- They then propose that it is possible to combine the best-of-both approaches, and liken the result to "American football".
In the agile methodology "space", the methods of Feature-Driven-Development (FDD) and Dynamic Systems Development Method (DSDM) contain visible remnants of more traditional methods and could perhaps correspond to the "American football" approach to agile-development.
Hyper-Frequent Iterations and Special Relativity
So if in-progress software features are inventory that increase engineering lead-time for our time-to-market, then it naturally makes sense to employ evolutionary delivery with short iterations that realize discrete, tangible working subsets of the most highly-valued, yet independently useful and usable functionality.
Of course, iterative development is not new, and pre-dates agile methods by at least a decade. If we look at previously existing data and trends regarding traditional waterfall-based and iterative development, most projects still employ either the waterfall or "V" model as their predominant development lifecycle model, despite the increasing popularity of iterative/incremental, and spiral development models during the "hey day" of object-oriented programming and design in the late 1980s and early 1990s.
For those who were doing iterative development, many had their