December 14, 2015 Leave a comment
“Agile” and the Problem with Estimates
In today’s increasingly fast paced development environments much is discussed on how to develop applications more quickly and what efficiencies can be implemented towards getting them into production. Starting with “Agile”, which advances rapid application development to new extreme levels we are now moving into an additional era of “DevOps”, part of which is to support continuous integration of applications into production. Despite some of the gains in efficiency in both areas there is still little discussion on how one gets to efficient application development in the first place. In fact, there have been very few documents written on how one estimates and schedules new and ongoing development efforts within the criteria that the “Agile” paradigm promotes; though there may be actual techniques involved, little is portrayed about them. However, in lieu of this articles are beginning to appear that are detailing the ongoing issues even with this very popular process paradigm.
One such article, which recently takes a high level look at these issues can be found at the online edition of Forbes at… http://www.forbes.com/sites/jasonbloomberg/2015/12/11/has-agile-outlived-its-usefulness/
The article’s author states right up front that “Agile” is continuing to have issues beyond the basic task and small-project levels as follows…
“Nevertheless, the problems and limitations of Scrum and the broader Agile movement have proven surprisingly persistent, in spite of the throngs of very smart people who have worked in various capacities with Agile over the years.
The numerous complaints about Agile include its lack of focus on software architecture, its emphasis on one-off software projects as opposed to building reusable code, and the reinforcement of the notion that the software development team is a self-contained group, as opposed to participants in a broader collaborative effort.”
Interestingly enough, it suggests that not enough is being done to correct these issues, which could boost the “Agile” paradigm to next level, which is interpreted as a mixture of the “Agile” and “DevOps” paradigms. However, if one analyzes this prospect it may do more actual harm than good if you intend to build a new paradigm based on one that is beginning to show significant limitations.
One of these limitations is that the “Agile” paradigm has made a serious but successful attempt at removing or limiting the reflective aspects of software development. One such aspect is that of project estimates and subsequent scheduling.
Due to the large numbers of organizations that have refused to understand and implement quality project estimate analysis, which actually follows engineering paradigms, companies have floundered consistently in their attempt to implement software projects on time and within budget, that satisfy user expectations. If you remove or ignore such a vital aspect in software engineering you cannot possibly label what you are doing as software engineering as Yahoo has recently done by eliminating another such vital aspect to the engineering process, that of Quality Control.
Though the claimed results in that organization are significant from such a function being moved into the development arena there are two issues here, which have not been explained in this recent announcement (see… http://spectrum.ieee.org/view-from-the-valley/computing/software/yahoos-engineers-move-to-coding-without-a-net). One, there is no mention of the types of projects that Yahoo is concentrating on to make such statements credible or questionable. Two, there is no evidence that by making such a move developers can exceed the maximum percentage in their ability to unearth defects, which has been thoroughly researched to be a consistent approximation of 60%.