There's been lots of articles as of late declaring that Agile, Scrum or XP are "dead" or are "circling the drain". While I personally don't think agile development is dead, I wondered what others out there thought. Is agile dying, or are people just not following the practices and principles and thereby diluting what agile software development is all about?

+16  A: 

I think we're starting to see more mixtures of programming styles. So pure Agile/Scrum may be rare, but it's definitely being used in conjunction with other styles. In that sense, it is not being diluted so much as being integrated into a larger pool of programming styles and methodologies.

I agree. Pure anything is very meh. I've looked at methodologies ranging from agile to waterfall. None of them are universal, yet people push them like they are THE ONE TRUE SOLUTION. Agile (capital A) is dead, but agile (lowercase a) is not. A good engineer will be pragmatic and agile.
Thomas Owens
+11  A: 

I think that many shops are picking and choosing which agile practices they like. The practices themselves are certainly not dead. Meeting all the criteria (whatever they are) to be an agile shop is rare, though.

Brian Genisio
I agree. After all in XP explained Kent Beck wrote very clearly they're just rules.
+4  A: 

Nothing that is applied by the book works. It's too costly, or it's so theoretical that when it comes to a real situation then we have a problem. I think Agile Programming is great, but you have to adapt the style to your real work environment.

If, for your situation, short iterations broke more of the design then you might adapt to have longer iterations. I think the problem is that people plan less and have a problem because they think that because it contains short iterations that they will fix it later. This cause a lot of problems and cost a lot.

+36  A: 

The terms are now so widely used by so many people (including those who are clueless about them) that they've lost a certain amount of meaning.

In addition, some of the related practices - particularly unit testing - have become so widely adopted that they're now "the norm" instead of specifically agile.

I think of it as being a little bit like what happened to specifically "Green" parties in the late 80s and early 90s: they didn't actually get much political power in terms of elections (at least in the UK) but a lot of their agenda is now part of mainstream politics. We don't hear much about the Green party in UK politics these days, but we hear plenty about environmental issues.

Jon Skeet
Unit testing was around long before people used the terms "agile" and "scrum" to describe a software process... they are not inherently agile.
maybe 'Automated unit tests' was what he was aiming for there. Also just because it was around doesn't mean people used to do it well. Agile enforces it better.
i think the distinction was applying the notion of unit testing to features, i.e. of redefining worthy testable units as the feature, not the 'smallest testable unit' = class or method. The focus on features is what makes it a very good thing.
Steven A. Lowe
Yeah, I think he's referring tot he idea that we need to 10,000 lines of unit test code for every line of actual code. :) In those cases, maybe YAGNI would make sense because who would ever have time to write all those tests!
Seems to me useful ideas don't spread unless they get latched onto a handy catchphrase. Then the catchphrase wears out, but the ideas remain.
Mike Dunlavey
... once people integrate the concept into their own behavior, they "make it their own", and it no longer belongs to the outside buzzword, like "Agile". Personally, I see people doing those things, but they are still way over-designing.
Mike Dunlavey
I've gotta say that in America, the Green Party didn't have much to do with the rise of environmental public policy. It's an incidental relationship, if any, not a causal one.
Dean J
+3  A: 

The only methodology that is relatively easy to find in a pure form is a waterfall methodology, most likely because it has been drilled into so many people's heads from antiquated college texts.

I definitely have found that creating a hybrid methodology that fits the fluid dynamic of your team is very much required. There are parts of any methodology that make sense to a degree, but being able to pick and choose what parts work and put them together in a logical and organized workflow is very productive.

As more and more software comes out that helps control workflows (thinking along the lines of the process management in Team Foundation Server as my example), I firmly believe that "a la carte" methodologies will become more common.

Kinda frustrating since Steve McConnell has been arguing in favour of that for at least 10 years now (Rapid Development book). Read my lips - NO NEW METHODOLOGIES
Not every team dynamic is the same, not every team is the same size, not every team has the same type of skills. Not being able to adapt is a sure route to obsoletion. I've worked at too many shops that have rigidly followed methodologies at the expense of productivity or results.
+15  A: 

Both "Agile" and "Scrum" are project methodologies. Although associated with coding projects, you can use these methodologies with any type of project. For Scrum, you don't even need a computer:

