TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Right up front, agile development presents a number of hurdles for many organizations. One such hurdle is that unless you're already committed to OO design, you may have to start there. Most of the agile development gurus start out assuming that OO development is the basic platform.
Next, there are a number of organizational issues. Many organizations have trouble with activities where the team, not the individual, is the key. Personally, I find this refreshing, but for many hard-line managers, it may be difficult. And then there is the issue of the full-time user. In many organizations, it is simply impossible to get the full time of many of the key people. I know that some in agile development shrug and say, well that's tough, no full-time user, no product or system; however, the issue of user involvement can be a deal breaker.
It would seem to me that working on an agile development team would not be everyone's cup of tea.15 In most North American organizations, programmers are brought up to be responsible for their individual activities. Many programmers went into programming because they like to work alone -- just them and the machine. Agile development calls for a very socialized individual. It may be a lot better; it's just not the way that many people have been brought up.
A more significant issue for agile development is the concept of the user. All large systems have many users, not just one. Getting to the requirements with many users is not a simple task. When I see people talk about the user or the customer, I'm always somewhat amused because it shows that there is a fundamental problem understanding the nature of the problem. If you have a customer, then there is some chance you will have a unified set of requirements. If you have customers, you will always have conflicts and ambiguity because multiple people will always have different viewpoints. And having a single person stand in for the customer doesn't necessarily solve your problems; you're still one level removed from the real customers.
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.