Re: You keep using that word. I do not think it means what you think it means
The manifesto is indeed very different from its application, but that doesn't necessarily mean it's good. Here are a few parts of it which I have seen go badly:
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Sorry for the repetition, now I have to take some separately.
"Working software over comprehensive documentation": Yeah, everybody seems to love this. You know what happens? I have to be your comprehensive documentation when people email the developers asking for help (I don't know if not having any support staff is part of the company's agile plan or just something they do). I'm not calling for a weighty manual documenting every line or giving a paragraph on each option, but document what it does and how and keep that up to date. If the software works and nobody other than the devs knows how to use it, it's about as good as it having a bunch of bugs.
"Customer collaboration over contract negotiation": If you have a good customer, of course. If you don't, get that away from me. A bad customer can ask for lots of things that aren't going to work. Whether that's just adding useless features, complex extra requirements at the last minute, or even asking for the impossible, it always happens when you've already done the core stuff. The requirements should be set forth at the beginning, so you can decide whether you can do them. Asking for some minor changes halfway through is fine. Asking for a major feature halfway through is painful but sometimes there's a valid reason. Asking for an overhaul about 90% of the way through is something from which the devs need insulation. Which brings us to
"Responding to change over following a plan": Again, it depends what the change is. Maybe something previously required isn't needed but a new thing is. Respond to that change. Maybe someone had a good idea and you can implement it without pushing out other important things. You can respond there too. But in general, you should have planned for most of the likely changes and you should follow that plan. In that case, you don't have to respond to change every day, meaning you can give the appropriate consideration every time an important change happens. The way management usually messes this one up is to consider anything they decide to be a change to which the developers need to respond. They started caring about something on Monday, so now the devs have to drop everything for it. On Tuesday they don't think it's as critical as they used to, so now it needs to be dropped again. That attitude is appropriate only for bugs which have been newly discovered or found to be more damaging than previously thought. Otherwise, it's a method of moving very fast and going nowhere.