New methodologies are often seen as the "new holy grail" which will "magically solve your project problems" and "get the project done". As soon as people start using any of these, the realize that most of the methodologies make the problems in a project more visible.

Visible problems can be solved, but most of the time the methodology is seen as the "bearer of bad news" and is quickly cast aside because people mix observation and cause.

So now that the world sees that Agile and Scrum project are in fact still projects, with real work involved, and real people, with real flaws, the search for a new "silver bullet" is not over.

In my opinion Agile and Scrum are not dead at all. There will be a lot more "methodologies", and each will have it's own merits and flaws.

Whatever methodology you choose, please try to see it as a tool, not a goal.

To build on your point: Scrum seems to be typically used a project management in software development, but I just took a ScrumMaster course and there were a couple of architects ("I build houses not software") in there using Scrum. Which blew my mind but made me think of it in a whole new light.
It took my awhile to realize your "I build houses not software" line referred to actual building architects and not Agile/Scrum/Alt.Net astronaut propagandists. They like to mix in all of those kinds of metaphors. :)
I watched an interview of the inventor of Scrum (I lost the link, would someone else know it?), where he said the point of Scrum to be to make problems visible. He said that Scrum works even for idiots - they will steadily deliver crap every 30 days.
Esko Luontola
+4  A: 

Agile and Iterative Development: A Manager's Guide has quite interesting sections on

  • You know you don't understand [Scrum/XP/UP/Evo] when...
  • You know you're doing it wrong when...

For example, when using UP, and insisting that all requirements are complete by the end of inception.

I think another difficulty is when agile processes are attempted with geographically distributed teams.

geographically distributed teams cause challenges to all process and work - not just agile...
+48  A: 

I look forward to the end of the hype. (not only for agile/scrum, but for all the new silver bullets that come out)

Since I can remember there was always some new thing that would save the software industry

  • 2nd generation languages
  • 3rd generation languages
  • CASE tools
  • UML
  • OOP
  • Java
  • CMM (and CMMI)
  • Generics
  • Design patterns
  • .NET
  • Outsourcing/offshoring
  • Agile/Scrum
  • LINQ
  • TDD
  • and on and on

Please don't misunderstand me. Some of those things listed above are fantastic. I would not dream of going back to the times before I adopted a bunch of them. But they are not replacements for thoughtful work, nor are they sufficient in themselves to solve the problems of our work.

Software development is hard. (non-trivial development anyway) and we need to use all the tools and best practices we can find. No one process or technology is going to save the day - none of these are one-size-fits all. Each company and project team has to choose their own process and tools accordingly. Again, I look forward to getting past the hype again.

The bottom lime: There is no silver bullet. period.

Any time you have such high expectations and claims of the kind CASE tools and Agile made, there is bound to be a backlash of similar proportions when those "promises" are not met. Whether the fault lies in bad implementations or unrealistic expectations it does not matter - the result is a backlash.

Please remember this is still a young field my friend and those mentioned above are additions and somecase removals of ideas/tools as we gain more experience in this is but a journey
Young field or not, it is ridiculous how the field seems to jump onto any snake oil salesman's claims - The list I put up is just a small sampling, but each (some more than others) were touted as the second coming...There is no silver bullet...
Absolutely agreee. The real advantage of any technology comes when the hype is over. It is good that the hype over 'agile' finishes and we all start really using it.
Sergio Acosta
LOL - yes, and since nothing is a silver bullet, we should all go back to entering our programs directly into the CPU as binary opcodes using toggle switches. Compilers were no silver bullet either, but perhaps they do help us out a little, eh? ;-)
Steven A. Lowe
You left off Model Driven Development and Oslo etc.
Well said, Tim. I happen to think for certain problems there are silver bullets, but they don't necessarily have catchphrases. Your litany of past bandwagons is a good lesson for us all.
Mike Dunlavey
I largely agree with the answer, but not all hype is created equal. While agile has some specific tools that are overhyped (e.g. pair programming), it really made the industry recognize a problem with our entire approach to development. I compare it to what scientific principles did for medicine. The short term hype is misplaced (re: fixing your broken project), but the long term hype is not.
Has LINQ ever been a hype?
Viktor Sehr
@Victor - are you serious? It is all over the podcasting sphere
How about SOLID?
Warren P
SOLID too - though I like the principles, they can be overbearing and burdensome if they are followed dogmatically. They really make more sense in large organizations and in software with a large surface area.
And don't forget XML
Sean Vieira
+8  A: 

