Focus on quantity (throughput, velocity, flow) vs quality (excellence, variation, accuracy) isn't so simple, and you can easily have enough of both with a little strategy, but there's an interesting parable I stumbled on (source below) that highlights the value of iteration:
"ON THE FIRST day of class, Jerry Uelsmann, a professor at the University of Florida, divided his film photography students into two groups.
Everyone on the left side of the classroom, he explained, would be in the “quantity” group. They would be graded solely on the amount of work they produced. On the final day of class, he would tally the number of photos submitted by each student. One hundred photos would rate an A, ninety photos a B, eighty photos a C, and so on.
Meanwhile, everyone on the right side of the room would be in the “quality” group. They would be graded only on the excellence of their work. They would only need to produce one photo during the semester, but to get an A, it had to be a nearly perfect image.
At the end of the term, he was surprised to find that all the best photos were produced by the quantity group. During the semester, these students were busy taking photos, experimenting with composition and lighting, testing out various methods in the darkroom, and learning from their mistakes. In the process of creating hundreds of photos, they honed their skills. Meanwhile, the quality group sat around speculating about perfection. In the end, they had little to show for their efforts other than unverified theories and one mediocre photo."
There's something special about choosing the focus that provides the most useful feedback, and there is also a side effect of being able to show yourself and others your progress along the way.
I think this is one of the most under-appreciated (and now at risk of being forgotten) benefits of agile, just doing more and more iterations. It's often lost now because we don't often have small teams iterating over and over on things. They build a feature for the pile and then move on to another, only to come back when there's an issue.
I think it's a symptom of trying to do to much, owning too much scope or supply chain, but also how we size and scope teams as well. There's an aspect of WIP limiting and cognitive load involved in the scope of our products and how we define the boundaries of domains and capabilities.
We've become victims of how much we can do in terms of breadth, at the cost of how much we can do in depth, and only the most disciplined organizations are ruthlessly limiting that scope to allow for the necessary depth and 'effective iteration'.
It could boil down to this: How likely are we to get it right the first time?
But the real question is: Are you willing to invest in your ability to get it right?
Parable source