There is a strange phenomenon common to software development projects that shows its ugly head time and time again in a developer's career. It is a phenomenon that at worst will destroy a project (and sometimes a company) and at best will result in disgruntled developers. This phenomenon of which I speak is called "buy-in".
To clarify, I'm not referring to the traditional sense of buy-in, where parties involved in a decision not only agree to that decision but provide their support for that decision. Instead, I'm referring to "buy-in" in cases where a single party (usually in management or some other decision-making body) makes a decision and then applies heavy pressure to attempt to get the affected parties to agree to and support that decision. Thus, "buy-in" can be considered a form of fake or faux buy-in.
This problem usually manifests itself in the form of scope creep, schedule changes, or unpopular architectural or business changes. If you've ever been asked to 'take on one more thing for this sprint' or been pressured into fitting your development estimates into a particular prescribed timeline, then there is a very good chance that you've experienced a form of "buy-in". It seems as though the primary reason behind management striving for this faux buy-in is either some lame attempt at 'rallying the troops for a common cause' or an attempt to make it more difficult to pin blame on a specific person (after all, 'the team bought into the decision').
In any case, this sort of thing is not healthy for a development team. True buy-in is healthy since the team is involved and committed to something that they believe can be successful. "Buy-in" is unhealthy since it is something that the team does not believe can be successful or can only be successful via death march conditions. An unmotivated and overworked team is not a recipe for success.
Folks, be cognizant of when you are being asked for your buy-in to a decision versus being asked for "buy-in".