Unfortunately, not all sources of variability are bad. Think about the antibiotic craze as an analogy. It was a major discovery that bacteria cause disease. But it was also a major discovery that certain bacteria are beneficial. Loading up your system with antibiotics 24/7 is actually detrimental to long-term health, even though it's awfully helpful during an appendectomy.
How do you differentiate good variability from bad ones in software development?
Here's a classic example: let's say I have a story card that says "build a feature that lets 10000 customers buy a widget from our store." In most classic agile systems, the engineering team will do their best to understand the customer requirement and see that it's built appropriately.
Now let's say that 0 customers show and buy the widget. Who's fault is this? In traditional agile, it's the Product Owner's fault, not the engineering team.
But exploiting positive variability would say: the effort required to build this feature requires knowing in advance how many customers want to buy the widget. The engineering effort is totally different if the answer is 0, 10, 100, 10000, or 1000000 customers. So rather than build the feature as specified, let's do an experiment to try and assess customer demand first, then build in response to that demand.
That means that sometimes a story will take 10X longer than you originally planned and sometimes it will take 1/10th as long. But in the end, you'll get a better business result. That's positive variability.