I’m not convinced there is that much evidence (hard and empirical) that Agile is actually that successful. Especially if you compare it to Linux (Linux success stories are easy to find).

But let’s try something different.

You say you have a lot of experience with Agile and with successful projects using Agile. That’s great, so how about you give details how you did it?

First of all, it will be a learning experience for a lot of people, and second, I bet that a lot of people will tell you that you didn’t do Agile properly.

Well, actually, they probably won’t since you will be telling a success story, so why don’t you post on the Agile boards with your own story, say that it didn’t work for you and let’s see what the reactions will be.

I’m betting that even you are not doing Agile properly.

I don’t care about doing Agile right or wrong, I care about things that work.

I would love to see data from people where agile fails, to learn and adapt. To gain knowledge. But most of the anti-agile posts and articles I’ve read are devoid of facts.

My replies:

1.) Sure it can. It’s quite easy. First explain what you’re doing. None of those posts explains what they are doing, just that they are “doing agile”. After following agile for over 10 years, I do not know what “doing agile” means. Second in the tradition of the great Hacknot, tell us what you’ve measured and what didn’t work with agile. This could include: Bad code (CC, High coupling, …), miserable developers (do you use statisfaction radiators?), % of missed deadlines, increasing number of bugs. There are many ways to disprove agile. Just not by saying “I do agile and it doesn’t work”.

2.) Agile – especially Scrum – is hard to get right. Especially managment buyin is a tough one and from my experience the number 1 reason for Agile failures. So it is not for everyone, and it is not too easy. From some successful agile introduction I wouldn’t say it is “too hard” though.

I add a 3.) point: The problem with Agile is that many people can easily claim they “are agile” and aren’t. It’s not as easy to claim doing RUP or being CMMi level 5 – because those practices are bound to hard facts.

“The faster the software development moves away from Agile and focuses on more pragmatic and proven technologies, the better.”

There is a lot of (scientific) data about agile. I’d think there is more recent data about agile than any other methodology. I myself have a lot of measurements about agile processes to show that they work (according to my definition of “it works”, better code qualitiy, low bug count, high customer satisfaction, high developer satisfaction, very short time to market but YMMV).

http://beust.com/weblog/archives/000519.html

which basically states that

1) Agile is a religion that can never be wrong and never be disproven.

2) Agile is too hard to get right (since so many people fail with it), and therefore, close to useless in its current form. Something I call a “brittle technology”

The faster the software development moves away from Agile and focuses on more pragmatic and proven technologies, the better.

http://www.cfwhisperer.com/post.cfm/an-agile-xp-debate-the-whole-story

I did post a link to this article on my blog in the comments.

I believe the reason that many attempts at agile fail is that it requires what is essentially a new skill, the ability to constantly adapt code to track the changes in the terminology and requirements of the stakeholders. Much of the body of software practice to date has been to protect code against change, for instance the open closed principle. Because agile focuses on change rather than prevention of change many practices that have been previously followed must be evaluated for effectiveness in this new context. It also becomes vital to practice BDD, this has been particularly difficult for new agile teams as there persists much confusion regarding its’ purpose i.e. many people focus on testing code rather than specifying the behavior of code. It will take time for the industry and education institutions to adopt the necessary skills and understanding to effectively practice agile but when they do I’ve no doubt that there will be a far greater number of successful projects and happy customers.

After saying this You argue that I have’n follow the rules. Eat my shorts…

Should this be used as a criticism of agile? No – the project manager couldn’t tell you which flavour of agile we’re using (seriously), let alone what the project practices are. What we’re actually doing is straight cowboy coding with tight timelines.

It’s very easy to criticise agile on the basis of projects where the the only thing ‘agile’ is the label.

” When developers have never written a unit test before and assume it’s QA’s job to find bugs. ”

This is a problem, I’ve experienced this too and it needs some work to change the mindset.

” I’ve been on projects where we’ve been given less then two weeks for a complete microsite.”

How could you have given deadlines in Scrum? The team sets the deadlines – otherwise there is no Scrum and agile at all.

But getting agile/Scrum into a managment mindset – let go of deadlines – is hard, and the toughest fight a ScrumMaster needs to fight.

“This is just my story, but I can imagine that many people’s first encounter with agile might look like this.”

I can imagine this too. And I’m sorry for that that people are burnt by something managment calls “agile” or “Scrum” but isn’t Agile or Scrum at all.

However I have worked in an “agile” shop for the last year and had terrible experiences. All of them are not because of the agile process per se, but because of a wide variety of misunderstandings, lack of skills and misconceptions in the management.

First of all, nobody at that place really understood agile. It was a term that was thrown at the development team without explaining what it meant. SCRUMs where introduced, but the way they were conducted were just useless (it was decided that all dev teams would gather for 15 minutes and ALL the project managers and sometimes account managers had to sit together).

Then lack of skills. This is in my opinion one of the absolute road blockers. Introducing agile with XP e.g. is a death march when developers lack understanding of their tools like subversion. When developers have never written a unit test before and assume it’s QA’s job to find bugs. I could go on with this list for an hour…

And finally, management misconceptions. Management assumed:

agile == tighter deadlines

This is one of the biggest problems we encountered. Management assumed because we were using agile we could just churn out projects in no time. I’ve been on projects where we’ve been given less then two weeks for a complete microsite. And this attitude just kills every opportunity to really introduce and improve agile process.

This is just my story, but I can imagine that many people’s first encounter with agile might look like this. I am reading more about agile and XP now and see how it all falls together, but if an organization just starts to call themselves agile without actually knowing what that is things get very, very painful.

With that said, I’m eager to work in a real agile team because I see value and a lot of potential in the agile approach.

Cheers,
Jakob

Result? Agile == low quality, generally.

By ‘low quality’, I mean, one or more of critical elements of software have been brutally sacrificed in order to define/meet a milestone. These elements could be performance, design, or raw code quality which includes things like (good and helpful comments, sound variable names, sound factoring of methods, classes and interfaces and packages).

Result? Agile == low quality, generally.

By ‘low quality’, I mean, one or more of critical elements of software have been brutally sacrificed in order to define/meet a milestone. These elements could be performance, design, or raw code quality which includes things like (good and helpful comments, sound variable names, sound factoring of methods, classes and interfaces and packages).

There is a very strong chance you are not doing agile at all I’d say. Dropping all process, hacking along is not agile, it’s an excuse for chaos, poor management and low professional standards.

“Almost all patterns work very nicely when performed properly.”

Yes, if you do agile, agile works. If you do not do agile, it’s obviously not working I assume. This is somehow like eating bananas proclaiming “I don’t like this apple.” :-)

For the set of coders we have on our C++ project the agile process brought out the worst in them. They are OK at being told exactly what to do with a well thought out spec from a waterfall approach but have not done well with agile where they need to think of all the edge cases and account for them before they start coding.

Instead people are just coding away and hacking in fixes as QA brings up the issues later.

There is a VERY strong chance we are not using agile correctly. There was no training, just do it. Teams are too big, scope of work too large, terrible management.

No one has the same agile experience. Almost all patterns work very nicely when performed properly. My agile experience has not been pleasant but I don’t think agile is the problem, management and the programmers are.