AGILE Fees Feeding Frenzy!

Posted by Kevin Brady on Thu 27th July 2006 at 03:30 AM, Filed in Software Dev Methodologies

AGILE, as mentioned in previous articles “AGILE Enough is Enough”, “AGILE Will Burn Your Arse”, is pure “Farty Floops” (a phrase coined by a good friend of mine ) as a fit for purpose approach to delivering large scale IT projects /programmes of work. 

In the beginning, the scalability of AGILE methods was even questioned by some of the AGILE founding fathers and leading authors in this field.

Then the fees gravy train came and changed everything!!!!!!!!!!!!!! 


The stratospheric popularity of the AGILE has kicked these concerns /potential weaknesses quietly under the carpet, where I fear they will stay until more money is lost on failed large scale IT projects /programmes of work.

AGILE is like a gift from the GOD of Management Consultants. 

The IT development staff (in-house and client based) love it because they can be creative and individualistic (released from prison at last); and lazy project managers can leave home on time because everyone (and consequently no-one) owns the delivery. It’s the equivalent of the “Human Rights Act for IT”, liberating but expensive for those holding the purse.

Clients also think AGILE is sexy because it promises the riches of Elderado:-

- Rapid IT development (that old chestnut)

- Reduced development costs

- Quality

All for a “little softening in the business terms” (be very afraid). “Remember, if something sounds too good to be true it probably is!”

Management Consultants and Software Houses love “High Gain No Pain” paradigms because they are easy to sell and can be implemented straight out of the box without the need to make PAINFUL changes to a client organisation.

This sitaution can be further explained by an extract from a book I am reading at the moment “AGILE Software Development by Alan S.Koch” entitled the “AGILE Manifesto”.

I KID YOU NOT this is a message in a bottle to all Software Houses and Management Consultancies that Raping & Pillaging is still alive and well.

When I first read this book, the fee earning opportunities were so evident I just for a second thought “perhaps I should follow the money and not my conscience”. Well my conscience won the day and here is my take on part two of the four-part Manifesto

Part 2 – “We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:”

- “Individuals & Interactions over processes and tools”

imageAnarchy & CHAOS – This FOG tends to destroy detailed resource plans and associated project plans. FIXED PRICE deals are not possible. TIME & MATERIALS wins. The”Money Machine” Management Consultants and Software Houses run all the way to the bank when they hear T&M. This is a path to great riches.

- “Working Software over comprehensive documentation” 

imageHow can you test large software systems without detailed requirements /tech documentation? You get the “what is a bug and what is a missed requirement argument” come testing time. This makes software warranties worthless!!!!!!!!!!!!! No good having working software if the client does not receive what was expected. This also leads to poor maintainability, and future development is made more expensive through knowledge monopolies (no detailed tech specs) on how the system works. Large Software House and the Money Machines (Big Five Management Consultants) love this because they can hold you to ransom if this software is a real money earner. Client losses here in my view and the software suppliers win !!!

- “Customer Collaboration over contract negotiations”

imageWhen all goes wrong, it will be impossible to find out who was responsible among a homogenous melting pot of business and IT people. From personal experience expecting business people to be in constant contact with a project right through to the end in terms of requirements specification and testing is just not possible or feasible. When I have pointed this out to clients in project feasibilities, they have always run a mile!!.  With 70% project failure rates recorded over the last 15 years in various surveys, this is a real risk and the winner is once again the suppliers, remember “possession is 9 tenths of the law” they’ve got the money and you’ve got the junk. Great swap in my view.

- “Responding to Change over following a plan”

imageIf you don’t follow a plan you will never be able to estimate future completion costs for a project. Change is featured in many many surveys as one of the top 5 causes of project failure in the US and UK. When I have worked for Software Houses I have always encouraged change because its is a really good way of breaking out of a fixed price contract and turning these agreements into lucrative Time & Materials contracts. AGILE is a wonderful way of making change a seriously effective fees generator “lots and lots of lovely gravy”. Believe me I have done it myself. AGILE is a “gift from heaven”.

-“That is, while there is value in the items on the right, we value the items on the left more”

imageWhat they really mean to say is AGILE implementations by major software houses or “money machine” Management Consultancy on behalf of clients, it is clear that they value the stuff on the left as much as possible and only get involved in the stuff on the right as a necessary evil. The problem is that the stuff on the right interferes with the fees pipeline and encourages litigation.
AGILE is a wonderful sales opportunity and a great revenue earner.

The GOLD rush is on!

Always remember which guys really made it big during the GOLD Rush.


This entry has been viewed 5634 times.


Excellent post.

Posted by ChrisJ  on Fri 28th July 2006 at 10:57 AM | #

Yes, Agile is difficult to apply to fix-priced RFP-style bids.  Not impossible, just not a very natural fit.

