This is Part 5 of the series of articles “Why go Agile?”
The philosophy of Agile Software Development sounds very nice in theory, but how does it stack up in practice? At Perficient Latin America, as nearshore/offshore software development vendors, we have deployed dozens of agile SCRUM projects large and small, and have seen for ourselves what we believe is scarce in everyday life: with agile you get your cake and eat it too. Agile is not just faster than traditional methodologies, it is also cheaper and –when done right—produces code output at a level of quality that rivals the rigorous RUP under CMMi 5. Now, is all rose colored under agile? Most definitely not. There is a main caveat to agile software development, and it is such a sensitive issue, that it often becomes a critical deal breaker in convincing an organization to go agile with a project. Ironically, the way agile is sold to a client goes against the grain of what a typical Chief Financial Officer wants to hear.
Let me expound more: companies are traditionally used to purchasing tangible goods at a given price. A server costs “X dollars”. One-hundred PCs of such and such characteristics cost “Y” dollars. In this same train of thought, a CFO wants to hear from her IT department that the software development they are about to embark upon costs a specific amount of money. In short, decisions mechanisms in an organization are slanted towards fixed cost software development projects. But, as we have seen in previous posts, a) it is very difficult –if not outright impossible—to estimate the cost of a software development up-front and, b) forcing a software development project to become predictive is one of the surest ways to damn it to failure, either because of cost over-runs, because the process of estimation is so cumbersome it is not productive, or because the resulting functionality would be “what the client asked for but not what the client needed” (we talked more about this in our previous post “what was the end result of traditional software development methodologies”). How, then, should a software development group approach a traditional company –especially one that wants fixed price—to convince them about agile? Quite simply, tell them the many positive truths about agile, which we summarize as: Agile is faster: Agile replaces a great percentage of written documentation about requirements for conversations about requirements.
The written language is highly inefficient. Imagine two scientists solving a complex and highly nuanced problem by correspondence alone. Now imagine they can meet in a room and collaborate in a veritable intellectual ping-pong. The speed of the conversational scenario will far outrun written responses. In a similar way, when the written language is minimized when structuring a project, and conversations become more “real time” the project moves significantly faster. In our experience, agile is approximately 35 to 40% faster than a project run under rigorous RUP. Agile incorporates what your learn into the end product: Software is never perfectly crafted from the get-go. There are too many variables to tweak during its development to make it a better product. Imagine an expert musician composing a new melody. No matter how expert she is, it is almost impossible for the melody to come out just right the first time she plays it. It has to be listened to, fine-tuned, exposed to the criticism of peers and in such manner matured to perfection. Traditional development methodologies tend to set specific software’s initial requirements in stone. When those requirements begin to be built, and improvement areas are noticed, the mechanisms running the project often make change so hard, and so politically costly for those running the team (i.e. because an expectation of cost fixed in people’s minds will change, for example) that changes and new ideas are not incorporated into the project. In a similar manner, the software development team often notices ideas for improvement, but –since often a fixed cost mediates the project—they prefer not to mention them, so as not to risk a pricing argument with the client. In the final analysis, the project loses, as new and good ideas are not incorporated in the software.
Worse still, changes in the environment and competitive pressures that would otherwise compel change are not taken into account. What is the purpose of hitting a costing target if the software is going to be no good? Agile is less risky: We have heard the abysmally high statistics from the Standish group about the failure of traditional software projects (when polling more than 8,000 initiatives in developed nations, close to 45% are considered unsuccessful!) The problem is that under traditional methodologies one often notices late that a project is going down the path to failure. This is a consequence of working under BRUF (Big Requirements Up Front), where often for the first months there is no software to show, but just piles of written documentation. By the time the first software is run live, and the team notices the project is late, or the functionality is flawed, the money invested in requirements is already too significant. Agile, on the other hand, delivers working software at every sprint (every 2 to 4 weeks). This is tangible software that our nearshore/offshore project groups deliver and can be tested by the client. It can even be incrementally released to production. Hence, the risk of failure is radically decreased, as one can test the quality of the product every month, and every month corrective measures can be taken to straighten a project before real damage occurs.
Agile is cheaper: The Total Cost of a project should be seen as a compendium of the monetary value of the project itself, the time taken to deliver the project, and the quality and potential of the delivered output resulting from the investment. By this philosophy, because agile is faster, has more relevant functionality and is less risky, then agile is in consequence cheaper. But is also cheaper for other more traditional reasons. First and foremost, for every dollar spent in an agile project, 80 to 90 cents go to producing code, and only 10 to 20 cents to administrative tasks. Under other traditional methodologies, 60 to 70 cents go to producing code and 30 to 40 cents to writing documentation and administrative tasks. Hence, for every dollar, you get more code when you go agile. Or put another way, you pay less dollars for the same application written under agile than you pay for that application written in RUP or a waterfall approach. This is important for companies looking for a cost-effective outsourcing partner to deploy services under a staff augmentation, or nearshore/offshore model. Second, agile under Test Driven Development (TDD) is significantly cheaper to maintain. With Test Driven Development, a significant portion of the code is covered by automatic tests (i.e. automatic unit tests and automatic component tests). As an application grows, new modules have to be regressed tested against the existing code, to make sure they do not break what already was working. For large applications this can take more time than the effort spend producing the new modules. Under Agile + Test Driven Development, much of regression testing (70 to 80%) can be done automatically, diminishing significantly the costs of maintaining the application.
Perficient Latin America experience under software development outsourcing models (staff augmentation, nearshoring or offshoring models) shows that, all in all, a well administered software development team working under agile achieves a 30% efficiency margin (in costs and speed) over a similar team working under RUP of the waterfall approach, all the while realizing similar levels of quality.
Regarding Perficient Latin America: Perficient Latin America is a software development Latin America company with offices in Colombia, Mexico and the US. Our customers range from Fortune 500 companies to Silicon Valley startups. Perficient Latin America excels in high quality, outsourcing agile software projects.
