This is Part 3 of the series of articles “Why go Agile?” In essence, RUP and the waterfall approach, even when done under judicious process discipline, still attempted to be predictive software development methodologies. That is to say, they wanted to predict in advance, before beginning the project, matters such as: what the cost of the software development would be, exactly what functionality the software would have, how “X” or “Y” functionality would be expressed on the screen, etc. Despite the academic efforts to predict software engineering, in our opinion, the project has not met with success. The Standish Group, a renowned technology consultancy firm based in the US, publishes the Chaos Report, a compilation of interviews of several thousand project leads that compiles their opinion on the success / failure of their software development initiatives. Projects are polled all over the developed world, from the US to Germany to Japan, as well as in technology intensive nations such as India and nearshore / offshore software development Latin American countries such as Colombia.
Recent Chaos Report statistics found that only 31% of software development projects are reasonably on time and on budget, while on average projects cost 189% of what was originally estimated. Despite the academic efforts of methodologies such as Function Point estimations, Cocomo I/II, Feature Points, SLIM, etc. predictions on the cost of a software development project are several orders of magnitude wrong. A wrong prediction contradicts expectations and causes dissatisfaction. But the real problem is that predictive software development methodologies not only do not work, but add insult to injury by actually making a project worse off and not better off. Why so?: Big Requirements Up Front written documentation is expensive, and slows down project progress: The formality involved in documenting, in advance, everything that is going to be developed in a great level of written detail, consumes thousands of hours of very smart and expensive resources, both at the client’s side as well as the developer’s side. Notice written communication is one of the most inefficient ways human beings have of communicating (it is slow, it takes forever to make it clear, and it is difficult to “ping-pong” a conversation in writing).
So software development projects tends to slog forward in meetings and debriefings about the status of the documents. Furthermore, documentation doesn’t make software; coding makes software. Often during “traditionally run” developments, the team presents management with tons of documentation, lots of expenses, and no code to make up for the investment. This is highly demoralizing and risky. In the final analysis, at this point in the software development project –and several months could well have elapsed just writing documents—the software may be a complete flop and nobody yet knows it. Traditional approaches to software development are administratively heavy: In software development projects based on BRUF and highly specific written documentation, processes are rigid and highly controlled. This requires a whole level of PM’s dedicated to managing the paperwork, the formal requests for changes in requirements, the formal estimations, etc. Again, money is being spent in administrative duties rather than in code.
BRUF creates bloated monsters: Predictive software development methodologies require that the user ideally foresee everything that a software will need before the software begins to be developed. Typically in such projects a fixed price budget is approved up-front for the construction of the project (i.e. the budget that corresponds to the effort estimation). The client’s lead users are very conscious of how difficult it is for a budget to be changed once it is approved. Hence, they err on the side of caution and include everything they think they need and they might need in their requirements for the software. Bloating is so prevalent and so severe in BRUF projects that the Standish Group’s statistics point to 45% of a software functionality being seldom or never used once the software goes live. Imagine that, if they process did not create such perverse incentives, the software development would have cost 45% less at no real, functional expense to the business! We want to close by being fair. The negative impact of traditional software development methodologies such as RUP can be mitigated by working iteratively.
Also, when deployed correctly, they produce software with very few bugs. But they tend to produce the software the client asked for, but not the software the client needed!
More on Perficient Latin America: Perficient Latin America is a world class software vendor partner with more than 30 years of experience in the market. We specialize in outsourcing and nearshoring Agile software development, software maintenance, quality assurance and staff augmentation for Latin and North America.
