AGILE Will Burn Your ARSE

Posted by Kevin Brady on Fri 30th June 2006 at 10:05 PM, Filed in Software Dev Methodologies

Just read the following article from an AGILE evangelist blogg – Managing “Leaderful” Groups

This article made me really angry. It makes AGILE look like the Hippy Commune method for software development. “We can all be leaders, we are leaders we all work together for the common good etc etc” (sounds like new labour smile) and “Evil Managers as was rudely stated” have to be re-educated. Sounds like Pol Pot’s year zero. I KID YOU NOT there are Project Management training sites offering AGILE training entitled “how to project manage AGILE projects where you don’t have much to do.” CRAZIEST thing I have ever heard.

I have audited a number of large and small AGILE projects at one of Britain’s largest oil companies. The report conclusion >>>> “DISASTER” !!!! & what makes it worse was the fact that they were set-up and mentored by one of the founding 17 who in my view was thinking Fees / More Fees and let’s empty the clients bank rather than delivering a method /approach which would give their client value for money. AGILE was a disaster and a quagmire or expense. I would love to mention the software house’s name and the toad that was responsible for the rip-off but I have a confidentiality agreement with the client which prevents me form say much more. The project teams in my view were in near anarchy and the oil company execs were wondering what oven they had just put their head into.

Without a leader with vision, sound quality management, documentation, risk/issue managements, change control, detailed project plans you have a project resembling something like a Jelly. The problem is that with normal well run projects it’s normally in the bucket where you can see it. With AGILE it’s on the floor, creeping down the stairs and at this point its direction and location becomes unknown.

This disorganised CHAOS exists daily in the new media world where small projects despite the jelly being EVERY WHERE eventually end up in the bucket and are delivered. The problem is when the project is above 4 people and 6 months in duration. However, the crazy thing is that people are really thinking of running large software engineering projects using scrum huddles.
image

“CRAZY MAN!!”

Can you imagine a bridge or the space programme being run like this? I have to tell you I would not have any house extension built using AGILE. The thought of getting paints, carpenters, brickies and plasters to get to together to design and build my extension on the basis of a fag packet requirements gathering process is just plain MADNESS. However, we are asking developers to do this. SAD BUT VERY VERY TRUE.

In a future post I will explain why AGILE is a method from heaven for Software Houses and Management Consultants and hell for the poor clients who have bought into this damaging and destructive paradigm.

This entry has been viewed 5805 times.

READER COMMENTS:

Great post. Interesting that agile appears to work on small projects, but fails so dramatically on larger projects. I guess it’s a simple question of multiple minds and multiple complexities, multiplying themselves to unmanageable levels!

Is there a middle ground methodology between Agile and some of the more orthodox strategic methods? If not - maybe someone should develop it. You could call it Prince Agile maybe! or Agility!

Posted by Peter  on Sat 1st July 2006 at 08:41 AM | #

Thanks Peter,

It would be nice to think that a half way house exists because it would make software analysts /developers with a creative bent (i.e talented) a little bit more cheerful.

These talented and often motivated guys/girls often make the magic happen on cutting edge projects. Seen this for myself only recently on a supply chain project. We must remember that PKZIP, Netscape, MS DOS some of the worlds greatest PC apps would not have turned up without these guys the spifire pilots of our age (“we owe so much to so few”):).

The problem is the thing I term being “half pregnant”.

Yeap you heard me “half pregnant”.

“YOU CAN’T BE HALF PREGNANT YOU ARE EITHER PREGNANT OR NOT NO HALF WAY HOUSE AS FAR AS I KNOW smile

From experience depending on project size you have to have a minimum level of development and project managment process. The half way house in my view for project above 4 people and 6 months in duration just does not exist.

I keep the guys and girls on my projects motivated with TV in the office, Chocolate, music and pinball.  This soon brings the majic back

Great comment Peter keep them coming. Don’t forget my have an open doctors surgery for project issues or problems you might be experiencing.

Posted by kevin brady  on Sat 1st July 2006 at 09:25 AM | #

Hey folks, I’m the founder of the blog linked to above.  I would like to point out that agile methods have worked well on some large projects.  The largest I have personally been involved with was a 20-million dollar 30-person project.  We used a “pure” implementation of Scrum (agile project management) and it worked well.  The project was a resounding success.  I have also heard of much much larger projects being successfully delivered using agile methods.  Take a look at Patient Keeper.  They’re a company that uses Scrum for their product line and delivers large critical systems to hospitals on a monthly basis.

Good luck on your projects!

Posted by Mishkin Berteig  on Mon 3rd July 2006 at 03:42 AM | #

