Now _that_ is a good question. Most agile systems are designed to insulate management from the volatility inherent in software development (and to tamp it down

Now _that_ is a good question. Most agile systems are designed to insulate management from the volatility inherent in software development (and to tamp it down a little bit). They aren't really designed to exploit the positive variability. 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.