Check and check. There's also my personal favorite: marketing informs the dev team they've just inked a big contract with a tight deadline for features that were never discussed with the dev team. "We kinda told them we already had those features but hadn't released them yet. Can you guys build that real quick like?"
However, recently I read Developer Hegemony[0], which seems to describe a path for IT developers to also have rewarding careers.
My current thinking is that the Agile philosophy definitely contributes both to successful projects and to satisfying careers for IT developers (Agile came primarily from that world of software development) but only when developers and users are equal partners. That generally only happens when the developers are independent consultants who can speak the language of business.
However, I do think that the original signers of the manifesto were onto something. My recommendation for people is, rather than learning an official methodology, that they go and read the writings of the various different signers. Get an understanding of what it meant for them at the time that they signed the manifesto.
Martin Fowler has commented that one of the other names they thought about calling their movement was "conversational software", in the sense that software development process was an ongoing conversation between the developers and the users of the system.
The point I gleaned from the book I mentioned was that (in the general case) the power politics of most IT organizations prevents the development process from every being a real conversation.
As I understand it, many of the signers were independent consultants at the time of signing (or helped lead IT consultancies) and could speak the language of business. It seems to me that perhaps this put them in a more "peer" relationship with the business stakeholders, and allowed the development approach to be more conversational.
This is key.
I've done both and I can't say one is better than the other. I've worked on software products where marketing couldn't figure out how to sell it and kept changing the core functionality. Or where the CEO kept shoving his ludicrous ideas onto development. I've worked on rewarding IT projects where I worked very closely with the users and was very happy to see my work help them perform their day-to-day jobs. I've also worked on slog IT projects where the users had no idea what they wanted and we kept churning.
After 28 years, I ended up preferring working close to the actual users.