I think the problem (and the reason) why companies get tired of Agile in general is that Agile will continually point to where things are going wrong. Agile doesn't shuffle things under the carpet like waterfall does. Agile is not easy to implement and does not fix the problems you do have. It will just show you what they are, via peeling back the layers. Once some companies find this out, they would prefer to move onto the next silver bullet since agile is just "too hard".

Nathan Lee
I'm not sure waterfall "shuffles things under the carpet". Poorly implemented methodologies of any sort can do that. As far as agile being "too hard" I think Donald Knuth put it best when he said "software development is hard". No methodlogy, agile or otherwise, is going to change that.
Bernard Dy
Yeah, waterfall really doesn't shuffle things under the carpet at all. I think, of anything, that's what YAGNI is all about: "Let's cup our ears and since the customer didn't see we needed to extend that library and my pair programming tumor didn't catch it ... lalalala" :)
+7  A: 

Agile isn't dead. It's pining for the fjords.

Sorry, no but it's certainly getting into the 'hype retaliation' phase where the clueless early adopters become disillusioned, and the antagonists crow about the failures in the agile approaches.

I think this will usher in some new approaches that are more grounded in the "reality of corporate america" rather than the conceptual beauty of XP and Scrum. the fact is that Scrum is really easy to screw up, and XP is hard to get working right. (Which is, I guess, another way of saying the same thing).

But many of the practices are very sound, and they will survive.

+1 for pining for the fjords reference. :)
Beautiful plumage!
Carl Manaster
+1  A: 

My opinion on the matter is that sotfware development comes in two different types.

  1. You know the specification of the product you are making, the specifications and who is going to use it and why.

  2. You got a goal, this is what is needed from the program. How it is done or how it is implemented is not important. What is important is if it can solve the problem and how. A common question in agile development is: right now we are not certain that we are going in the right direction, but we can change it if it's needed.

3.) the requirements change, while development is ongoing. Thats what happens often to big projects, which run for a longer time period and where a lot of people (users) are involved. I do currently rapid web-GUI prototyping for a bank, and - boy things are changing rapidly !
+1  A: 

I haven't read "lots of articles", but I did read the one referenced and the one that it referenced, and they both seem to be saying the same thing: people are just paying lip service to the principles of agile without actually understanding and using them, and then wondering why their projects fail.


Steven A. Lowe
There were actually three different articles referenced - each word is a different hyperlink. But yeah, I agree. Duh.
Cory Foy

I think it is very important to use agile tool to support the development cycle. In my company we work for more than two years with InTask software. What I like so much with InTask that it helps the developer as well as the project manger and team leaders.


+167  A: 

Agile is currently in the Trough of Disillusionment:


As with anything technology related, there is an initial hype surge that pushes it far past what it's actually capable of. The resulting backlash is this "Trough".

Eventually, people will grasp what it is really about, and stop drinking the hype kool-aid, and you'll see a steady improvement. Other people will decide that Agile development doesn't fit their organization and will stop trying to bend their process to it. Overall its a win/win.

This pattern can be applied to anything that is good, but was overhyped.

iPhone can be a good example :)
Adam Byrtek
Jon Skeet is another good example! But we're still on the initial upswing...
Steven A. Lowe
Brilliant answer!
I expect this to apply to Windows 7 [email protected] haha :)
One of the things that gets realised in the "slope of enlightenment" phase is that Agile may be very useful in some cases and not others. Hopefully we figure out which cases it's useful for too.
@FlySwat — I'm stealing your graph. ;-)
Ben Blank
@Lowe lol, nice one
Mark Rogers
This graph is Gartner's "Hype cycle" (see
Pascal Thivent
+5  A: 

Just stumbled over this article When Agile Projects Go Bad

Aaron Digulla
+4  A: 

"I think Agile has worked its way into the mainstream such that within the next few years we won’t talk about Agile much anymore; we’ll just talk about programming, and it will be assumed that everyone means Agile whenever that’s appropriate." -- Steve McConnell (8th Oct 2007)

(my emphasis)

+1  A: 

