That incremental goal is not mutually exclusive to kanban. The difference is whether you are stating at the beginning what goal you will hit, vs just working towards that goal. It's the same thing, one creates pressure to hit inaccurate estimates, the other just marches towards the goal.
> Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure
Why is that? Scrum has the same backlog.
> since there is no opportunity to reflect on the larger picture
Why is this the case? Kanban often says that you talk about retrospective items any time they come up. You then even can re-prioritize such items right when needed, meaning you solve todays problem today, not tomorrow. Retrospectives in scrum can often come too late (and personally I've never really seen them work well, too little, too late, and often compete against 'business' priorities that always win out).
> And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong.
Kanban is less susceptible to priority inversion. You keep the highest priority at top, it is evaluated more often, and you pull from the top. Why does this mean that months can go by? Why is that any more the case than say scrum where you are encouraged to fix priority for weeks at a time?
> As I said, there are appropriate times to do kanban, but the situation you describe is not one of them.
I think the burden of proof is on you to state places where scrum uniquely bests kanban. The statement that kanban is best for places where ad-hoc work comes in constantly is a case where scrum spectacularly fails. For regular project work, kanban can be a great fit (I'd say universally better than scrum, since planning is just complete BS. Kanban is often little more than scrum without the planning sessions and with far more frequent prioritization, and you get to keep all of the same retrospective & estimation tools)
I answered your general point in a separate reply, since others brought up the idea of continuously planning and retrospecting in kanban.
But I'm confused by this statement:
>planning is just complete BS
To me, planning is where design meets reality. Planning involves several activities, but probably the most important is prioritization. I'm curious why you think that prioritization happens more frequently in kanban, where the convention is to simply take the next task off the stack. Are you saying that every time someone takes a task off the kanban backlog, they independently re-prioritize the entire stack? Or do you have regular re-prioritization sessions with the team? If it's the former, that seems like a lot of overhead and opportunity for conflict and misunderstanding. If it's the latter, how is that really different from regular sprint planning? Because surely, as part of the prioritization, you would also consider things like estimation of difficulty and risk.
> Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure
Why is that? Scrum has the same backlog.
> since there is no opportunity to reflect on the larger picture
Why is this the case? Kanban often says that you talk about retrospective items any time they come up. You then even can re-prioritize such items right when needed, meaning you solve todays problem today, not tomorrow. Retrospectives in scrum can often come too late (and personally I've never really seen them work well, too little, too late, and often compete against 'business' priorities that always win out).
> And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong.
Kanban is less susceptible to priority inversion. You keep the highest priority at top, it is evaluated more often, and you pull from the top. Why does this mean that months can go by? Why is that any more the case than say scrum where you are encouraged to fix priority for weeks at a time?
> As I said, there are appropriate times to do kanban, but the situation you describe is not one of them.
I think the burden of proof is on you to state places where scrum uniquely bests kanban. The statement that kanban is best for places where ad-hoc work comes in constantly is a case where scrum spectacularly fails. For regular project work, kanban can be a great fit (I'd say universally better than scrum, since planning is just complete BS. Kanban is often little more than scrum without the planning sessions and with far more frequent prioritization, and you get to keep all of the same retrospective & estimation tools)