TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
The keys to being successful with agile development are almost the mirror image of those you need to be successful with CMM. Where CMM tends toward rigidity over management, agile development tends to be perceived as out and out hacking with an overall lack of discipline.16 Agile development projects also have a tendency to become inwardly focused.
Agile development differs most from traditional systems approaches in organizational matters. As a result, if your organization is going to be successful using agile development, then it must face the possible organizational fallout issues early on.
When agile development gurus say that you need an on-site customer, they mean it. They don't mean half-time commitment or quarter-time; they mean full-time. This is very hard for many organizations to meet. Indeed, agile development not only calls for the full-time commitment of users, it requires the key most knowledgeable users -- the most difficult people in the organization to get your hands on. The only thing that can be said in the defense of agile development's insistence on the full-time, key user involvement is that it's the only thing that works in the long run if you want good systems. As we have said for years, good systems require good users.
Secondly, when agile development calls for pair programming, it means two programmers working together all the time. This is also a requirement that many organizations have trouble with. Many software managers and many (if not most) programmers see themselves as hardy individualists. Indeed, many of these people don't like anyone even suggesting that they look at their code (even after its done, in some cases).
This has to be overcome. Programmers must be briefed and must understand the nature of pair programming, coding standards, and the fact that they are to do test-first design and deliver working versions every couple of weeks. A second issue involved with pair programming is the measurement of individual performance -- you can't do it. If you (or your management) insist on measuring individual performance, don't start down the road to agile development because you'll only end up frustrated. Agile development is based on team performance; you need to understand that.
Agile development is much more of a stretch than CMM is for most organizations. Although CMM may be seen as overkill in many organizations, at least most people in the band will recognize the music and the instruments. With agile development, we're talking about something quite different, something more along the lines of new music, new instruments, and no conductor -- a jazz ensemble as opposed to a concert band.
As a result, training is a key element to the success of agile development. Successful organizations need to bring in people with significant experience doing agile development and use them to train their people bottom up.
One of the other keys to success with agile development is a hands-off project management style. Project and software managers must learn that agile development is managed mostly by the project team (including the users). Agile development is consciously a minimalist management strategy. If you want high-quality software delivered quickly, application developers argue, then you should manage the key pressure points (i.e., the product releases).
Finally, organizations need to study agile development closely before they start. In fact, the key managers, users, and technical leaders should go to visit reference sites and talk seriously with their counterparts to find out what kind of problems they encountered.
Agile development is normally promoted bottom up in most organizations. It is usually brought in by some of the best and brightest young programmers, often the same people who have been the most serious supporters of OO development and new languages. For this reason, serious attention must be paid to getting some of the older, less up-to-date people educated. It is probably a good idea to have a few of these people introduced to the first or second agile development project both for support and as a way to gauge what kinds of problems you're liable to have when you try to roll out the approach to other projects.
Agile . since Jun 23 . Index . DOCs TOP TOC
As with any war, there is a lot of propaganda. And anywhere there is propaganda, there are slogans. For the agile development folks, the slogan is probably, "We're agile, and you're slow, bloated, and old-fashioned." If you believe the application developers, agile development is a minimal, fast-track approach, and everything else, especially CMM, is heavy-handed, bureaucratic, and doomed to failure.
On the other hand, CMM proponents point to the fact that CMM is used by some of the largest software organizations in the world on some of the largest projects. Their slogan would probably be, "Agile development is for small (inconsequential) projects; if you want to do some important (big, mission-critical) ones, you need CMM!"
As is always the case, there is some truth to both these points of view. CMM is bureaucratic and somewhat prone to producing huge amounts of paper. It is very expensive, but then again, so is failure. Small boats are, as a rule, faster and more maneuverable than big boats; on the other hand, you can't transport millions of gallons of oil or thousands of passengers on a small boat. The approaches that you use on small projects often don't scale up.
The agile development folks respond that their management movement is just as much a development strategy. If you're careful, they maintain, with how you plan your increments, you can do big things with a lot fewer people in a lot less time. They argue that you can create much larger projects (and organizations) than you could have in the past. The key is collaboration and commitment.
So who are you to believe? Well, as with most things, the answer lies somewhere in the middle. The war between CMM and agile development provides the opportunity to make both approaches better.