I entirely agree - I can bring some experience too. I've been involved in quite a few successful Agile projects. The key is in the management of the process. The target is to provide the system that the customer needs, regardless of what they think they want. One of my projects is 7 years old and still has unmet original requirements because there are always higher priority things that the customer wants us to do that weren't original requirements (and no I don't mean "fix the bugs"). A more traditional engineering process would have delivered a markedly different system, one that was not as useful to the customer. I once watched £100k of my work go in the bin because of a requirements error. Implemented properly, Agile methods stop that kind of thing from happening.
On the flip side, even with the best management, new features are always going to be a weakness and as 100% automated test coverage is a myth there is always an increased regression bug risk. This is obviously going to be felt most in ops and it's really important that a) this is understood by everyone and that b) ops have a priority line back into development so they can kick arse when people drop the ball.
no subject
A more traditional engineering process would have delivered a markedly different system, one that was not as useful to the customer. I once watched £100k of my work go in the bin because of a requirements error. Implemented properly, Agile methods stop that kind of thing from happening.
On the flip side, even with the best management, new features are always going to be a weakness and as 100% automated test coverage is a myth there is always an increased regression bug risk. This is obviously going to be felt most in ops and it's really important that a) this is understood by everyone and that b) ops have a priority line back into development so they can kick arse when people drop the ball.