Considering the philosophy underlying agile approaches, the definition of what IT project "failure" or "success" means comes into question (Eveleens & Verhoef, 2010).  According to Eveleens and Verhoef, the Chaos Reports are unable to accurately predict project failure (or success) due to contextual (aka "complexity") issues.  When agile teams and their respective contextual projects are viewed as complex adaptive systems, for example, defining success or failure is innately unpredictable.  So, trying to define success or failure rates in an "agile world" may be misleading or, worse, meaningless. 

As a professional developer, I have seen my share of project failures and successes over three decades.  I would argue that "failure" has taken on a different meaning in the last decade in so-called "agile teams".   Software evolves across projects and teams, making the notion of "project failure" is, perhaps, less of a concern that it once was, say under a waterfall philosophy.  Software continues to be serviced and provide service, or it fails, not necessarily the project or the team that supports both aspects.

That said, have a look at Enam and Koru's (2008) older paper for references and links that may lead to later surveys.  There's a repository of success and failure info that may be of help to you.    One relatively recent Forrestor survey by West et al., (2010) found that agile method adoption has reached "mainstream proportions". If agile methods are any indication of agility (not always), then it is indeed an "agile world".

Eveleens, J., & Verhoef, C. (2010). The rise and fall of the Chaos report figures. IEEE Software, 27(1), 30–36.

Emam, E. K., & Koru, A. G. (2008). A Replicated Survey of IT Software Project Failures. IEEE Software, 25(5), 84–90.

West, D., Grant, T., Gerush, M., & D’Silva, D. (2010). Agile Development: Mainstream Adoption Has Changed Agility. Retrieved from http://pmshow2011.programmedevelopment.com/public/uploads/files/forrester_agile_development_mainstream_adoption_has_changed_agility.pdf

Please read my last papers in IADIS AC (2013) and JCKBSE (2014) about that. I will upload them as soon as possible.

The success rates of agile software development and lean IT projects, I believe is poor (as you said around 50%) because of poor planning and poor management supports.

I have seen sucess rates for Lean projects are much higher if attentions are paid -- apriori (well-in-advance) -- on getting the key management supports/buy-in from everyone including higher managements and planning those key projects from grounds-up including definition, design, prototyping, implemention, and customer supports aspects.

I was involved on many such lean projects. Looking back, I had better sucesses since we (our lean team) paid greater attentions on detailed planning and seeking key management supports from get-go.

Take a look at some of those listed herein:

Knowledge-based Enterprising (KBE) Strategy for Lean Product Development (LPD)

Conference Paper Knowledge-based Enterprising (KBE) Strategy for Lean Product...

The success rate in a Lean Project depends a lot on what you want to do. And indeed, only results in best rates, if you do a lean mindset project in the top down format. Did you read the book "The Lean Mindset: Ask the Right Questions?" and visualize the experiences of the authors?

The problem is defining either "lean" or "agile project." Lean is typically not about projects but about products. And if you read books like "The Toyota Production System" you find that people use the term "lean" for everything from Scrum and TPS-based developments to the ideas from Roos and Womack. They are only casually related, and most people who are doing the latter don't understand the former; most of them don't know the difference. And lean isn't about measuring some final result but about continuous improvement. If you take that perspective, then lean can't fail: only the product fails. Then it becomes a matter on who you want to blame.

So, as the Japanese might say: Mu. You have just asked a non-question.

@Bryan: Thanks for the links to papers on project success and failures. They are great. As  they would say in Japanese:優れた  Sugureta  ;) to James (and to Google Translate for the translation)

The last I read from Capers Jones was uncommitingly stated disappointment, riddled with words like "vague".

The best paper I've read is by Magne Jørgensen. He showed some research data to some agile experts — data about the performance of agile teams. He asked the experts if they thought that the data indicated that agile was better. The experts wholeheartedly said "yes." It turns out that the data were random. ("Myths and over-simplifications in software engineering," Lecture Notes on Software Engineering, Vol. 1, No. 1, February 2013)

In other words, LinkedIn groups are NOT the place to go for any scientific answers. (I know — I'm one of those agile people hanging out there whom Maya talks about...) I am not sure there is any place you can go to get answers because of the contextualisation problems I mentioned earlier. I'd love to see the experimental design of any paper that claims to have conclusions in this area, to see how they delineated agile projects. I'm guessing that most such rationalisations are worth a good giggle or two.

Hey, Maja - You said that "quite a few people helped me assemble a good amount of industry data." When you use it (in a university setting, which is a public setting) are you allowed to cite the sources? Context is everything, and it's difficult to totally encode context. Revealing sources is a sine qua non of scientific research; without it, it's just more Capers Jones data where the sources are "vague."

If the sources aren't transparent I'm concerned that it reduces to the same problem of defeating the purpose of reporting data in the first place. And if they are transparent it's a puzzle to me why people aren't forthcoming in the public social fora.

@ Maya, my papers cited hear, now are available for download :) Any difficulty please tell me.

Estimating software failure rates, based on Chaos Reports, for example, runs counter to emergent software development thinking and practices--i.e., agility.  See Eveleens and Verhoef (2010).   Software systems and teams coevolve.  I've been researching effective agile teams and their behavior for my PhD, which I am about to defend.  In short, I question whether it is meaningful to combine the failure rates of agile IT teams and traditional IT projects. I have not seen much research in this area.

That said, have a look at recent articles citing Glass (2005) to gain a better perspective on what "failure" means to a modern agile software development team or IT team.  As a 30+ year software developer myself, how I view IT failures today does not equate to how I viewed them 5-10 years ago.  The "team effect" has, to a large extent, weighed in more heavily than the project management effect.  This is consistent with the self-organization teams phenomenon.  How you define IT project failure has necessarily changed with the times.  In my research, "being agile" is the focus, rather than "doing agile" by following agile methods.  The former is effective team-oriented (e.g., theories of effective teams apply), while the latter is project-management-oriented (e.g., adopt Scrum).  McAvoy et al. (2012) suggest research and teams focus more on "being agile" and effective team behavior, rather than following methods by rote.  Chase some references and you  may find some failures (success) rates for agile IT projects.

Eveleens, J., & Verhoef, C. (2010). The rise and fall of the Chaos report figures. IEEE Software, 27(1), 30–36.

Glass, R. L. (2005). IT Failure Rates--70% or 10-15%? Software, IEEE, 22(3), 112. doi:10.1109/MS.2005.66

McAvoy, J., Nagle, T., & Sammon, D. (2012). Using mindfulness to examine ISD agility. Information Systems Journal, 23(2), 155–172.