{"id":5003198,"date":"2015-12-16T22:29:46","date_gmt":"2015-12-17T06:29:46","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003198"},"modified":"2023-03-12T12:41:02","modified_gmt":"2023-03-12T19:41:02","slug":"incremental-development","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/incremental-development\/","title":{"rendered":"Incremental Development"},"content":{"rendered":"<p>Nearly all Agile teams favor an incremental development strategy; in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality. These are called \u201cvertical\u201d increments (that is, the difference between successive product versions), as opposed to the opposite strategy which successively delivers complete technical components: for instance, creating a database schema, then building business rules on top of that, and only then implementing a UI. (<a href=\"http:\/\/agilefromthegroundup.blogspot.com\/2009\/12\/agile-software-construction-is-like.html\">This article<\/a>\u00a0offers a typical illustration of the distinction. It echoes the \u201clayered cake\u201d metaphor of software architecture: one can either cut along the horizontal layers, or vertically across them.) It is difficult to imagine an incremental approach in the Agile sense which is not also\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/iterative-development\/\">iterative<\/a>, at least to some extent, but the two concepts are not identical. (They also prove surprisingly difficult to pin down, and are often the subject of heated semantic debates.)<\/p>\n<h2>Origins<\/h2>\n<ul>\n<li>1980: substantial discussion of incremental development in IBM\u2019s Federal Systems Division can be found in a volume edited by Harlan Mills, \u201c<a href=\"http:\/\/trace.tennessee.edu\/cgi\/viewcontent.cgi?article=1004&amp;context=utk_harlan\">Principles of software engineering<\/a>\u201c, specifically an article by Dyer, which recommends organizing \u201ceach increment to maximize the separation of its function(s) from function(s) in other increments\u201d; however, the idea is still very much that of a scheduled, phased approach rather than one responsive to change<\/li>\n<li>1984: while criticisms of the \u201cwaterfall\u201d sequential approach have started much earlier, formulations of alternative incremental approaches are becoming more pointed; a good example is an early paper on \u201c<a href=\"http:\/\/dl.acm.org\/citation.cfm?id=801993\">Knowledge-based communication processes in software engineering<\/a>\u201d advocating incremental development for the specific reason that \u201ccomplete and stable specifications are not available\u201d.<\/li>\n<li>1985: perhaps the first explicitly named, incremental alternative to the \u201cwaterfall\u201d approach is Tom Gilb\u2019s\u00a0<a href=\"http:\/\/dl.acm.org\/citation.cfm?id=1012490\">Evolutionary Delivery Model<\/a>, nicknamed \u201cEvo\u201d<\/li>\n<li>1999: in an\u00a0<a href=\"http:\/\/www.objectmentor.com\/resources\/articles\/IIDII.pdf\">article<\/a>\u00a0for the C++ Report, Robert C. Martin gives what is perhaps the earliest description of the Agile sense of the terms \u201citerative\u201d and \u201cincremental\u201d<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>In an Agile context, Incremental Development is when each successive version of a product is usable, and each builds upon the previous version by adding user-visible functionality. <\/p>\n","protected":false},"author":6000331,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[908],"tags":[],"class_list":["post-5003198","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-process"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003198","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/6000331"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003198"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003198\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003198"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003198"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003198"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}