Agile programming is an extension of standard best practices. It is something more sophisticated and relies on very good discipline and team work. Most companies think vice versa – good practices are too expensive and slow for them and they choose fast and light approach which promises agile methodology. And fail miserably. Because it is no matter how you call it bad practice is till bad practice.

awsom comment - many agile zealots out there need to understand this.
+1  A: 

I think possibly it's due to the fact that a lot of people have grabbed onto the "agile" label mistakenly believe that "no process" is an agile process. Agile is highly prescriptive, XP especially so. If you leave out key practices, you may have a lightweight process, but it is no longer agile. You have to work to keep the agility.

From my perspective, agile -- the principle -- is still alive, but agile -- the buzz word -- may have lost some of it luster. Having said that, last year's Agile 2008 conference had the highest attendance ever. And. as others have noted, some of the practices are finding their way into other, heavier-weight processes as well.

+9  A: 

James Shore sums it up pretty well in this article . There is another thread in SO on the lines of this post.

My two cents:

  • I like the notion of Shu-Ha-Ri (Alistair C.'s Agile book). However people jumping onto the bandwagon jump directly to Ha / Ri without the preliminary phase of learning and doing everything to the T.
  • People are having all dessert and no vegetables as James Shore says. Things that are easy to do get adopted.. Scrums, TDD, Continuous Integration, etc. Supporting or balancing practices like RealCustomer, AcceptanceTesting, IterationPlanning, Refactoring, etc. are left out or done in an ad-hoc manner. This is setting yourself up for failure. Don't pick-n-choose unless you know what you are missing out on. Complete the Shu phase.. before experimenting. No free lunch.
  • Trying to cover up people issues with agile practices and tools isn't gonna cut it. They will continue to surface. Org. Cultures where technology is treated as 'Gimme an end date & start coding, I'll give requirements later' slave labor, will not benefit from the agile spectrum. Agile feeds on competence, discipline, respect, feedback, professionalism, trust,.. cultures that don't have this are going to find it tough. Also agile brings issues out in the open in a very 'in-your-face' way..
  • Agile is no substitute for frequent 'Inspect and Adapt', not even close. The good thing is agile 'fails fast'.. so you can change course if you keep your eyes open.

What would the phrase "agile failed" mean, exactly? That a project using an agile methodology failed? What does it mean for a project to fail? Why wouldn't we say "the project failed", or "Joe failed", or "the market failed (to materialize)"? Agile isn't an actor. It can't succeed, nor can it fail.

If people want to be seen as responsible when things go well, it seems to me that they ought to accept that they are also responsible when things don't go well.

But as far as I can recall, no one has ever said that Agile -- whatever that is -- always works.

Ron Jeffries

Update: Ron Jeffries just nailed what I was trying to say with the following post.

If you don’t do what we suggest, then don’t call what you do by the name of what we suggest. Don’t call it XP if you don’t do the XP practices. Don’t call it Scrum if you don’t Inspect and Adapt... The only way to succeed is to build a team who work well together and who get things done. XP and Scrum are the best ways we know to work well together. You have to do right things, and you have to do things right, in order to succeed.

Great response. I appreciated the linked articles.
+4  A: 

This question hurts my head. Any question of the form, "Is X dead?" is crazymaking when you see people doing X all the time around you.

If you were asking "Is Agile working out poorly?" or "Is Agile failing to meet expectations?" that's different. But criminy, of course Agile isn't dead. Five minutes with Google will straighten you out on that.

Amen to that. From what I see (in my company, other companies, Agile Finland's free seminars, etc), agile and scrum are definitely not going away, quite the opposite.
+1  A: 

"Agile Development" is a very broad term. The way I see it (and I might be horribly mangling Robert C. Martin here) agile development is about Embracing Change. Do you have a process, use methodologies, use tools or design your code to easily accomodate changing requirements or facilitate easily changing your code? If you are, you are to some degree doing Agile development.

I think more relevant questions are: Who is not doing Agile Development these days? Who has clients that know 100% what they want before you write your first line of code? Who knows their domain so well that they will not be able to improve their design during development?

Hans Løken
Wouldn't that be mangling Kent Beck?
Tetsujin no Oni

One size does not fit all.

I think people are picking and mixing practices based on what suits their situation. Steve McConnell has been advising this for years - his book Rapid Development gives a catalogue of practices with guidance on whether they suit your project. The book won a Jolt Award in 1997, and Steve McConnell is hugely respected, so it's time it caught on.

Eric Sink put it like this (tongue in cheek):

I'll admit that the body of wisdom literature produced by the Agile movement has some very good stuff in it. But Agile is no different from any other major religion like Christianity or Buddhism. You can learn some great principles and practices there, but formally becoming a member is a decision that should not be made lightly.

To be fair Alistair Cockburn's Agile Software Development also advices pragmatic selection of practices, but IMHO some of the other agile gurus are too evangelical - I suppose they are consultants & they have to publicise themselves somehow. Let's remember we are all from different worlds. If you aren't building enterprise-IT systems you might consider agile a disease.

+4  A: 

Agile is dead? That is a laugh. What percentage of waterfall projects fail? Over half? How many articles have you read declaring waterfall dead?

By the way, if you would like a great laugh, read this waterfall 2006

Agile, done right is alive and thriving. When agile fails, it is an issue with execution not Agile.

For example, some teams will say the are doing agile because they don't want to plan, document, test etc. They use agile as an excuse to do what the want. These folks are called "agile cowboys". They hide behind agile to do as they please, not please their product owner.

Another example is a team that honestly wants to do Agile but no one on the team has experience with Agile. Such a team required embedded coaches. A coach that understands the role of the Iteration Manager, a Dev Lead, a Analyst and a Test Lead. In addition, the business partner needs to identify a product owner. The team as a whole should attend an agile boot camp before they start.

Furthermore, a team must be willing to learn and put in place core agile practices. I have talked to teams that said agile did not work. When I ask them if they had a product owner, a prioritized product backlog, sat in an open work space, conducted daily stand ups, did pair programming, test driven development, automated testing, retrospectives etc. and they would answer no to most or all of them. At that point it was clear that they were not doing agile.

I have never seen a team actually doing agile fail. I have seen teams just doing SCRUM unable to maintain a sustainable pace. Without the engineering practices of XP, you code will degrade and future changes will be progressively more difficult.

I have seen many well functioning agile teams for the last 5 years and they all have delivered on time, within budget with high quality and very happy business partners.

Agile is a widely used and more often misused term. If you hear that agile did not work, ask a few more questions. I believe you will find that a team that executes the agile practice well have a very high success rate. I also believe you will find far more teams claiming they are doing agile than those that claim they are doing the majority of agile practices.

Cam Wolff
+4  A: 

Agile is in crisis because the gurus have run out of clients that they can charge C$400 per hour.

I've seen this... but more often, its not even the *guru*s that are charging the 400$/hr. Just because you call yourself "Agile expert" and get yourself some consulting clients, doesnt mean you know anything about it.

People speak agile, but show less when it comes towards development

+1  A: 

"When agile fails, it is an issue with execution not Agile."

God, that is the #1 excuse from any aglilista about the SCRUM/XP/LEAN methodologies. And that excuse it littered all over the web when it comes to "failed" agile projects--very annoying.

S/W developers and engineers need to get the word out. Agile is the same as waterfall. They are methodologies and provide 'suggestions' in how to communicate to an audience. Waterfall doesn't "fail", just like agile...

In waterfall, the audience is the system analyst/engineer, developers, testers and trainers (hence the heavy influence on domain requirements and tracability, and designs). Use it appropriately.

In spiral, it's about the end user, and developer (hence UML, use cases and modular programming/designs). Use it appropriately.

In agile, it's about the business, competition, and end user (hence stories, iterative programming, developer culture). Use it appropriately.

A lot of concepts in agile have been used since the invention of the computer, just that the application context is different. For most short-lived, dynamic requirements (i.e. how do we make money TODAY) with committed customers and mgt, it works great. Otherwise, I recommend another methodology (i.e. try building a ground station system with SCRUM == FAIL). Also, agile methodologies are like the ADD of methodologies, sprint, refocus, sprint, refocus.... great for college grads that can work 15hours a day, but maynot not the seasoned power station developer.


Actually I think Agile can be incorporated within CMMI. It may seem tricky but possible. Most companies work in an SCRUM way but don't even know it. Of course the good understanding of that approach is needed as well. By the way - if anyone is interested to share his/her thoughts about SCRUM/Agile approach - don't hesitate to contact me - I'm working currently on scrum - a new website about scrum :)