There is a very wide spectrum from the mythical evil-waterfall-monolith to a perfectly lean and utterly agile continuous delivery of value. In fact, scratch that, it’s not really a spectrum. It’s not even a consultant’s two-by-two matrix. It’s a complex multivariate systems-view that is needed, and fighting religiously for absolutes doesn’t help improve any of the real trials and tribulations on the front lines.
Come on – Don’t try to enforce one-size-fits-all agile or lean or kanban. Instead, create your own adaptive center of excellence from any approaches & tactics, new or old that can provide insights into the variety of techniques that can be adopted for each situation.
For example, a really well-formed support team could move to kanban and get rid of most of the scrum ceremonies. Likewise, not every multi-scrum-team product needs a cadence of Program Increment planning – but (be honest) some do.
The bigger the organization, the more important it is to be practical in your approach to change you’re passionate about. Self-check: Are you asking for a change that makes the organization easier to work in, better at serving the customer, or more sustainable as it grows? Great! Don’t let fundamentalism get in the way of the spirit of agility and the purpose of your organization.
….Especially if you are an enterprise that is “mid-transformation”.
In fact, rather than worrying about drastically changing to a new and elaborate process with all the answers (which will definitely FAIL), there are just a few underlying principles that will help evolve an enterprise toward lean agility:
1 – Each time you make a business decision, make one that makes it faster to validate your assumption than if you hadn’t made a decision at all.
Anytime you make a decision, make it easier to recover from it as an organization if you are wrong than if you had done nothing at all.
2 – Challenge the biggest assumption first, working to disprove one hypothesis at a time
3 – Each time you touch code, leave it simpler to understand and easier to change than if you hadn’t coded at all
4 – Create an environment of psychological safety for your people
5 – Do no harm to the user
Keener Strategy 
I think the most important rule when deciding to introduce Agile is to remember your company is not the companies you’ve heard about when reading about Agile. Do not try to fit your company to Agile – fit Agile to your company. Choose the methods or apps you like and the ones that really work – for you, not for other companies, your company’s what matters. I’ve gone through many, staying with the simplest one – a tool looking like created for children, Kanban board. Not as childish as this one https://pl.pinterest.com/pin/517491813405747658/ 😉 but still nice and friendly. I have friends who use FDD or Cleanroom and they’re satisfied – every company is different.
Maya – Very true. It’s nice to get ideas from other companies, but we shouldn’t confuse their tools and processes with the culture that created them. That’s why my “simple rules” are focused on gaining agility over time. The “heroes” of agile continue to improve based upon these rules, not because of their processes or tools.