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 ▼
RSS

Design

The Discipline of Agile


Scott is a DDJ Senior Contributing Editor, Practice Leader Agile Development with IBM Rational, and author of several best-selling books. He can be contacted at www.ambysoft.com/scottAmbler.html.


Lately, it has become common for traditionalists to claim that Agile software development isn't disciplined, a harsh criticism that needs to be addressed because nothing could be further from the truth. I suspect that the people who are making these claims either misunderstand Agile or they're for excuses to not adopt Agile techniques. This month, I describe the discipline required of Agile developers, share my criteria for determining whether a team is Agile, and argue that traditional development provides a false sense of discipline.

Many traditionalists mistake code-and-fix approaches for Agile approaches, and they're correct that the code-and-fix crowd isn't very disciplined. Compounding the problem is that the code-and-fixers often claim to be agile because they're not writing documentation or not doing code inspections. When traditionalists know how to distinguish Agile teams from code-and-fix teams, the criteria described in the accompanying sidebar "How to Tell the Agilists from the Code-and-Fixers" should help, they'll see that they're mistaken on Agile being undisciplined. This is important because it will enable them to consider Agile in a fair light, and more importantly it may make them start to question how disciplined traditional approaches are in practice.

The Discipline of Regular Delivery

The greatest motivator of discipline within Agile approaches is the regular delivery of working software. The shorter the iteration the greater the discipline required to make it work, and interestingly Dr. Dobb's 2007 Agile Adoption survey (www.ddj.com/architect/200001986) showed that 85 percent of Agile teams prefer iterations between one and four weeks in length. Providing concrete, measurable business value in the form of working software each iteration is incredibly tough because you actually have to do your job. Undisciplined IT professionals hide behind detailed documentation, reviews, or other questionable forms of traditional "earned value," which are little more than promises to deliver something at some point in the future.

There are several agile techniques that you can adopt to get yourself out of the undisciplined rut of traditional "earned value". First, do just a little bit of initial, high-level modeling up front to give you the information that you need for initial planning and architectural decisions (www.agilemodeling.com/essays/amdd.htm). This is often on the order of hours or days, not weeks or months, because your focus is on modeling and not on writing extensive documentation. Second, don't overbuild your software to support some mythical future requirements that may never be applicable but instead work in the priority order as defined by your stakeholders (more on this below). Third, adopt a just-in-time (JIT) approach to planning instead of the false security of a detailed, up-front planning. Mike Cohn's Planning Poker (www.planningpoker.com) is a perfect example of this because it easily enables people who are doing the work to plan it out on a JIT basis. Interestingly, the Agile Adoption survey also showed that the fourth most useful work product on agile projects is a detailed iteration plan yet the least useful was a detailed Gantt chart.


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.