The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ...
When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow".
Though I see a benefit in using this when doing prototyping and/or proof of concepts, I fail to see any value when doing real (operational) products which could (and should) be defined.
Yes, but you don't know, and have no experience in, the methodology we're using here.
Then it is up to him to explain the process to you - and you should be able to challenge every assumption, logical fallacy, incorrect belief that he comes out with. If the process is so strong, he should have no problem with you questioning it.
This is something I hear often. It's the idea that agile means you can skip the requirements gathering phase altogether. That is not, and never has been, the case. You still need a rough idea of what you're going to build. And it's your responsibility to work, with a representative of the client, to determine at the start of each sprint, what you are going to deliver. That means that they have to have provided enough detail going into the meeting to work out the rough shape and size of each task.
Even more: Get everything out of the way you can. Your team has to know enough of the architecture and the technologies used so that you can assign them tasks that tell them what needs to be done, not how to do it.
In sprint planning I want to define tasks like this:
We need a new entity named <whatever> that has the following properties: (list), possibly some reference to the requirement documents.
Also, we need a data access object with data access methods to cover the following requirements: (another list of references to the requirements and possibly some elaborations)
No need to lose a word about how to do that, where to place these objects or what technologies to use. My boys know that before writing the first line of code and there probably will be more assignments like this coming their way.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
Actually, and with mixed but increasing success, I try to explain to the client* what they need and how they need it. They're a clue-less lot and if I didn't (or they just don't want to listen) then the effect is much more like what you've experienced.
Interestingly, word of mouth (?) has it that IT knows what it's talking about when it comes to IT. Imagine that!
* Client as in defining users as these are in-house users.