TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
If you want to do business with defense agencies and with an increasing number of large corporations, you need to show CMM certification. Some organizations use this as an opportunity to make major improvements in their software processes. Other organizations see it simply as something else they must do in order to do business with the government. The ultimate danger of CMM is that it can easily harden into mindless paperwork. In a discussion with Cutter Consortium Fellow Robert Charette, he remarked that this freezing in place was the biggest problem with large organizations using CMM.
Just like TQM, CMM must be worked on every day to be of value. New approaches need to be evaluated, and CMM must be modified to keep up with the times. CMM software development managers have to take a "sundown" approach to processes and forms. If a process doesn't make sense any more, or, if some form is out of date, it ought to modified or let go.
In addition, CMM managers have to work to maintain organizational flexibility. In particular, they need to ensure that they promote face-to-face communication whenever possible.
Finally, CMM needs to be automated. If some particular bit of information needs to be kept up to date, or some formal approval needs to be given at a certain point, then these things ought to be automated so that they are as easy to do and are integrated as possible. Of all the approaches out there, CMM must be constantly reengineered.
Because of its tendency toward rigidity and bureaucracy, CMM in the wrong hands can stifle all innovation. Pretty soon, if you're not careful, CMM becomes all the bad things that its opponents say about it.
Agile . since Jun 23 . Index . DOCs TOP TOC
Unlike CMM, agile development is a product of the 1990s, not the 1970s or the 1980s. For the most part, the people most responsible for the agile movement, with some notable exceptions, came of age at the beginning of the "object revolution" in the late 1980s and early 1990s. Cutter Consortium Senior Consultants Kent Beck and Alistair Cockburn along with Martin Fowler, chief scientist at ThoughtWorks, were involved at one time or another in teaching and promoting OO techniques.10 In its early days, the object revolution promised to sweep the planet and completely change how people did software.
Today, the object revolution has been very successful in many ways; today's most popular development languages and operating environments all have a definite OO flavor. But not everything has gone as planned. For example, components have not been as big or as easy to use as OO gurus predicted. Even more disturbing, OO projects have often been as late and over budget as non-OO projects. As a consequence, some of the most devoted OO advocates came to recognize by the mid-1990s that OO techniques alone would not revolutionize the software world; there needed to be a new way to build software.
But as those promoting OO techniques found, OO design and coding were not enough to take full advantage of the new opportunities that OO offered. To truly create new classes of software in very short periods of time, the software process itself needed to be radically overhauled. A number of different approaches of radical new OO development were experimented with, and agile development was born. Today, agile development represents the coming together of a number of the most successful approaches built around a common set of ideas.
Among the most important early themes of the agile development movement include the following:
§ Systems are best developed in short increments.
§ Users and developers must work hand in hand.
§ Each systems increment should be designed to handle the minimal requirements.
§ When changes in requirements occur, the agile development folks believe that they should be designed in rather than added on and that there should be minimal documentation beyond the code.
Most former OO programming gurus involved in the agile movement have a general dislike for paperwork, especially much of the paperwork imposed by rigorous software approaches such as CMM. In the circle of agile gurus, a strong minimalist bias exists. The software is alpha and omega, the beginning and the end; everything else is overhead. The ultimate argument goes like this: "Why worry about documentation or project management forms, etc., if all that people are really interested in is the product itself?" Then, "What if we throw a small number of really good programmers in a small room with the user and let them develop the software a little at a time. That way, you can eliminate all of the waste and miscommunication." And so was born XP, the father of agile development.
Instead of being imposed upon by some large organization like the DOD, agile development was actually a somewhat spontaneous development of a number of independent consultants who came across many of the same ideas.
One of the most influential and widely followed gurus in the agile development movement is Cutter Consortium Senior Consultant Kent Beck. Beck has written numerous books and articles on XP and has lectured around the world. After working for a number of organizations including Apple and Hewlett-Packard, it was his work on a project for Chrysler in the mid-1990s that allowed him to begin to formulate his ideas on a radical new way of developing systems.
Throughout the late 1990s and now into the 21st century, an increasing number of people became associated with XP or other fast-track methodologies. A number of books came out of this work, and more and more organizations became interested.
Unfortunately, there were many ships flying the flag of extreme, incremental development, and software developers and managers were having a tough time understanding which methodology did what. Finally, in early 2001, a group of agile gurus met in Salt Lake City, Utah, USA, to see whether they could come up with a set of common principles. Out of that meeting came the famous Agile Manifesto.