Is Agile Development Dead?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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: http://www.mountaingoatsoftware.com/task-boards

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.

Answer 7

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.

Answer 8

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. http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf

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.

Answer 9

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".

Answer 10

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.

Answer 11

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.

Answer 12

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.

Duh.

Answer 13

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.

Cheers!

Answer 14

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.

Answer 15

Just stumbled over this article When Agile Projects Go Bad

Answer 16

"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)

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

"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?

Answer 22

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.

Answer 23

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.

Answer 24

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

Answer 25

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

Answer 26

"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.

Answer 27

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 :)