One of the things I've learned, from designing products and systems for a wide variety of companies over the years, is that the initial expectation is that you will come in and churn through a few requirements each day; putting each brick in place and finally arriving at a complete product. This is usually done once they realize that there is a need for UX and isn't always done with a lot of forethought. While this is certainly a proven way to get a job 'done', it's just as likely to produce the least innovative result. In many cases delivering little more than a reprogrammed/refreshed version of what they might have already had. Being able to fundamentally re-think how a user interacts with a system means understanding both the system and the interaction as a whole, not in a step-by-step basis. We live in a three dimensional world, not a one dimensional one; so why do companies naturally approach their UX as if it always follows a one dimensional 'wizard' like flow?
Some companies prioritize the guaranteed and predicable method this gives you because of their size and the amount of money they invested in the project in the first place. In other words, they're so afraid to fail they forget the true meaning of innovation. There are of course other reasons for this approach, like tackling the limited set of requirements that business has already signed off on and the immediate need for delivering UX artifacts to the developers in waiting. (Whether development has other building blocks they could be working on is a separate discussion.)
This would probably explain one of the reasons smaller companies (or even more often, start-ups) seem to be able to innovate so easily while others try and try again to replicate the same results. Leading to the frequent need for the larger, more established companies, to acquire the smaller ones for their innovative solutions to help put them back on the fast track.
Many larger companies have started to adapt the Agile Development Method in order to try to capture the magic that allows smaller shops to bring better stuff to market faster. While it works for getting stuff done, I have yet to see a case of pure Agile Development of a multi-million dollar project leading to an innovative User Experience without some major advance planning of where you want the UX to go. You either have to plan ahead or you will no doubt end up with some major UI rework at the end, which often forces a project to go well over-budget.
Some companies of course are more hampered by an existing customer and partner base so vast that it has little choice but to keep the status quo while trying desperately to also add innovation to an already complex suburban sprawl like environment. This complexity aside, it is always possible to look to the future and set your company on a path to more innovative and up-to-date customer experiences.
So, how does a larger company innovate and still stay on the safe path?
The solution that most often works for me sounds quite simple. UX is holistic; so designing as you code isn't really much of a UX strategy. Since much of the perceived bottleneck (or pain-points) of a UX team is producing the wireframes themselves, especially in Agile, you need to change the understanding of wireframing. It's not something you do to merely illustrate where buttons and info go on the screen. If that is all you're doing, you're doing it wrong; well, at least in the context of User Experience.
When it comes to wireframing, if you truly want to be "agile", you should sketch out the general functionality in advance of development in an iterative way. The goal being to understand the users and the system goals in context of the whole experience. If you think of your wireframing stage as a mini-"Agile" design phase you can more quickly visualize and test out the intuitiveness, simplicity and complexity of the system cohesively. This allows you to more quickly verify the fundamentals of your UX in the same way that you test out your code at the end of each sprint.
In most cases, the up-front iteration on your wireframes is more than made up for by avoiding the constant daily struggle of trying to solve UI problems (and later re-work those same things) within your scrum teams. It is also an extremely efficient way to manage your UX Strategy and User Interface when you're dealing with several development teams working on different parts of a much bigger project.
