TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Even the most casual reader will note the kinds of differences between CMM strategy and that of agile development. CMM is an organizational religion. It is intended to define relationships between large organizations, not unlike the medieval church. Agile development, on the other hand, if not a personal religion, is surely the religion of a small group (the team). Where CMM defines large external measures of obedience, agile development focuses on individual/small group responsibilities.
Where CMM is often referred to as a heavy or rigorous method, it is clear that individual contributions in an agile development "church" are much more closely scrutinized by the fellow members of the local church. Similar to many of the early Protestant sects, agile development insists on very proscribed behavior, which, in turn, assumes a high skill level among the team members.
A second factor that one observes when looking at agile development is how closely a series of psychological group dynamics, beliefs, and research are woven into the approach. People work better in groups, so we program in teams; code review is good, so we always have pair programming; output-oriented design is good, so we incorporate test-first development; people work better with enough rest, so we institute the 40-hour work rule.
In a typical CMM environment, organizations can organize any way they want or use any method they want, as long as they commit to doing the same things the same ways, measure what they do, and try to improve it. Agile development is a much more tightly integrated package. You can't decide to implement items 1, 4, 6, and 9 (out of the 12 ideas Beck proposes) and leave out the rest. Indeed, if you listen to many of the agile development gurus, you need to commit to the entire program if you're going to be truly successful -- each of the 12 items above is there for a reason, and taking any one item out can jeopardize the entire program.
It's interesting to note here the similarity between Beck's 12 practices and Deming's 14 points of management. Like Beck, Deming stresses that you need to do all 14 if you are going to be successful in instituting a successful quality program. Organizations almost always pick and choose which ones to include in their specific program. For example, organizations routinely ignore a number of Deming's rules, especially the ones about no slogans, driving out fear, and breaking down barriers between departments.
Agile development aims at forever changing the way people develop software. In my mind, it is a much more rigorous management approach than CMM. Agile development, like Deming's quality, requires a much stronger commitment up and down the line. Moreover, agile development, like Deming's practice, requires a commitment to a very different style of management. In CMM, we see most of the responsibilities being placed upon the systems and project managers. In agile development, most of the responsibilities are placed upon the team. Teams are responsible for setting priorities and schedules, designing, testing, and delivering. The product rolls out in small increments, but in an almost Japanese fashion, where individuals are not accountable except as part of a team.14
Agile . since Jun 23 . Index . DOCs TOP TOC
Deliver quickly. Change quickly. Change often. These three driving forces compel us to rethink traditional software engineering practices.
-- Jim Highsmith
One of the more controversial concepts underlying all of agile development is the idea that the product (prototype) should be developed by taking into account only those things the user currently wants and are specified for the current release. This is a controversial idea because it seems to many experienced managers and developers as simply an extreme form of hacking. Rather than see this as an essential ingredient within an overall project philosophy, many managers see this as simply a way to avoid real, long-term requirements and design consideration.
The defense that the application developers give for working only on the things that they know right now is that if one begins to consider future (unknown) requirements rather than current (known) requirements, there is no easy place to stop. When you're thinking about all the different ways this product may be used in the future, do you stop at three, five, or 10 years in the future? And since you are, after all, guessing about what those future requirements might be, there is a good chance that you will guess wrong. Agile developers maintain that it is better to focus on what you know, and be prepared to change.
Personally, I have always favored a minimalist approach. As it turns out, the methodology that my colleagues and I evolved back in the distant past worked in large part because, like agile development, it was both minimalist as well as highly incremental. So an approach that involves designing each increment just for what you know at that particular point in time has special appeal. Over the years, this design strategy has helped my colleagues and me create systems that are much easier to understand, design, and implement.
Our approach, like that of agile development, is that when you develop the next increment of an incremental project, you take the new, modified requirements and do a complete redesign, integrating the new requirements with the old. In agile development, this is not called redesign, it is called refactoring, but it amounts to the same thing. Clearly, then, whether this approach is successful over the duration of a large project is a function of how good you are at refactoring.
The trick to having a clean, elegant design in an agile development environment is to build things in, not add things on. In practice, this grows more and more difficult as the size of the program gets bigger and bigger and pressures to finish the product/system grow.