I'm writing an Agile course for some of the new guys we are on-boarding recently, and I want to add a cautionary tale so they understand that Agile is not meant for all projects.

My problem is that, because of the nature of the projects I work in with Agile has worked pretty well so far, I can't honestly point out what can go wrong and why when you use it in the wrong kind of project.

What are things to look out for when an Agile project goes wrong?

  • 18
    Most of the horror stories I've heard about agile were more about the people involved than the kind of project they were working on.
    – Matthieu
    Apr 2, 2012 at 17:29
  • 1
    I see several questions that point to Agile pitfalls in the "Related" section to the right------------------->
    – CFL_Jeff
    Apr 2, 2012 at 17:36
  • 1
    I revised the question to not invite story time and instead ask about individual concrete facts about where Agile goes wrong.
    – maple_shaft
    Apr 2, 2012 at 18:16
  • 3
    @Oded What approach does work well when there are "hard deadlines without give on the functionality"? Apr 2, 2012 at 21:48
  • 6
    @irrationalJohn - The death march, of course ;)
    – Oded
    Apr 3, 2012 at 7:59

8 Answers 8


The biggest failure with "Agile" teams is a result of what is called Cargo Culting. Essentially, teams want the effects of successful agile teams so they mimic the visibile actions

  • Daily standups (that run for an hour or so)
  • Breaking work into sprints
  • User stories (that are usually little more than a sentence but an estimate is expected)

Those are the three that you'll see consistently "applied" in these environments but very little committment to actually being agile. In fact you'll hear management say we're "doing agile." (Run away at those two words it's a bad sign.)

You'll also hear a lot about technical debt but their definition of technical debt is "do it quick and dirty and maybe we'll get around to making it better later." (Translation: we are going to make it sound like we're concerned with maintainability but in reality we will keep the same boiler room mentality because that's what's worked for us in the past).

Other key phrases: "I know these stories aren't fully defined but we're doing agile so we can fix them as we go."

"We're doing agile development so you should be able to accomodate what I need within the sprint as I identify it."

"We're not able to lock down our committed stories at the beginning of the sprint because needs keep changing mid-sprint."

The key indicator on whether an Agile project will be successful is if the project lead (scrum master or whatever role) has had experience or formal training on leading an agile project. Too often I've seen people read about Agile in a book or take a two day course on being a scrum master and think they've got the chops to successfully implement it. Sorry it ain't happening captain.

  • 4
    I don't fully agree on the key indicator to success. I would say the key indicator is real commitment by both management and developers, and at least a basic understanding and acceptance of Agile rules by customers. Even the world's best Agile training can't get you far if management behaves like you describe above. OTOH with enough determination and enthusiasm, one can learn Agile even from a book and apply it successfully in a project via successive refinement - if management supports it in earnest. Apr 3, 2012 at 7:16
  • Just an aside, can you explain what "boiler room mentality means"? I've heard it before, just never heard an explaination. Apr 3, 2012 at 14:51
  • 2
    a "boiler-room environment" is a high-pressure, fix-it-now-by-any-means area where the working conditions are always unpleasant. The boiler-room mentality perpetuates this sort of situation.
    – Hellion
    Apr 4, 2012 at 14:55
  • 1
    "... the project lead (scrum master)...": I recently listened to a talk by Bob Martin maintaining that the scrum master was not meant to be a project lead in the beginning: it was a role to be rotated among the team members (developers involved in the project, not managers) and was only supposed to check that certain agile principles were enforced throughout the sprint.
    – Giorgio
    Apr 16, 2015 at 6:07

People that didn't understand what agile is (was?) all about and apply it to:

  • clients that are unavailable for comment until the deadline
    ...and threat legal action afterwards;

  • managers that keep developers away from the client, (probably because they're slightly underpaid, and could jump ships, going to work for said client) and play a game of the "broken telephone" in a desperate (often successful, though) attempt at looking busy and useful,

    See also: mushroom management, aka "kept obscure, fed manure" and pointy-haired bosses. :)

  • teams that are too big to go anywhere;

  • companies that are keeping on their payroll once-renowned system architecture designers that are desperately diverting attention from the fact they completely lost sight of the actual coding craft, by overdesigning magnificent, unpractical, hard-to-realize, UML sagrada familias.

  • 2
    Wow, Chinese whispers, really? Sounds hella racist. Apr 2, 2012 at 20:59
  • 12
    I don't agree with your hypocritical indignation about racism. Go tell racist to the wikipedia entry on the topic and to its reference to the oxford dictionary 2008 edition.
    – ZJR
    Apr 2, 2012 at 22:31
  • 3
    @Canlas You sound hella north-american.
    – ZJR
    Apr 2, 2012 at 22:37
  • 3
    What on earth does playing a game of "telephone" mean? Really don't think that edit was in any way necessary...
    – Cocowalla
    Apr 3, 2012 at 9:12
  • 6
    The actual name of the game is "Broken Telephone" (already edited) and as ZJR points out its not a racist phrase, I actually linked the Wikipedia article to "Broken Telephone" and guess what? it redirects to "Chinese Whispers" =)
    – Chepech
    Apr 4, 2012 at 14:18

Agile is not suitable for fixed-term or fixed-price contracts. Once you've signed up for such a beast, you have to deliver. Agile is very good at continuing development for ever, as customers change their minds and 'clarify' their requirements. That does not help you on the day the money runs out, but still have to finish the work.

