Channels ▼


Initiating an Agile Project

Scott is the practice leader of the Agile Modeling and Agile Unified Process (AUP) methods. His latest book is Refactoring Databases: Evolutionary Database Design (Addison-Wesley, 2006). He can be contacted at

ONE OF THE MOST MISUNDERSTOOD aspects of agile software development is the first few days, or weeks if things aren't going well for you, of a new project. Little has been written about this subject, perhaps because it's a "phase" that we just get through on the way to starting the interesting development work, perhaps because it's fairly straightforward to people with agile experience, and perhaps because many traditionalists seem to struggle with the overall concept no matter how we explain it. Regardless, I'm going to do my best to overview how to successfully initiate an agile software development project.

Figure 1 depicts the lifecycle of a typical agile project (described in detail in "Where Did All the Positions Go?", DDJ, June 2006; Agilists refer to the initial iteration of a project as "Cycle 0," during which you determine whether the project is feasible, setup the technical environment, start building the team, and do sufficient modeling to support these activities. Sounds like what you do on a traditional project? Absolutely. The difference, however, is agilists achieve the same goals with a lot less effort—Cycle 0 is typically a week or two at most.

[Click image to view at full size]

Figure 1: The Agile Project Lifecycle.

Fundamentally, you need to do just barely enough to get the job done, or as the Extreme Programming (XP) aficionados say, "You need to maximize the amount of work not done." This is likely where traditionalists struggle most when it comes to agility: You don't need anywhere near the level of documentation, or detail for that matter, that you've been led to believe over the years. For example, although you'll likely be asked for an initial estimate, you don't need to spend weeks or months doing detailed requirements, analysis, and design so that you have the input into some form of complicated estimating process. A ballpark estimate will often do, and frankly it is just as accurate as anything you'd produce counting function points or following COCOMO II.

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.