[sheepmullet]

> This is unnecessarily cynical.

I think it's pretty clear that these strict agile processes work well for some and poorly for others - some people do better in a highly structured environment and others do worse - it's a bit like remote work on the other end of the spectrum.

The criticism and pushback comes from the negative experiences devs have had when management pushes a one-size-fits-all approach.

I've been involved in more than 5 failed agile methodology process improvement initiatives. I've seen great engineers reduced to a tiny fraction of their former productivity and seen other "hopeless" engineers get a lot better.

[cbryan]

It's a great process for reigning in "great" engineers that produce a ton of technical debt. It's a fantastic approach for making your engineering team more stable and product delivery more predictable.

[sheepmullet]

> It's a great process for reigning in "great" engineers that produce a ton of technical debt

So any positives can safely be attributed to the new process and any negatives are clearly just the new process shining a light on existing problems.

Gotcha.

And the parent poster was wondering why people were so cynical.

> making your engineering team more stable

Can you expand upon what you mean by more stable?

One of the main selling points to management is it becomes much easier to switch developers between teams.

> product delivery more predictable.

In what sense? And through what mechanism?

It does reduce risk on short term deliverables but that's a very narrow interpretation of predictable.

It's certainly not the case as an external customer - trying to nail down an xp team to a fixed deadline more than a few weeks away is an exercise in frustration.