While I'm now in a very loose shop which has pretty much whatever methodology each developer/user pair find useful, I used to work in a supposed Waterfall shop. I discovered the secret to successful waterfalls from them.

In principle, a user would make a formal Service Request on the appropriate form, getting approval from management on the user and programming side, for the the change. Then a front line programming manager would assign the task to a programmer who would draft a Technical Design Document, which would again be approved all around. Finally, work would begin until the programming side was happy. Then the users would test.

The above sounds like a disaster. Here was the trick. None of the documents were finalized until right before a release (sometimes hours before). This left both sides open to debate and discuss what the request was and how it would be implemented. When testing was going well, the documents would be signed on the way to release.

I suspect that there are shops on the other side, where agile methods are supposed to be in place, but they aren't really used in practice. So, I don't let the terminology or stated policies affect me. What matters is how things work in practice. Is there really a rule that you can't talk to users after they deliver their request? Do you really have to tell someone in advance exactly what you are going to do?

Phil