AGILE Fees Feeding Frenzy!

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 | #