Agile is about trust, and a relationship with the customer.  Contracts and RFPs are devised to close every loophole - they are the opposite of a trusting relationship.  Hence, we value “Customer Collaboration over contract negotiations”.

Don’t mistake that for an expectation of undeserved trust though.  It is very easy for a client to tell when Agile is not delivering - because an Agile development team must be delivering tested and approved user-functionality nearly constantly. 

If they are not, then they are failing, and it is easy enough for a customer to terminate the relationship.

Posted by Steve Campbell  on Mon 7th August 2006 at 07:48 PM | #

This proves to me that Agile is not an instant fix for your problems. It might have major flaws. If you have a good team, a fair project manager and a good relationship with the customer you can achieve much more than with a traditional approach.

Posted by M. Groeneveld  on Mon 11th September 2006 at 02:37 PM | #

M.Groeneveld - I totally agree. The new media industry proves this every day

Posted by Kevin_Brady  on Tue 12th September 2006 at 12:35 PM | #

I don’t know. This sounds like pure FUD to me.  What experience do you have with Agile development in practice?  I’m a member of a team (both contractors and in-house) that just shipped an 18 month project spot-on time using XP.  The quality compared to the last version of this project went through the roof and I’m not hearing ANY complaints from management.

Some misconceptions you seem to have:

“Agile means there’s no accountability.” As a developer I felt *more* accountable rather than less during this project because we had to produce a tangible release every two weeks that delivered what we promised.  Over time the co-ownership of the code meant that anyone with a problem that needed to be fixed NOW could go to just about any developer on the team and they had the traction to make the fix.  Co-ownership means no one can hide behind the excuse that “the other guy wrote that.”

“Expecting business people to be in constant contact with a project is not feasible.”  I agree that this is probably the hardest part from the standpoint of selling Agile methodology.  It makes heavier demands on the organization to be involved in this way and peoples’ roles often need to be redefined to make this possible.  This point actually gives the lie to your contention that Agile is some kind of quick, attractive fix.  What you don’t address are the outcomes that an organization can expect from committing to this process.  In my experience (admittedly, all of one project) the results were extremely good.

“You can’t test large software systems without detailed requirements /tech documentation.”  You’ve obviously never done test-driven development.  Ours was a large system (about 2.2 million LOC) and between having almost 100% unit test coverage, automated functional test coverage, old-fashioned QA working off of detailed user stories, and fairly frequent beta tests, this baby is one of the best-tested pieces of software I’ve ever shipped.

“Agile means there is no plan.”  News to me. Agile is about having an efficient, fair process in place for evolving your plan when it’s needed; it’s not about dispensing with planning.  I didn’t see any less forethought or any fewer milestones that had to be met in this project than in any other I’ve been involved with.  Quite the opposite.

I agree that a yellow light should go on any time some idea gets hyped the way Agile methodology has.  But that just means people need to do their homework to know the facts, which was always the case, right?

Posted by Davi d Beers  on Tue 12th September 2006 at 03:05 PM | #

Hi David,

I have delivered more heavyweight systems than fingers on my hand. Take a look at my Bio. I understand testing all to well. At its simplest if you don’t have a clearly defined use case model you can produce good scripts.  I understand automated testing and have used it myself many many times. However it has its limitations which means it can’t be used on its own.

It would seem to me that you’re running a non typical Agile project where the model is kept up to date during the development. Obviously comprehensive testing is possible under these circumstances. This does not happen in typical Agile projects where the emphasise is always on build and less on documented requirments defintiion. Then we come into the zone of how much you can change Agile before it becomes something else.

No plans remark. I audited 2 years ago an Agile programme set-up by one of the well known founding fathers (he should no what Agile means). The only plans I saw projected no more than 1 month ahead. Without a plan at least at stage level you’ve get the following problems:-

- Resource management becomes non existent. You can’t predict when people are due to leave until the last minute. Not efficient.

- You can’t do What-if change control analysis to assess the impact on cost /schedule for any given change when your project telescope can only see 28 or less days ahead.

- You can’t estimate contingency for holidays, sickness etc accurately because you don’t have the whole plan only a 28 day slice.

-Cost estimation is CRAZY. You can never say what the final cost will be. Only the cost up to today and 28 days ahead.

All this to name but a few.

All this seems to suggest I am anti Agile. I am NOT. I say in all my posts it has its place despite these obvious issues detailed above. I have seen it work in the New Media industry frequently before the name Agile was ever thought of. The issue I have is the building of large systems of critical importance with strong requirements to be maintainable and migratable going forward. This is where hacking stops and engineering starts !!

Posted by Kevin Brady  on Tue 12th September 2006 at 03:47 PM | #


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:

20 + 2 =