It's even worse. You not only need to deliver _before_ the requirements change, but _so_ the requirements can change.
The way I think about this is that you are always playing with 2 variables--latency & throughput. So much talking & thinking goes into talking about throughput, but in the exploration phase improving latency creates value, even at a cost in throughput. We don't have orthodoxy about how to manage or engineer for latency. Not yet.
It's even worse. You not only need to deliver _before_ the requirements change, but _so_ the requirements can change.
The way I think about this is that you are always playing with 2 variables--latency & throughput. So much talking & thinking goes into talking about throughput, but in the exploration phase improving latency creates value, even at a cost in throughput. We don't have orthodoxy about how to manage or engineer for latency. Not yet.
I'm on board with your use of latency & throughput. The closest I found so far is No Boilerplate's video on "You're doing agile wrong":
"If the cost of failure is less than the cost of planning, you MUST NOT plan."
Link: https://www.youtube.com/watch?v=9K20e7jlQPA