TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Even though everyone gives lip service to the idea that some approaches work better in some environments or for some domains than others, no one wants to admit that their approach wouldn't work for everything, if people would just do it "right!"
One of the lessons that I've learned over a long career in software is that a five-man project is a lot different than a 50-man project, which is a lot different from a 500-man project. If you're charged with developing a 1,000 man-year project, you ought to look at CMM. If you're involved in developing a high-risk, high-change product, you ought to look at agile development.
If you look at where CMM and agile development have their biggest following (foothold), you can pretty much tell what they are best suited for. CMM is used mainly for large, outsourced software projects, in military software, and in areas where software reliability and safety are paramount (e.g., drug systems, medical devices, nuclear devices). Agile development is used mostly for product software, especially in areas using new technologies.
Highsmith makes the point that agile development evolved to help people with what he calls "exploratory projects." Exploratory projects are those that have the following characteristics:
§ Frontier technology -- pushing the state-of-the-art
§ Mission-critical -- critical to the business' overall success
§ Time-critical -- have a required time window to become operational
§ Constantly changing -- have very volatile requirements
There is no reason that a large organization can't have more than one standard method for software development; one approach for smaller, critical, technology projects; and another for very large, non-time-critical projects. Over time, CMM and agile development will begin to cross-fertilize, but that is a long-term activity.17
Agile . since Jun 23 . Index . DOCs TOP TOC
I learned a long time ago that despite all of the publicity in the press, software wars are side issues. If you are the ones behind CMM, the real competition is not agile development, but apathy. Many, if not most, organizations are stuck at Level 1. While those involved in the 21st century software wars are at war with each other, they are ignoring the great mass of people for whom almost any software development approach would be preferable to what they have.
The CMM and agile development folks need to talk more, and they need to take each other more seriously. The CMM side needs to see agile development as a new paradigm, not just another form of hacking. Unfortunately, many of the principal developers of CMM haven't been actively involved in development for a long time. They simply don't know what is really going on or how the software development and tools have changed.
On the other hand, the agile development side needs to see CMM not just as a failed attempt to overcontrol the creative process but as a way to help organizations do a better, more predictable job on very large, outsourced projects.
At the core, CMM and agile development both want to do the same things, which is to help people do a better job. They simply come at the problem with very different cultural bias.
In the process of developing this report, I took the opportunity to read the various articles in "The Great Methodology Debate" from Cutter IT Journal. What struck me the most was that almost all of the authors in that debate misrepresented the other side. Of course, in a debate, one is expected to make the strongest case possible, but debates normally don't make good science or good technology.
It seems to me that we can either use the current software wars as an excuse to keep going in the direction we've already decided on, or we can see it as an opportunity to advance the state of the art. Our industry needs to clarify what it means and the terms it uses. In fact, we need to be taking to heart some of the ideas that business researchers like Clayton Christensen have been saying about disruptive technologies and plot a course that aims not at getting our organizations to the current best practice but to some higher level, something I've labeled "next practice."