Let’s analyze this view…
First, let’s get Kanban out of the way: Kanban works fine whether you are project-focused or product-focused.
Then, let’s talk about the project-focused part. On the left, waterfall — and more broadly, the old way of thinking — is happy to have a big batch size. People on the team will even justify it as a good thing: after all, since they are driven by a contract, the only thing that matters is the complete, final delivery. What’s the point of partial deliveries?
On the other hand, project-focused Scrum will happily deliver during each iteration of the project. Yet, the team will probably happy delivering maybe once per iteration — supposing that the iteration length have been properly chosen. Once the team is there, why improving? Isn’t it working good enough?
Please note that this is not necessarily a bad thing in itself… If the team is indeed leading a project, then budget and time are constrained: it may make sense not to invest more into a better delivery process, given that the project is short-lived.
Now let’s have a look at the project-focused part. On the right, the team has many incentives to keep going faster and faster ever.
While project-focused Scrum teams will have a natural tendencies to stick with “just enough” delivery speed, product-focused Scrum teams will tend to continually improve their delivery pipeline.
On the left, a team with a very big batch size while being product-focused will feel completely constrained by their delivery speed, feeling that nothing gets accomplished. The team will want to fix that, hopefully moving to the right side of the scale.
There, too, being product-focused brings many incentive to improve the delivery capability of the team.
Product focus: the ultimate enabler of continuous improvement?
Is there any good reason not to iterate fast?
Other than legacy code, technologies and organization which are getting in the way? Which also could all be fixed, at least in theory?
The power of faster feedback