Does this make sense?
What the picture tells is that you have a trade-off between job-size and uncertainty. The more uncertainty, the smaller the job.
Why is this important?
Normally the unknown-unknown is what bites us. In the unknown-unknown quardrant is where agile traditionally really works, because you proceed in small steps and fast iterations to drive fast and frequent feedback. To uncover the unknowns faster.
However, in a context of low uncertainty, it’s a problem if you make too small steps. You end up treating the unknown-known as if it’s the unknown-unknown. This means unnecessary internal discovery and unnecessary internal dependencies caused simply because too many small jobs are broken out rather than proceeding with bigger chuncks in one go.
Lean start-up is typically faced with high-uncertainty and should proceed with small chuncks
Big, scaled agile projects rarely are like this – bigger chuncks can be cut out and handled in one go. But, for this to succeed you need more structure and planning up-front. It’s simply a pre-condition for success with agile at scale.
If you have high uncertainty and should only proceed with small chuncks, then it’s a question if you sensibly can scale.