> However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves.
Is the author an Agile coach? This is the classic response when people observe that Agile has failed to transform their team: you're doing it wrong, the problem is you. When systems seem good in theory but tend to fail in practice, you should just try to learn what you can from them and move on to the next thing.
No, it really is true. Agile is widely misunderstood. The way scrum is implemented in 90+% of the cases is a complete mockery of what it was supposed to be. A lot of coaches completely miss the mark as well.
And the fundamental problem is that agile is completely incompatible with the way most enterprises are built. A truly agile team talks to the users of the product, and they have complete control and responsibility over the development process. That just doesn't happen because managers want to manage, and as much as developers would like freedom, they'd often rather not have the responsibility.
A lot of us were doing some form of agile before someone came up with the word agile.
I'll give you an example:
Imagine the process of creating a retro video game.
First, you might write a function that clears the screen.
Next, you'll get something simple drawn. Maybe just a simple block.
Then you write a function that allows you to move the block with a controller.
Then you swap the block with some sort of character animation.
Next, you'll write a routine to draw girders.
Then you'll implement gravity.
Etc., etc. You'll just keep iterating until you have a well-balanced and engaging game.
That's agile. You may have had a lot of the game designed beforehand, or none. In fact, you could even create the game design documents with the same method. Make a quick first draft, get feedback, make adjustments, and repeat. And then keep going back to it whenever you notice something doesn't work or some better idea comes along during the course of development.
Originally, agile had nothing to do with rigid meeting schedules. Or "adapting to changes," or whichever buzzwords people like to throw around.
Electric cars have electric motors. So if you attach an electric motor to an F150 without removing the gas engine, you have an electric car. And it has terrible gas mileage.
> a complete mockery of what it was supposed to be
I started programming long before "scrum" or "agile" or even "XP". One consistent observation I've made around every methodology that comes along is that management manages exactly the same way they used to manage after they roll out the methodology as they did before the methodology.
Honestly, 99% of the time people are doing it wrong. People are either too strict with it or too "loosey goosey" with it.
*EDIT* It doesn't have to be correct, it just has to work for the people on the team. If it works, then use it, if it doesn't then change it. That's agile.
If people can only ever get into the goldilocks 'not too strict, not too loose zone' 1% of the time, then it the process is by default not fit for purpose in almost any circumstance.
Likely the 1% of the time it works is the rare case that you have a small and exceptional team working together, in which case the project management methodology is unlikely the reason they are working well.
You don't have to, just find what works for your team and use it. It may not be perfect or exactly how it is supposed to be but if it works then use it.
No, they need to come up with that on their own. What exactly "wrong" means? And why do you think you know it better than them? What if they find some better way that you didn't know about? Agile says that it needs to be sustainable also for the sponsors. Show the team that if the sponsor isn't able to sustain the next sprint, there won't be a next sprint. The process is up to them.
That certainly applies to Scrum but agile is more of a religion than a system. It's a bunch of extremely vague "principles" whose meaning is often anyone's guess.
What constitutes agile is basically a matter of opinion.
Is the author an Agile coach? This is the classic response when people observe that Agile has failed to transform their team: you're doing it wrong, the problem is you. When systems seem good in theory but tend to fail in practice, you should just try to learn what you can from them and move on to the next thing.