Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Agile at 10: Evolving Again

This week marks the 10th anniversary of the signing of the Agile Manifesto at the Snowbird Retreat in Utah. During the intervening decade, agile has gone from a disjoint group of practices taken from extreme programming (XP) to a mainstream approach of software development — if not the mainstream approach. Its success was due to several factors, the most important of which was that in embracing change, agile directly addressed the principal limitation of the waterfall model. In addition, the manifesto's signatories were all established teachers and trainers and so they were accustomed to reaching large audiences to spread their message. These exponents infected their students with a kind of religious enthusiasm for some techniques — especially TDD — that became the hallmark of agility and the bane of professionals using other approaches. Little by little, however, the core practices that underlay the principles — frequent releases, significant customer involvement, early and frequent testing — became part of how most developers approach their work.

During early part of this first decade, the focus of agile was on developer practices: pair programming, TDD, frequent check-ins, and continuous integration. These practices targeted the individual programmer's role in the development process.

Then, towards the end of the decade, agile began to evolve to a more encompassing target: the process. Scrum and Kanban emerged as key practices and the qualities of lean manufacturing became the guiding values going forward. Agile now referred to team processes and the way the team interacted with the technology. The most recent step in this direction is surely the migration of continuous integration to continuous deployment, as described in Jez Humble and David Farley's masterpiece, Continuous Delivery.

This was a natural and, I dare say, necessary evolution. The early programmer-centered practices were good, but not good enough to extend the revolution. Moreover, the practices were being corrupted or insufficiently applied. For example, TDD morphed from a test-first approach to one in which code was written first and the tests written immediately after. This change reflects confusion about TDD's principal goal, which is better design, rather than greater testing.

Among other practices that were unraveling was pair programming, in which two developers work side by side on the same code. Only one has a keyboard. The idea was that two programmers working together in this way would produce more, better quality code and so the cost of two developers working as one would be offset by the results. While there appears to be benefit to pair programming, it's hard to quantify; and most sites that try it, ultimately give it up.

Process-based agile, however, looks like it's here to stay. Organizations that try scrum, stay with it. Likewise, lean project management generally results in practices that are sticky; that is, once exposed to how lean works, organizations stick with it. These new directions must be expanded, in my opinion, if agile is to break into one arena in which it has gained little traction: large projects (more than 5M LOC) with multiple large teams (more than 500 total developers). Five years from now, I suspect, we'll know whether agile has breached the last redoubt of the waterfall model successfully.

— Andrew Binstock, Dr. Dobb's Executive Editor
[email protected]

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.