> What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority.
I would say this is pretty standard, and personally I really hate it. I think it works well if you want to prioritize hitting a date above all else, especially with a junior team or in a "low trust" environment (cheap off-shore team). But for other metrics, I don't think it's great.
In my experience it results in a lower product quality, people do the bare minimum to finish a ticket and throw it over the wall. Since tasks are so split up, things don't end up connecting coherently. The problem you're trying to solve for the user gets completely lost and you end up with a bunch of features that don't necessarily make sense.
In my opinion, it also really sucks for job satisfaction. It makes me feel micromanaged and have 0 autonomy. But I have met people that love it, their reasoning being "I can just zone out and write code without having to think about other things". So that's more of a personal thing.
> If Development doesn't deliver business value because Product can't stick to a coherent feature strategy, that's Product's fault, not Development's.
While you might technically be right, that's not a great attitude to have.
I'm not arguing that Product should sit high and mighty and refuse to listen to Development. Great ideas can come from everywhere, including Development, of course. But understanding what ought to be built, at least for functional requirements, is fundamentally Product's job and their decision.
What great teams do is that they have a Product guy sit on the same team as Developer guy(s), precisely to avoid the malaise you describe.
I would say this is pretty standard, and personally I really hate it. I think it works well if you want to prioritize hitting a date above all else, especially with a junior team or in a "low trust" environment (cheap off-shore team). But for other metrics, I don't think it's great.
In my experience it results in a lower product quality, people do the bare minimum to finish a ticket and throw it over the wall. Since tasks are so split up, things don't end up connecting coherently. The problem you're trying to solve for the user gets completely lost and you end up with a bunch of features that don't necessarily make sense.
In my opinion, it also really sucks for job satisfaction. It makes me feel micromanaged and have 0 autonomy. But I have met people that love it, their reasoning being "I can just zone out and write code without having to think about other things". So that's more of a personal thing.
> If Development doesn't deliver business value because Product can't stick to a coherent feature strategy, that's Product's fault, not Development's.
While you might technically be right, that's not a great attitude to have.