TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
What changes need to be made to agile development today? Well, for one thing, more attention must be paid to some basic management issues: architecture, design, documentation, integration, and tools.
Agile development depends on breaking projects into time-boxed iterations. Application developers have to come up with methods for breaking up larger and larger projects into small agile development ones that can be somehow brought together. The only way that I know to do this is by spending some time at the beginning building a systems architecture that can then be used for planning a series of small incremental projects that can be brought back together to form a larger whole. With something as dynamic as agile development, this process can be more complicated than in a CMM environment. In Figure 3, from Highsmith's most recent book, there is an iterative agile development systems lifecycle that has a place in the adaptive cycle planning phase for this kind of systems architecture activity [3].
 Figure 3 -- The agile development systems lifecycle [3]. |
Agile development simply must produce more design artifacts. The idea that the code ought to be the only documentation you'll ever need doesn't cut it. That's a little like saying that the chip contains all of the design concepts that you'll ever need to understand, let's say, a Pentium X computer. In its rush to minimize, agile development has thrown too much out with the bath water.
Finally, agile development has to get over its aversion to relying on tools. The software business has made itself one of the key drivers in modern business by providing electronic tools. If one could bring forward the best businesses from the 1960s into the present, they simply couldn't compete. Today's business world is an electronic one that operates in real time. Software development has to keep up. No matter how good our management strategy for software development, we can't get to where we have to without better and better tools.
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