As a manager, the trick is to find the sweet spot between chaos and blind adherence to rules. The uncomfortable truth is that there isn't one sweet spot for all cases.
I've run teams where a very agile approach made sense (usually where the dev and users where small in number and very close) and others where a more formal phased approach made sense (usually where we need co-ordination across companies).
The simple fact is that trying to run these types of programme the same way is an exercise in futility. That's not to say that one can't extract common practices that make projects generally better e.g. it's generally preferable to get code into the wild sooner rather than later if you can do it safely, it's just that the "one true path" idea is a marketing concept not an engineering one.
I've run teams where a very agile approach made sense (usually where the dev and users where small in number and very close) and others where a more formal phased approach made sense (usually where we need co-ordination across companies).
The simple fact is that trying to run these types of programme the same way is an exercise in futility. That's not to say that one can't extract common practices that make projects generally better e.g. it's generally preferable to get code into the wild sooner rather than later if you can do it safely, it's just that the "one true path" idea is a marketing concept not an engineering one.