First, let me say that the Agile processes institutionalized a number of excellent ideas in software development – pair programming for reviewing the product, incremental development to properly manage and estimate projects, integrating testing with development, forcing the customer to be very specific about requirements, and refactoring 3GL code to make it more maintainable, to name a few. The OOP-based Agile processes like XP, Scrum, and the rest, were the first attempt to focus on a specific implementation of a process for software development. (SQA systems, like the CMM, focused on what a good software process should do, but not how to actually implement such a process.) However, I have three big problems with the OOP-based Agile processes.
The first problem is that they focus too much on testing for reliability. Integrating testing with development was an excellent idea, but it is not the whole solution to the reliability issue. When the OOP-based Agile processes were introduced in the ‘80s, the industry average reliability was a little over 4-Sigma, or about 5K defects per MLOC. That was pretty awful compared to non-software products. The OOP-base Agile processes improved on that significantly because of the emphasis on integrated testing. However, in practice there is a limit on what testing alone can do. (I spent two decades in the electronics test business, so I know a bit about it.) That limit is roughly 5-Sigma, or 232 defects/MLOC. The only way you can get better reliability than 5-Sigma in software development is through militant defect prevention, but the OOP-based Agile processes do not do that at all.
The second problem I have with the OOP-based Agile processes is that they remove all accountability from the developer for reliability, schedule, and productivity. Reliability is defined as passing the customers’ acceptance tests. If the software passes those tests it is, by definition, meeting the customer’s requirements completely. Thus the developer is not responsibility for doing anything else to improve the quality of the product, like defect prevention.
The only schedule responsibility the developer has is to resolve small sets of requirements for a particular IID increment. The overall project schedule is the customers’ responsibility via “steering” the development by defining the next small increment’s requirements (which the developers will negotiate down until they are sure they can be completed within one increment).
Accountability for productivity is also removed from the developers’ shoulders because all the metrics employed (e.g., XP’s Velocity) are defined relative to the developer team itself. The metrics measure how well the team performs from one increment to the next. It is typically impossible to tell if one Agile team is more productive than another Agile team, much less more productive than another non-Agile team, unless both groups produce exactly the same product over all the increments. No wonder developers love the OOP-based Agile processes!
The last and biggest problem I have with the OOP-based Agile processes is that their popularity has set back software development by at least a decade. In the late ‘50s the introduction of 3GLs caused a major paradigm shift in software development by increasing productivity by orders of magnitude. In the ‘90s, the industry was poised for a similar paradigm shift from 3GLs to 4GLs. Unfortunately, the OOP-based Agile processes are militantly focused on writing 3GL code. Attempting to use more abstract model representations is dismissed as “BDUF” – Big Design Up Front. IOW, they want no part of 4GLs.
Today there are several commercial transformation engines that will produce an executable directly from just a UML OOA model using 100% code generation. Shops that use those engines report order of magnitude gains in productivity and integer factor improvements in reliability. Yet that level of 4GL development is still in the Early Adopter stage because of the mainstream shift towards OOP-based Agile processes. In fact, there is no reason that agile processes cannot be adapted to 4GL development. Bob Martin, a pioneer of XP, has been on record several times saying that a 4GL is essentially just another programming language. Nonetheless the OOP-based Agile developers remain militantly focused on 3GL coding. Worse, most of them also dismiss 4GL development as BDUF.