Article relies on a non-sequitur assumption that you should work on an entire feature start-to-finish without interruption.
What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority. This is what actually reduces batch sizes. Then deciding to prioritize the work to finish a feature instead of new work for a different feature becomes a matter of discipline, not process. This is important because it allows management to stop throwing good money after bad on features that the business decided that they don't actually want anymore.
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.
> 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 agree with the general idea, but I'm not sure putting development and product in an antagonistic relationship will improve things.
They're different professionals with different ideas of what's important. Someone in product is unlikely to understand the development cost of leaving something half-finished, because recognising it as a maintenance tar pit takes development expertise that can be hard to articulate (as expertise tends to be).
What's needed is close cooperation, not finger pointing.
What management ought to do is to split feature work into tasks of smallest granularity as possible, then schedule only those of highest priority. This is what actually reduces batch sizes. Then deciding to prioritize the work to finish a feature instead of new work for a different feature becomes a matter of discipline, not process. This is important because it allows management to stop throwing good money after bad on features that the business decided that they don't actually want anymore.
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.