I've heard lots of misconceptions about the work of design over the years. I bet you have too.
"Design takes time and can't be estimated."
"Design is slow."
"Design makes things pretty."
"Design doesn't need to be tested."
These misconceptions place design in the realm of magic, as if it can not be measured (it can) nor estimated (it can). The term "design" also may be relegated to the visual design profession - as if to say that visual design is easy.
In part due to the popularity of Agile and the fact that it was designed for software development ill-informed teams may view design as a bottleneck, a special snowflake, or an activity unrelated to development. This may be predicated on the notion that only certain people can design things.
Design is only a bottleneck if you make it that way through organizational structure, ignorance, or both.
Agile can both help and hurt
One proposed remedy to a perceived lengthy design process? Agile. The Agile framework has amassed a reputation for speed. (Ideally that reputation would include other things, but this is primarily what I've witnessed.) Now, Lis Hubert's article is right in the broad UX sense - designing a product, service, or what-have-you at a strategic and enterprise level is not well-suited to 2-week sprints. It's kind of silly to think it is. But Agile isn't about creating an entire product in a sprint; Agile is about shipping something. That should resonate with UX folks because we want to get something out there to get user feedback on (right?) Thus, we work alongside development in the same team to deliver something. Yep, pair developers and designers.
The important piece of UX in Agile is that it makes things transparent. Some design work does take time, but instead of a nebulous "whenever designers finish their work..." mentality, there are numbers on it. What would happen if a company never estimated development work? Yeah, I doubt that'd be good.
Make no mistake: Agile UX is about delivery. Research and similar activities can absolutely be done in this framework, but - this is key - the scale and scope will be markedly smaller. It is possible to take learnings from small research and scale them up to something bigger... say, a UX strategy!
If UX strategy is implemented at this scale, I doubt Agile UX by itself can address it well.
Agile UX is wrong for UX vision and strategy
UX strategy, I believe, sits above this. Learnings and work done within Agile teams and sprints roll up to a broader set of goals aligned to KPIs. (Note: you can't do this work if design is seen as an exercise in magic, because then it is seen as without value.) This strategy may be expressed in maps of how design components, patterns, and practices contribute to the bottom line (or top line, or....) It requires a dose of advocacy and education. This all is a key part of the work of a UX strategist.
Admittedly this part of design is a little slower because it's integrated with business models, technical architecture, and product portfolio definition. It's not quite "big design up front", but it is necessary to ensure there will be experience-related goals in mind during the overall delivery process.
This portion of the work can also be built on your standards: branding, interaction, UI, visual design. This can make the overall creation of assets and design work a lot faster.
Coupling
A last note: I firmly believe that design and development should be coupled as closely as possible at both strategic and delivery levels. Companies tend to get the UX + delivery part right faster because of the classic "UX is deliverables!" problem. It's different when strategy is in play, because in some companies the value of design at that level may or may not be realized. This is the fabled seat at the table... but it doesn't just materialize because we want it.
Through creating value and tying it to what matters to the business, UX and design can lead those conversations. But it's not going to happen when your designers are solely tasked with delivery.