Good Agile /Bad Agile

Posted by Kevin Brady on Wed 7th January 2009 at 08:03 PM, Filed in Software Dev Methodologies

I have recently been getting a growing amount of traffic to my site from an excellent blog entitled “Stevey’s Blog Rants”.

I have also received mail from my readers recommending that I mention a particular post of Steve’s entitled “Good Agile Bad Agile”.

Despite the fact that this post is a little dated it is one of the most commented Agile posts on the net because of its open an frank discussion about the potential deficiencies of Agile. If anyone who interested in reading this warts and all discussion about the new Agile religion, then look no further. Its a very well written post casting doubt on Agile as a silver bullet development methodology /framework.

The post has tons of comments which make very interesting reading and is a must for anyone interested in getting to the bottom of what Agile and SCRUM is really about and how in the real world to motivate development teams. One comment added to Steve’s post which really struck home was one written by Clark Stanley where he discusses where the real answers are to are found in the quest to deliver successful projects :-

A successful software methodology (not new, others have suggested it):

    (1) Hire really smart people (2) Set some basic direction /goals (3) Get the hell out of the way

In addition to the steps about, there’s another key: RETENTION. This is basically the “secret sauce” over at Google and a number of places. They’ve figured out that the above works, and everything else about how Google works revolves around RETENTION and ATTRACTION of talent. All the food, money, etc is to make it attractive to the top performers to stick around.

How do you make developers want to work for you? Make them believe the things they hate most don’t exist in your environment. I haven’t worked at Google, and don’t have any inside knowledge, but I do know it’s a publicity traded company, and at the end of the day they want to make a profit and make the shareholders happy. Do I believe they truly don’t have deadlines? No, I don’t. They don’t have deadlines they tell developers about, but I bet they have an idea of how long they’ll let a project go along before they kill it off. I also bet while it may be true that you can swap teams along before they kill it off. I also bet while it may be true that you can swap teams every other day if you want it won’t serve you well when it comes to bonus time.

Bottom line, they’ve figured out above 3 steps, and then built an internal economy that ensures:

  • Bad projects die, and good projects complete
  • Bad developers leave, and good ones never ever ever leave

I’d love for someone at Google to weigh in on this with internal insights. I can say the two things I’ve seen absolutely kill performance on teams is:

  • Bad projects that just don’t get killed. A company that keeps beating its head against the wall just because they don’t “quit”. Stupid, insane, and bad business. Worst of all the good developers smell out these failures waiting to happen and get frustrated beyond all hell when the project keeps running like the Energizer Bunny.
  • Mediocre or bad developers lingering along because a company is unwilling unable, or just completely clueless about performance management. Nothing will drive a project straight to hell faster than some below average performers. Not only do they drag down the project but they drive the top folks out of the organization faster than anything. Sure, there are some people who “like” being the biggest fish in a very small pond, but most top performers like to be around other top performers.

Combine the above two and you have a recipe the ensures you’ll be looking for a silver bullet in any methodology anyone can come up with. Problem is the only thing that really works is to solve the real problems. This leads me to one-word silver bullet software methodology.

THINK smile

All I wish is that I had written this myself. Never a truer ward spoken

This entry has been viewed 1404 times.


Thanks for your ongoing comments on Agile.  I participated in a debate a few years back at a private company and I created a working paper entitled, “Agile Methods and Other Fairy Tales.”  I did not realize it would cause such a ruckus among the Agilista’s. 

I received many many hateful emails which really surprised me.  It caused me to think a lot about software development and address many issues the Agile folks are trying to address.  I started studying the software industry in a new light.  I created an free online book, “Reboot! Rethinking and Restarting Software Development.” 

One thing I have is plenty of data which does not support the claims made by Agile Methodology.  I have consulted with over a dozen clients that abandoned the Agile approach which gave me an opportunity to gather data.  I have another set of data from clients that experimented with Agile.  They wanted to quantitatively study and compare results with some of their traditional projects. Another set of data comes from merger and acquisition work.

The data supports that Agile projects are 30% to 40% less productive than traditional projects.  Agile projects have more defects than traditional projects too.  The data supports that the number of defects grow for Agile projects and shrink for traditional projects.  The number of defects for traditional well managed projects gradually decrease with time.  The number of defects increase for Agile projects with time. 

Another problem is the cost to enhance software that was implemented with Agile methods is much higher than the cost to enhance software with traditional methods.  The cost is about double.  It is hard to get an exact read because the enhancement costs rise rapidly with Agile projects and so do the number of defects. 

One of the problems we have in the software industry is a lack of quantitative data. Many companies think they are doing fine, but in actuality they are not.  In the end, they are Unskilled and Unaware.  They don’t have the basic skills to determine success and failure.

The bottom line, those software organizations with great project management out perform everyone else by orders of magnitude.  There is no secret.  There is no silver bullet.

I think it is worth mentioning that I do not sell any methodology, I do not do project management consulting, my primary role is to evaluate companies and offer suggestions for improvement.  The bulk of my work is evaluating the worth of a software organization.  In other words, I travel around the world for clients and tell them what they should pay to acquire a software organization.  My speciality is software measurement.  As I often say, “I get the facts!”

Thanks again for intelligent writings and comments on the software industry.


David Longstreet
Software Economist

Posted by David Longstreet  on Fri 10th April 2009 at 04:03 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:

10 + 1 =