In the agile usability forum, Steve Gordon astutely observed:

“Making these choices is a business decision that requires balancing strategic and tactical considerations in the specific context.”

i agree. imho, one of the roles we, as software professionals play, is to provide the business with some “cost” information and some potential alternatives. when a specific feature idea comes forth from the business side, we are to provide cost (in terms of effort, schedule, and even downstream ramifications). We can also discuss various variations on a theme. For example, many times the development team might say: “Well, providing X is expensive and would take 6 months. However, we could do Y — which seems like it would achieve nearly the same result — for a much smaller cost, and have it done in one month.”

Talk is (usually) cheap(er) than one-way (non)conversations.

That is, a non-agile “Company A” might simply spit out a new feature set idea in an email. Then, the dogmatic development team spits back a single answer (it will cost X). Business chooses not to go forward. Meanwhile, competitor B implements Y and drives Company A to lose business and go bankrupt.

Or, non-agile Company A accepts excessive cost X. Company B does Y, gets it done sooner and eclipses Company A’s much later release of an only slightly better feature X. Company B makes more money, Company A never recoups the cost of feature X.

Talk is cheap — and that’s a good thing when it comes to working as a team for a common goal. Company A did not have a discussion, and it cost them dearly.