This happens multiple times per day. I’ve found doing nothing to be the only logical solution. The 9am meeting says do X, the 2pm meeting says do Y, and each day those meetings drastically change the direction and don’t agree. The only way to win is not to play.
That’s why you get everything in writing. No change without detailed description of what you’re doing and a written reply stating that yes, this is what they want. Otherwise you’ll be in a constant refactoring treadmill.
That would be great if it wasn’t my boss’s boss, and his boss making all the changes. If they were to put something in writing it wouldn’t matter, they simply change it the next day or tell someone else to change it for them. They view this as being “agile”.
I’m working for a big company and our end-user has a lot of ideas of what features he wants. The only issue is that he changes his mind at the end of each sprint or in the middle of it. I am happy he has ideas for making the work more efficient because at the end of the day that’s the major point of our work, but he can’t lock down a deliverable. We have a business admin that’s supposed to work out the actual work we need to do but this end user both won’t take no for an answer for his idea and won’t stick to his own script. I’d describe it less as a feature creep and more as a bunch of lateral moves and shifting goalposts that doesn’t always amount to something better than the first interation yet it’s still somehow a major blocker. Not only that but the big picture ideas get lost in his own plans and it becomes all about the small things he didnt articulate when I present the work.
Solid change control. I’ve seen so many project come undone through lack of change control. You can only develop with stable requirements and changes to requirements should come with a cost. Without it it’s basically offering unlimited development forever, often on fixed fee contracts too.
This happens multiple times per day. I’ve found doing nothing to be the only logical solution. The 9am meeting says do X, the 2pm meeting says do Y, and each day those meetings drastically change the direction and don’t agree. The only way to win is not to play.
“When you do things the right way, people won’t be sure you’ve done anything at all.”
That’s why you get everything in writing. No change without detailed description of what you’re doing and a written reply stating that yes, this is what they want. Otherwise you’ll be in a constant refactoring treadmill.
That would be great if it wasn’t my boss’s boss, and his boss making all the changes. If they were to put something in writing it wouldn’t matter, they simply change it the next day or tell someone else to change it for them. They view this as being “agile”.
I’m working for a big company and our end-user has a lot of ideas of what features he wants. The only issue is that he changes his mind at the end of each sprint or in the middle of it. I am happy he has ideas for making the work more efficient because at the end of the day that’s the major point of our work, but he can’t lock down a deliverable. We have a business admin that’s supposed to work out the actual work we need to do but this end user both won’t take no for an answer for his idea and won’t stick to his own script. I’d describe it less as a feature creep and more as a bunch of lateral moves and shifting goalposts that doesn’t always amount to something better than the first interation yet it’s still somehow a major blocker. Not only that but the big picture ideas get lost in his own plans and it becomes all about the small things he didnt articulate when I present the work.
It’s getting pretty frustrating.
Solid change control. I’ve seen so many project come undone through lack of change control. You can only develop with stable requirements and changes to requirements should come with a cost. Without it it’s basically offering unlimited development forever, often on fixed fee contracts too.