If the best argument they can come up with for the process is "because that's how agile development is done" it's because they don't actually understand the process but that doesn't necessarily have anything to do with them being certified or not.

That's my point. They paid money to get "certificated", get jobs as project managers or scrum masters but have no idea how development or agile actually works. I've have come across a lot of these types of people.

(And, in case you're interested, "certified" is the standard term. In case you're not interested, my apologies for bringing it up.)

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that?

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual?

Continuous attention to technical excellence and good design enhances agility.

And takes time. Ops, sprint's time is over. I guess that refactoring can wait.

The best architectures, requirements, and designs emerge from self-organizing teams.

Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership.

There are definitely good ideas in this manifesto. Ideas that have been applied for years, before even the manifesto came to be. Some others are just wouldnt-it-be-nices.

Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them.

There is no point in delivering software which doesn't meet customer requirements. If changes to software are required because it doesn't meet requirements, pretending otherwise solves nothing. Agile processes make it easier to cope when these changes happen, and accept that if change is required then other constraints have to move – such as deadlines.

Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that?

Most tasks do not require 'longer attention spans', whatever that means. Almost literally every task can be broken into smaller parts with minimal effort, helping to expose implementations to scrutiny at earlier stages.

And while Scrum traditionally has a fixed sprint length, there's no requirement to follow that to the letter. If your constraints are such that it doesn't work, then adjust the process to suit.

But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource.

No – Scrum is about the team of individuals. Depending on a single individual is obviously stupid regardless of what process you use.

The only remotely close way of doing this is turning everyone into cogs in a machine.

Not at all true. A nice sustainable pace is reasonable for any team of skilled professionals. If you are not achieving it, your team is broken.

And takes time. Ops, sprint's time is over. I guess that refactoring can wait.

And pretending otherwise does nothing. Make refactoring a requirement for completion, and you will avoid this problem.

What’s the point in delivering something both you and the customer know is wrong, when you can turn around and fix it instead? The point is delivering something of value instead of delivering something you agreed upon half a year ago.

Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that?

The text says "couple of weeks to a couple of months", not 2/3 weeks. If a task requires a longer attention span than two months, you should probably break it down and deliver something of value earler on. As you say yourself: "the market won’t wait for you to implement them".

To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource.

What a nice way of motivating people. Every person in a good team is of big value, and cannot easily be replaced by anyone else. Creating a good team requires thought and planning. If Scrum is about diluting the individual, then Scrum is far more wrong than I originally thought.

This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual?

When you motivate people, and give them tasks they like, they tend to perform their best. Turning people into cogs in a machine, as Scrum seems to like, is not a good way of motivating them. As the manifesto says: value the individual and motivate them, and they will get the job done.

And takes time. Ops, sprint's time is over. I guess that refactoring can wait.

And that is why you don’t care about sprints. You do one task, preferably as small as possible, and deliver it when it is done. That’s it. I have never understood why I should spend loads of time planning what I should do the next N weeks, when I can just do it instead.

Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership.

Having strong leaders around a self organizing team is not necessarily problematic. Self organizing teams are more about giving the team freedom to work the way they want. A manager or leader can then contribute by removing obstacles and ensure the team has everything it needs instead of micromanaging everything.

The most important part of The Agile Manifesto, in my opinion, is "Individuals and interactions over processes and tools". If you care more about the process than you do of the people in the team, you are doing it wrong.

EDIT: formatting.