The AGILE Storm in a Tea Cup

Posted by Kevin Brady on Fri 7th July 2006 at 03:56 AM, Filed in Software Dev Methodologies

It would seem that my comments on a post listed on the blogg AGILE Advice where I expressed my views that AGILE methods seem to have moved on from a method designed to make small visual based projects fly (please see my post AGILE Enough is Enough and is now being considered as a scalable enterprise level solution is causing a bit of a “storm in a tea cup”. 


Over the last few months I have seen a significant rise in consultancy requests from companies who are finding that AGILE as an enterprise level solution is massively increasing costs in many cases in exchange for lower quality delivery and often zero impact on the madness that is 70% to 92% annual UK IT project failure rates.

I repeat again the words of Martin Fowler concerning the limitations of AGILE:-

“If you want to build a doghouse, you can just get some wood together and get a rough shape. 

However, if you want to build a skyscraper, you can’t work that way – it’ll just collapse before you even get half way up.”

In my view, it is the FEES gravy train and the Human Rights aspect of AGILE for development staff, which is DRIVING the “Square Peg into a Round Hole” despite Martin’s comments.

At the end of this week I will post an article that explains how I believe the consulting FEES bonanza is behind this change of tack concerning AGILE and its application.  Keep tuned in.

One of the biggest issues in my view faced by the IT industry as I have mentioned in previous posts, is the lack of audited IT project /programme transparency. I have a serious of posts starting next week which explore this area and how things can be improved going forward.
Really Mishkin, Viky and I should not be arguing about one-approach verses another we should be arguing about how we can empirically test different approaches and methods in order to help ourselves and the world make better strategic IT decisions. Billions of dollars of IT project /programme failures occur each year equal to the gross national product of Portugal.

This wastage effects everyone!!!

The big issue surrounding the empirical testing of differing approaches is the fact that the only reliable project failure /success case studies are related to the government due to the courtesy of the National Audit Office or non-government organisations through court transcripts. I have to say the latter source of information in recent years has totally dried up due to the concerted and skilful efforts of “Money Machine” Management Consultants to keep their disasters out of the courts. If it were not for books like CRASH we would have virtually no easily accessible data from this source.

Therefore, Mishkins statement about successful IT projects /programmes being delivered using SCRUM I have to say:-


Do you have access to an independently produced audit reports with answers to the following:-

• What were the project /programme’s acceptance criteria? Were these agreed at the beginning?

• What methods /tools were used to test acceptance and are the results of these tests available for public scrutiny.

• Did the programme /project have agreed project drivers placed in the correct order at the beginning and what was the project or programmes performance against these respective drivers :-

    o Quality o Time o Cost o Scope

i.e. Was the project /programme of work delivered under or over budget and did it turn up on time ?

Without laboratory results (independent, detailed, and verifiable case studies) Strategic IT decisions are made on the following unacceptable basis, perpetuating the MADNESS that is 70% + annual IT project failure rates:-

Metaphysical religious belief in a given approach

Following the crowd. Everyone else is doing this. We must not be left behind.

Corrupt Manipulation. By Money Machine Management Consultants.

Personal Investment is Human Capital – Many bad strategic IT decisions I have come across, especially within SME’s, is staff looking to build a new CV by experimenting with the cutting edge (sorcerers apprentice) at a host organisations expense so they can get a better long term rate of pay.

Self-Spin and Deception. Many organisations when faced with repeated IT delivery failures get very very good at covering up, or spinning these basket cases into glorious successes. One insurance company I did some consultancy for in the Surrey told me the following on arrival

“We have a perfect IT delivery record!”. “We have never ever had an IT systems failure!”.

The fact that the company was almost in management and financial meltdown due to a “BLUE SCREEN, NO GO” pensions application system seemed to have been forgotten by everyone.

The power of spin is truly awesome and can truly rewire people’s brains.

Personal Experience. Most IT managers do not have a statistically significant sample set of IT project /programme successes /failures under their belts to make reliable decision based on personal experience. This is why I recommend in my post Project Auditing Key To Success. That all IT managers should give up two weeks each year to project /programme auditing to increase the sample set.

Until Mishkin and I have verifiable answers to the above audit questions for projects and programmes we are claiming as victories for this or that approach, we are never going to get consensus.

All I can say is that all the large-scale AGILE related projects /programmes I have come across have been a shambles and I am picking up an increasing number of project /programme troubleshooting enquires where AGILE has made what was already not working even worse.


This entry has been viewed 5969 times.



Your comments about the challenges in adapting agile development methods to enterprise IT are timely. As one of the participants in the discussion you mentioned on Mishkin’s blog, I don’t want to overlook the valid issues you raise on this subject. It is important for people in our profession to understand the reasons for and the impact of procedural and cultural changes in IT organizations, as we try to deliver better value to our customers.

As agile moves from the proof-of-concept stage into the corporate mainstream, a wide range of challenges are emerging. You mention the problem of too many consultants of dubious qualifications who demand high fees while delivering questionable value. I’ve said before, and will reiterate now, that this is not a problem inherent in agile development. To raise this question again and again in the context of agile methods is nothing more than a red herring.

The problem of consultants is only one among many issues. Another issue, with all due respect, is with people who take the approach of demanding "proof" while offering no proof of their own that the methods they suggest as an alternative to agile are any better. Presumably, they support the very same traditional methods that led to a need for change in the first place; a tacit assumption on their part that those methods ever actually worked very well. The oft-cited Chaos Report certainly does not suggest that the IT industry is in particularly sound shape at the moment, with nearly all development following traditional methods.

Clearly, there is a need to change something. The questions are, what should we change, why should we change it (and when should we leave well enough alone), and how can we measure the difference quantitatively?

This topic has been coming up more and more frequently as people try to get a handle on the objective merits of agile and lean methods, and how those methods might fit into enterprise IT. It is a complex subject that deserves study.

"Independently produced audit reports" may provide some of the answers to these questions. It is unsurprising that a consultant who specializes in IT auditing would think so. wink

There may be other ways to arrive at an objective assessment of "hard" value, as well. I have some opinions on the subject that I will be sharing on my blog.

Posted by Dave Nicolette  on Mon 10th July 2006 at 12:46 PM | #

You wrote:

I repeat again the words of Martin Fowler concerning the limitations of AGILE: “If you want to build a doghouse, you can just get some wood together and get a rough shape. However, if you want to build a skyscraper, you can’t work that way – it’ll just collapse before you even get half way up.”

Please re-read full Martins article:

The methafore you cited was comparing planned vs evolutionary design, not about Agile itself. Furthermore, he acknowledges the limitations of planned design approach (non-evolutionary):

“So all this makes planned design sound impossible. Certainly they are big challenges. But I’m not inclined to claim that planned design is worse than evolutionary design as it is most commonly practiced in a “code and fix” manner. Indeed I prefer planned design to “code and fix”. However I’m aware of the problems of planned design and am seeking a new direction.”

Posted by hypno  on Tue 14th April 2009 at 02:03 PM | #

Hi Kevin. I read your post and I think you make some interesting points. In general, I agree with some of your assertions and I also feel that Scrum falls into some subpar development practices. I especially liked the analogy with building a doghouse vs. a skyscraper.

Posted by The Software Purist  on Mon 14th December 2009 at 11:22 AM | #


Please feel free to submit relevant comments to this entry but note: inappropriate or purely promotional comments may be removed as will be personal abuse and defamatory remarks. Reasoned debate and substantiated critique on the topic in hand is encouraged and welcomed. Email addresses are never displayed, but they are required to confirm your comments.


Email address is required but will not appear publicly:

Add your comments below:

Remember my personal information for next time

Submit the word you see below:

18 + 2 =