Sure thing Johanna:
Here is the DevOps Framework deck: https://docs.google.com/presentation/d/e/2PACX-1vRrmMinQrHJeWJjjsCzXyo8JwAX32HIjzY7hx6IiLQHszZgZtt8kPiFOpmBH00dQ0VOBkunta_AYZDk/pub?start=false&loop=false&delayms=3000
And here is the Business Agility Deck: https://docs.google.com/presentation/d/e/2PACX-1vSOqw2VHgJJGc-dlVKRcabGgUJnCCnOnD9m8Hj0wHoTz3b_4VQHdeaAZdlcnl0lFy8spSDFH46MMJCs/pub?start=false&loop=false&delayms=3000
To the second question, yes. It’s the personification of ‘who moved my cheese’. Mike McCalla here did a nice write up on “Inviting vs. Inflicting Agile” and I think there was even a podcast we did on it. The point being, a lot of the enterprise, or even personal, change that is introduced in a lot of what practitioners do, is potentially threatening to those impacted by the change. I have not found a silver bullet to ensure that threat is eliminated, but to mitigate I invite folks to the conversation. in the framework talk I go into how starting small with lighthouse projects is extremely successful. It allows for a gradual change, and creates outside curiosity and (when done very well) excitement to be part of the new way. In the Business Agility talk, I go into creating a better interface with the business/product managers. Often, we default to Jira or slack as the interface and that is an artificial construct that gives an external appearance of invitation to the change, but is ignorant to the human side of change.
Not till we appreciate the stance of the non-technical folks impact to change, and find ways to introduce them to the change like lighthouses and interfacing better, will we ever unlock the real hyper-speed we talk about with DevOps, Cloud, Agile, Lean, etc. But the beauty is this, it works both ways 
Only focusing on the business operations, product management and process aspects of agility while ignoring engineering culture has the exact same outcome, just from a right angle to the one you present.