Re: What is this article on about?
You need to be careful to distinguish between a badly written article and the subject matter that the article is covering.
17% is the only statistic reported in the article, but this was only those projects which were so catastrophically bad that they risked the very existence of the companies involved. There is a vast spectrum of failure between "sank the business" and "didn't go as well as expected or required".
The article does not report what % of the 5,400 projects studied were successful, but it is not 100 - 17%.
And why shouldn't this guy seek to make a name for himself off the back of some good ideas, IF the ideas are indeed good. Just because those ideas come in part from the past doesn't necessarily make them bad ideas. Some of the best material on software project management was written in the 70's and is ignored by subsequent generations of developers simply because of that fact, to their cost imho.
(ftr - I was only born in 1971. My assessement of the state of the art in the 1970s is with the benefit of hindsight and observing how those practices could have saved the bacon of any number of projects in the 90's and beyond that were run according to "modern methodologies and principles").
e.g. note the emphasis in the Winston Royce paper on the importance of documentation. And note that Agile preaches that documentation is the least important aspect of any project. Every tenet of the Agile manifesto directly or indirectly devalues and dismisses the relevance or importance of documentation (even the three that don't mention documentation directly: 1) processes = documentation, 3) contracts = documentation, 4) a plan = documentation)
The manifesto sounds very "efficient" in principle by seeming to emphasise delivery. The mistake is the naive belief that documentation is not important to successful delivery. Think about all the projects you had to work with where immediate problems were caused by insufficient documentation to be able to understand what the system was doing, how and why and where the inevitable conclusion was that to get that understanding you were going to have to start over, sometimes even before that original project had been completely delivered.
True, Agile does not dictate NO documentation, but the High Priests of Agile in an Agile project will use their church to brand anyone suggesting that more documentation is needed as a heathen and a philistine to be cast into the desert to contemplate their sins.
Biting the hand that feeds IT
