Summary
What are Agile Methods really all about? Is it some new humanistic view of software development? Is it a social revolution? Or is it just plain good business? This blog makes the case for the latter.

How do you run a business? I'm a CEO of a small consulting company so I have some small knowledge about what it takes to run a business. Aside from a cast-iron stomach, and the will to make tough decisions, it takes something else. It takes data.

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.

The bottom line for agile methods is that they provide the data that makes managing software projects possible. They allow a software project to be managed like a business.

Talk Back!

Have an opinion? Readers have already posted 17 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Robert C. Martin adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Robert C. Martin (Uncle Bob) has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming. In 1995 Robert authored the best-selling book: Designing Object Oriented C++ Applications using the Booch Method, published by Prentice Hall. From 1996 to 1999 he was the editor-in-chief of the C++ Report. In 1997 he was chief editor of the book: Pattern Languages of Program Design 3, published by Addison Wesley. In 1999 he was the editor of "More C++ Gems" published by Cambridge Press. He is co-author, with James Newkirk, of "XP in Practice", Addision Wesley, 2001. In 2002 he wrote the long awaited "Agile Software Development: Principles, Patterns, and Practices", Prentice Hall, 2002. He has published many dozens of articles in various trade journals, and is a regular speaker at international conferences and trade shows.