Words have meanings, or they are useless. So, let's define "agile". It doesn't mean "apply a label to any process that you already have". So, where do we find a definition for agile? Probably the best candidate is the Agile Manifesto. But there's not much concrete process there, so now what?
I worked in an agile (and, in fact, XP) environment for a while. The rule there was that the product manager owned the decision of what stories went into the project, but the technical team owned the estimates. That's kind of agile-y (we're doing stories and estimates, yay for us!), but it's also just good engineering management.
If you're in a situation where "Feature X has to be done this sprint because it's already been sold to (Board|Client|Investors|Other Dept)", you're in trouble whether or not you call your process "agile". The trouble you're in doesn't have much to do with whether you're agile or not, either - it has to do with management that doesn't listen to engineering reality. (However, it is a violation of at least one of the principles from the agile manifesto - sustainable pace.)
> So, where do we find a definition for agile? Probably the best candidate is the Agile Manifesto. But there's not much concrete process there, so now what?
So, now we recognize that "agile" doesn't describe the elements of a software-development process, it describes a set of priorities which are used for determining what process is adopted, and how the processes adopted are applied, in a particular organization (a set of priorities which specifically calls for consideration of the particular people involved and how they particularly interact.)
One of the principles of the Agile Manifesto is "People over process". While that doesn't mean process is not important, it does mean people are more important. Whatever your process is, it should be focused on people, working code, customer collaboration and the ability to respond to changing requirements. Even if you try that, it's still possible to have a process that does these things badly. But I still have to see someone argue that these principles themselves are a bad idea. (Well, responding to change can be harmful when driven to extremes.)
Scrum is the most process-oriented process that's still pretty agile. But one of the most essential aspects of it is that you refine your process based on how it works. In an organization with multiple Scrum teams, eventually every team will have a slightly different way of doing things, because that's what works for them.
Fair enough. But that means that the complaints about agile don't really have much to do with agile, they have to do with bad processes that are trying to implement agile. (Scrum is more concrete, though, and can be more validly criticized or defended without as much confusion over the definition.)
> But that means that the complaints about agile don't really have much to do with agile
Well, yeah, that's usually the problems with complaints about agile -- they aren't about agile, they are about a specific set of processes (usually ones developed, adopted, and applied by an organization not applying the principles in the Agile Manifesto) which that particular organization, or the consultant selling them, called "agile" as a way to hook on to the popularity of the buzzword.
> Scrum is more concrete, though, and can be more validly criticized or defended without as much confusion over the definition.
In principal, sure, Scrum is subject to process-based criticism, although lots of criticism of Scrum are about "what I've seen organization X, that claims to be using Scrum, do" rather than "the framework defined in the Scrum Guide".
I worked in an agile (and, in fact, XP) environment for a while. The rule there was that the product manager owned the decision of what stories went into the project, but the technical team owned the estimates. That's kind of agile-y (we're doing stories and estimates, yay for us!), but it's also just good engineering management.
If you're in a situation where "Feature X has to be done this sprint because it's already been sold to (Board|Client|Investors|Other Dept)", you're in trouble whether or not you call your process "agile". The trouble you're in doesn't have much to do with whether you're agile or not, either - it has to do with management that doesn't listen to engineering reality. (However, it is a violation of at least one of the principles from the agile manifesto - sustainable pace.)