| 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 [19] | 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
About the author
Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.
About the author
Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.
About the author
Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.
