Being efficient - eliminating waste - does not inherantly make one more effective in responding to changes in the business environment. It certainly engenders responsiveness: since I have a more precise sense of where I'm at, I can more precisely determine what and when I can implement a reaction. But there's a difference in (a) being able to respond and (b) being aware of the need to respond and formulating an appropriate response. The latter part - awareness and solution shaping - allows an organisation to effectively capitalize on operational responsiveness.
To be responsive to our environment, we need a high degree of "situational awareness." This means we need to be very aggressive in looking outward, developing an opportunity radar and knowing how to read / interpret / shape / prioritize what it tells us. Efficiency is, by definition, inward looking: all well and good making those Model Ts for pennies until you determine that the market doesn't want to buy Model Ts any more.
To mature our situational awareness, we need to focus on business requirements management. (Of course, arguably we're not generally very good at managing requirements, but for now, let's focus on our aspiration.) There's an ideal state of Agile maturity where requirements are captured as expressions of business functionality that provide value, with each requirement globally stored and prioritized (and re-assessed) in near-real-time. If we have transparency of operations and integrity of completion supplementing well-formed and prioritized requirements, we're not only looking outward but we have aligned the entire organisation - not just development, not just IT - in so doing.
This uniformity is important. It doesn't take much to make a development team hyper-efficient, at least relative to it's peers in just about any silo'd organisation. This is every bit as much disruptive (if not moreso) than having an inefficient delivery organisation, only now you create a queue of unused functionality: feedback loops lose timeliness, organisational memory is malformed or lost as people move or simply leave. This, in turn, simply relocates the organisational (stationary) inerta and organisational waste by creating a stockpile of largely unused capital assets.
In sum, a hyper-efficient development capability buys nothing if you don't have the business capability to properly consume it: it's not sustainable, it's disruptive, it's wasteful. It's also potentially damaging: being hyper-efficient without situational awareness makes you an over-caffinated, high-strung, hypersensitive development shop with a massive inferiority complex in a destructive relationship with your customer/business partner.
So efficiency is a goal, but let's not lose the wood for the trees. How requirements are shaped, communicated and prioritsed provides IT a critical external view that operational efficiency alone does not. Effective requirements management enables you to do more than just respond, it matures your situational awareness, letting you to take informed decisions about what and how to respond. It also brings the business and IT into the same structure of execution, creating alignment and partnership (as opposed to a subservient relationship of one to the other) in a social system of peers. That, in turn, engenders organisational cadence.
