> Does Agile really not work with large enterprises?

It works well when you can control or bound the expectations of your users. Delivering a gradually-expanding customer self-service portal, for example, is a perfect candidate for agile processes.

However, it doesn't work when the requirements are legal or financial compliance. There is seldom an opportunity to iterate and improve, it needs to be done once and fully by the go-live date. You can't release a small part of a compliance project ahead of schedule because, well, it wouldn't be compliant... Date-bounding makes-up a large proportion of enterprise business logic for this reason.

Counter-intuitively a large enterprise actually needs to be more flexible in its project management and methodology than a small, "agile" start-up. Deploy whichever technique is appropriate for the task, which means you have to have adaptable staff.

Source: having worked for a Fortune 100 that was agile-ising.

Fake agile does not work. Large enterprises come with all their problems in processes, tools, skills, etc. They hear this new buzz word and latch on to it. They take this new thing to their teams and ask them to implement it. And all this while, the upper management just knows how to pronounce the word "Agile"; they have no clue what it means or the work needed to "implement Agile". So upper management is never in a position to help the teams. Most times, management does not want to change the existing tools, processes or grow people's skills. And so agile fails - because people want the benefits of agile without doing the work.

Agile isn't binary in the sense that it either "works" or "doesn't work". Do enterprises adopt agile? Yes. Is it not "true" agile? Most likely yes. Can anyone equivocally determine what true agile is? No.

Agile is what you make of it. The biggest thing holding back a "by the book" agile scrum implementation at enterprises is budgetary process. Business people, who own budgets, have an extremely hard time understanding why they can't build X for $Y, because there are few agile processes that help them clarify that.

We are around 200 and it works really well here. We must be doing it wrong because things are going better since we switched to agile 5 years ago.

There is a plague of fake agile out there.

People buy cheap outsourced development written to spec. People say they want all the benefits of agile but that means embracing risk in order to access the potential of their coders in a real agile management environment. In fact they are happier missing out on a great implementation if it is cheap and timely.

So there is a lot of agile bullshit out there, looking agile-ish but really being paranoid micromanagement by cheapskate philistines making crap software, managed on kanban boards by people with certifications.

Real agile is hard. Maybe impossible for most projects. But being fake agile avoids grappling with the hard problem of how to get the most out of your software development with the resources you have.

The biggest problem with agile is it seems to eliminate software planning. It's a stark contrast to waterfall where execs and product managers spent months designing things leaving no time to actually implement them. Agile swings wildly the other way, some product manager writes a few user stories on what he expects the software to do and off you go writing code.

I've never been an an AGILE project where architects and managers followed through with designs or documentations. The halfway through the sprint you'll get clarifications of specs if you're luckly. Something needs to be redesigned? too late, you're doing another sprint next week.