Agile is very good for the post-project phase when you are doing incremental updates and bug fixes however.

The other aspect where Agile fails is not a fault of Agile, its a fault of people who insist on all the old stuff like full-on project documentation, up-front designs, and poor lines of communication. (The half-arsed agile manifesto).

  • Hold it. Do you really think that most Agile projects are intended to continue "for ever"?
    – user16764
    Apr 3, 2012 at 0:12
  • 1
    that depends on the project, some as open-ended and continue while there are new requirements to include. But most agile projects are not intended to finish and ship on a set day. I was particularly thinking of government contracts that have set milestones to meet.
    – gbjbaanb
    Apr 3, 2012 at 10:13
  • Formally, a project is never open-ended; the single key defining feature of a project is that it has a (start and) end date. It's products and services that you maintain long-term. Apr 7, 2013 at 11:31
  • 1
    "poor lines of communication": As far as I know, good communication has not been discovered by agile, and agile methodologies can do very little with dysfunctional teams that are not able to communicate.
    – Giorgio
    Apr 16, 2015 at 5:51

Here are a few questions that may be useful to look for an answer in terms of finding an example where an attempt at Agile can go poorly:

Have you ever heard of "pseudo Agile"? Here are a couple of blog entries about it:

There is something to be said for companies that may take their own view of what is Agile and butcher it into something else.


I worked on a highly successful Agile team, as well as a few that attempted Agile, but couldn't get it to work.

The successful one had the following elements:

  • Truly "Agile" requirements. There were user stories, and we coded off of them.
  • Available product owner. If a user story I was coding from was incomplete, I could easily go to the product owner, ask him what should be there, add it, and the complete the code.
  • Commitment to the process and a realization that it was a learning curve.
  • Focused team.
  • Managers who knew and understood the Agile way of doing things who were committed to making it work.

The successful team did Agile, and did it really well. I would think that if you don't have any of those points above, you could fail quite easily. The first and second things go hand in hand, and if you don't have that, then Agile won't work.

The team I was on that didn't do Agile well had a few elements too:

  • Lack of committment from management. The management didn't believe in the philosophy, and were hesitant to commit as a result.
  • Requirements documented in other places than user stories. See above about management commitment. Also, we had highly paid requirements analysts and big expensive requirements tools that someone needed to justify the use of.
  • Pretty much reflects my experience with Agile, +1. Either the whole team (including business rep and management) commit do going Agile and it works well, or it's just some developers that want to do it and it's a case of crash-and-burn. Apr 3, 2012 at 1:04

I will add to the great answers already posted that, by my experience, agile and specifically Scrum will only work if management AND team are willing to put lot of visibility of what's going on.

This means that in public companies (governments for example), it will be very difficult to make it work properly.


I do not know this from personal experience, but hypothetically, there are many circumstances when agile is not the best option.

  • Projects whose product is life or property critical - For example, you do not want to use agile to develop the software that runs your pacemaker. Why? Because you have near-zero tolerance for errors. Consider a classic example of programming error within medicine in regards to the Therac 25. Granted, it wasn't built with agile, but the point is this: Developing life or property critical is no place to say, "we'll clean that up on the next sprint" or "we don't need great, just good enough."

  • Projects with too many junior developers - Agile expects a certain amount of autonomy within the participating group. If there isn't enough experience on the team, then that autonomy can work against you.

  • Projects that require a higher degree of control or planning than what is traditionally offered with Agile.

I'm assuming either someone else will jump in and help out with better examples, or downvote this bit of tripe I've written ;-).

Just remember that when the only tool you have is a hammer, every problem looks like a nail. Not all projects are nails.

  • 5
    Agile does not preclude life-critical systems. If an item is not fully tested and accepted by the customer, it is not "done" and is not released, not matter whether the sprint is done. It may be possible that other items (requirements, stories) were properly completed and tested during the sprint, so they CAN be released--if the customers want them to be. Agile is always about delivering precisely what the customer needs, with high quality. Apr 2, 2012 at 23:01

Agile in my opinion is all about the culture of the team that is practicing. If the culture sucks, the team members do not get along, and people are not collaborating to meet sprint committments then the culture or team is deficient.

I wouldn't necessarily say however that Waterfall will necessarily work in such an environment, it is not a black and white situation, very little is truly black and white.

A good Agile team is communal. They have a tribal spirit of community where all members are working towards the same goals. The team succeeds or fails together. They work together on solving problems. A team member will stop what he is doing with his tasks to help a struggling team member out. Everything is sink or swim.

When this is not the case then it quickly becomes apparent what is wrong. If the team members are sitting down, typing on their laptops or texting, or zoning out during the daily standup then you don't have a good Agile team. If your project managers are enforcing all the Scrum procedures, definitions and terminologies but everybody is just keeping cadence and paying lip service, then this is just a rather blatant farce of what Agile truly is, and this in many ways leads to team dysfunction, inefficiency, missed deadlines and failed projects.

Failing Agile is in many ways worse off than a moderately successful Waterfall team and probably have lower project success rates.

  • I agree, but consider for instance a project where the product owners are unavailable virtually all the time and there is a predefined fixed deadline on the project because its critical to demo it on a convention (or anything), and your team is composed by a couple of senior herding a pack of juniors. So, yeah there is no black and white but there are some core characteristics a project needs to have to work well with Agile that doesn't have to do with peoples attitude, right?
    – Chepech
    Apr 2, 2012 at 20:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.