I am currently doing up a bathroom in my house, using the critical elements from Scrum, and it works a treat (as a matter of fact, this is the 2nd bathroom).
However, a couple of things need to be done right, otherwise the result might really not be what you want.
Most important: frequent communication, good feedback, inspect and adapt.
It also helps if the Product Owner (in this case me, the house owner) has a very clear idea of what he wants, because, let’s face it, once the tiles are on the wall it’s kind a difficult to move the pipework around.
BTW, Agile methods do NOT mean that you can drop planning and risk management, they are simply handled differently.

Kevin, I have now read several of your articles and they range in tone from open over dogmatic to pure rant’n'rave. I don’t think you’re helping anybody’s course with that approach (and neither is Mr. Beckford IMHO). If we could all come down to a level where we discuss evidence and tendencies that can be substantiated, it would probably help more in establishing what really works and what doesn’t.

Posted by Wolfgang Schulze Zachau  on Wed 4th October 2006 at 12:44 PM | #

I agree wholeheartedly with Wolfgang, the key to success is by adopting the disciplines that agile methods propose, its far better to find out today that their is a problem in a thin layer of software than in 3 months time in vast layers of code, its easier to test and easier to fix. Agile is highly disciplined when done right like any methodology if done piecemeal it is more likely to fail if the disciplines are not followed which includes planning, Design, unit testing, integration testing and so on.

Posted by Kevin Johnston  on Mon 13th August 2007 at 07:47 PM | #

I am not sure you can judge Agile Project Managment based on a few cases. If that is all it took then more traditional forms of project management should have been tossed years ago. Often it comes down to the skillset of the project manager to ensure projects are estimated, developed and implemented properly. You can have the best project management methodology but a bad project manager can still screw it up.

I have used both methods and a hybrid of the two seems to work well for me to deliver my projects.

Posted by Trevor Fradsham  on Mon 7th January 2008 at 03:01 PM | #

Agile is, as you have stated, nothing more than a buzzword similar to RoR (Ruby on Rails or just ‘Rails’ to the really cool people).  I think that some of it’s principals are valuable and can be applied in a manner that would allow the project to be successful.  I have worked for NUMEROUS Agile infused companies and have noticed one very amusing commonality, none of them do it the same or even close to the same.

The extremely hazardous affect of Agile as I see it is that it promotes a pace of work that is not sustainable over longer periods of time.  Agile seems to create an “always putting out the fires” environment and burns people out.  This causes high engineer churn and weakens the team, department and company.  Think of it this way, take any vehicle that has a standard transmission (that gear shift thingy) and drop that baby into first gear and stand on the gas and watch your RPM’s redline.  This is Agile.  Your vehicle will be able to take this abuse for a very short amount of time but will ultimately blow.  Humans react the same way to this type of abuse.  Some will be able to take it for longer than others but all will eventually seek less stressful and more organized approaches.

Another fundamental flaw is that Agile leaves absolutely zero room for affective QA.  Attempting to stay in lockstep with development as the project progresses is an exercise in futility.  How can you QA something when it has not been developed yet?  It is completely asinine.  Sure you can write test plans from loose requirements (that will change because Agile promotes this change) but try to write any detailed test cases without ever seeing the feature in action.  How about when you test a feature in sprint 1 and it passes but throughout sprint 2 and 3, the requirements change causing the code to change and you have no retest?  Now you have untested code being released under the guise of being functionally correct or you have to make sure you QA team tests the same features over and over again throughout the SDLC.  Neither of those scenarios make for a successful project.

Forget about automation, these short sprints that deliver incomplete features are a nightmare to automate.  In Agile teams, test automation becomes a fulltime job because of the churn caused by Agile.  Imagine if you were a developer and were told “just start writing code and when you get the requirements, you can change it over and over again until it becomes what we want”.  Why not just wait until there is a solid feature to automate/develop and do it once?

I simply can not imagine anyone thinking that starting to build a house before you had blueprints would be a good idea so why are we forcing our software development teams to do just this?

Posted by justme  on Tue 12th May 2009 at 04:32 PM | #

Thanks for the comment Just Me. I have to say speaking out about what is common sense these days is becoming increasingly more difficult at Agile and Scrum gains traction in the wider corporate world. I have to say having worked for the last 12 months on trouble shooting programmes for one of the worlds largest IT consultancies it is interesting to note that all the ones designated as Agile programmes were in the worst financial state and poor customer satisfaction.

I agree with all of what you have said and in the search for a project /development framework which can reverse the 70% + project failure rates reported by the major Project Failure Survey’s I have to say Agile & Scrum are not the answer. I only wish they were smile

Posted by Kevin Brady  on Thu 14th May 2009 at 02:50 PM | #

POST A COMMENT:

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.

Name:

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:

15 + 1 =