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; www.ddj.com). 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.
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.
