The AGILE Storm in a Tea Cup
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 :-
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.