We look at our sales data every week. We have monthly goals and we compare our monthly achievements to those goals. The difference goes straight to the bottom line (which happens to be our paychecks). In short, we run our business very iteratively because the bottom line is directly connected to our pocketbooks.

I think every business is run iteratively. Regularly keeping track of the sales, revenue, cash, and payables is a significant part of what every business must do to remain solvent. And when those numbers don't add up to the right sums, then tough management decisions have to be made. Sometimes this means cutting costs. Sometimes it means layoffs. Sometimes it means new sales incentives, or price reductions. Sometimes it means new product offerings. But one thing is certain, you cannot make those business decisions without data.

Compare that to how most software projects are run. They begin with a date. Let's not kid ourselves, all projects start with a date -- probaly before they have requirements -- probably before they have a name. An endless stream of requirements follows. A project plan is put together, and then reformed and reformed until it meets the date. Then the project is launched, and from a management point of view it goes dark.

Managers ask "How's that project going?" The answer: "Pretty good." If you want a more detailed answer it will be something like this:

• (10% in) "We're currently building data models. We're about 80% done with them.
• (20% in) "We're currently building use-case models. We're about 80% done with them.
• (40% in) "We're currently building class models. We're about 80% done with them.
• (60% in) "We're currently building sequence design models. We're about 80% done with them.
• (80% in) "We're implementing the necessary infrastructure and architecture components. Were about 80% done with that."
• (90% in) "We're starting to implement the main features. They'll be a snap because we've got all the design and architecture built. We're going to make the deadline."
• (110% in) "We're about 80% done with all the features."
• (120% in) "We're about 80% done with all the features."
• (130% in) "We're about 80% done with all the features."
• Repeat until complete or cancelled.

I realize that this sounds flippant -- and it is -- but it also strikes too close to the truth for a vast number of projects. No real data comes out of the project, and so there is no way to make any management decisions. Projects that produce no data cannot be managed. Period.

By their very nature Agile projects produce data. That's the bottom line. Never mind all the hoo-ha about new social orders and egalitarian software departments. The reality of Agile methods like Extreme Programming (Especially Extreme Programming) is that they produce periodic reliable data about the progress of the project. They don't report progress on models. They don't report progress on infrastructure. They regularly report verifiable and accurate data on implemented features. In the case of Extreme programming these reports come at least twice per month.

Imagine you are the manager of a software project. On the wall you see two bar charts. The first shows the number of feature-points completed by the team in each of the last iterations. The second shows the number of feature-points remaining in the project, again for each of the last several iterations. See graphs here. Anyone, manager or otherwise, can look at these two charts and see the status of the project. You can look at that second chart and eyeball the slope to predict the end-date. If the end-date is later than the deadline, then Mr. Manager, you've got some managing to do.

Charts like these provide the data that allows a software project to be managed like a company. The data tells us when tough decisions need to be made. Perhaps we need to renegotiate the due date, or reduce scope, or add manpower. The decision may not be easy, you may need a cast-iron stomach to make it, but without the data it can't be made.

This data is produced as a matter of course in Agile Methods like Extreme Programming. What's more, the data is accurate. No feature can be said to be complete unless it passes the acceptance tests written by the business stakeholders (usually business analysts and QA). Agile methods start out producing data like this from the very beginning of the project, and don't stop until the project is over. In an Agile project there is no Analysis phase that cannot be measured, there is no Elaboration phase that cannot be measured, there is no design phase that cannot be measured, there is no infrastructure development that cannot be measured. Analysis, design, infrastructure, architecture etc, are all done in process while producing working features and reporting real progress.