Will It Fly?
An important consideration during Cycle 0 is the economic, technical, operational, and political feasibility of the project. So we ask ourselves if the system will pay for itself; if you have the ability to build the system (or to manage the project if you're outsourcing the effort); if you can keep the system running once it's built; and whether your organization can tolerate the successful delivery of this system. Although there are detailed techniques for determining the answers to these questions (which I describe at www.ambysoft.com/essays/ projectJustification.html), the fact is that I don't remember a project where I couldn't have honestly answered those questions during the first week with very little effort at all. Luckily, open and honest communication is a hallmark of agile teams, so if you're truly agile, then you should be able to easily address these questions. The alternative, of course, is to waste money following more bureaucratic techniques.
Laying the Groundwork
You begin to build your team during Cycle 0. You don't need everybody on the first day, but you do need your key people if available. This can be a bit different from what traditionalists are used to—there is very little "ramp up time" on an agile project because we start doing the work right away. On an agile project, there aren't weeks or months of modeling, documentation, and reviews to get through. Instead, there are hours or days of it—and then you start to work on building working software.
Ideally, agile teams are typically made up of generalizing specialists who have one or more specialties (for example, they're great at both use-case modeling and Java coding), a general knowledge of the software process, and at least a general knowledge of the domain. If you don't have such people yet, don't worry—as long as you can find people who are willing to work towards becoming a generalizing specialist, you should be okay.
One or more stakeholders will be active participants on the team, and now is the time to start identifying who these people will be, negotiating their availability, and actually getting them going. You want to start building relationships with critical stakeholders, such as the people paying for the system, who might not be active participants.
You also need to setup your working environment. This includes obtaining a workspace for the team and getting them moved into it. Don't underestimate the importance of shared tools such as whiteboards on which to sketch and dedicated wall space to post important diagrams. Furthermore, it is critical to setup the technical environment, including test databases, integration machines, testing tools, development tools, and your configuration management environment.
