So in adopting Agile in a large corp. is it best to go "SAFe" to get buy in at the top, or just a small team on Scrum to start?

I've been doing transformations since 1999. In my experience both have worked. So you work with what you have. If I am given a team, I can grow that into a large transformation. If I have the CEO at my side from the start, I can inspire teams to try new ideas.

But the fastest path is to have an executive sponsor, a budget, and measurable goals that will be used to evaluate the success of the transformation. When I see an account like that, I smile.

As to SAFe, that is a great framework, but not a requirement to get buy in at the top. SAFe is a set of techniques. If the executive is already excited about SAFe, I will use that in the transformation. If the executive is simply excited to see how agile can improve the organization's capability to deliver quality software faster, then I may or may not use SAFe depending on various factors. The biggest of which is: Do they have large teams working on the same product. If teams are independant, they don't need to plan together. But if there are significant team dependencies, planning together is a great idea. I also look to see why there are so many team dependencies. Usually they have poor team design: Silos. The goal there will be to create self-sufficent teams that can bring work from concept to cash without external dependencies.

Best advice: Totally self-serving, hire people who have done it before to help you do it. This will help flatten the J curve and dramatically increase odds of success. My current client Started in 2012. By 2015 they had zero results. Then we joined them. 2016 they were 30% agile. 2017 88% agile. That's some significant improvement from their first three years going solo.

Anthony thank you very much for this reply. I think it's looking like I need to get more direct end-goals from my superiors in order to best pick the solution. I also need to get clear direction on how the team(s) will be structured to help make that decision.

@Robert: Thanks for the support!

@Elmer: When looking at teams, typically there are two major shifts that agile looks for vs. traditional:

1. Cross functional teams vs siloed teams. So no more "testing team" "architecture team" "dev team" "analyst team" etc.

2. Long standing teams. In traditional typically a project is funded, and a team is assembled to implement the project. This has lots of inefficiencies at the portfolio level. Agile portfolio management asks for long standing teams, then you bring the work to the team. When one project ends, you just give the existing team another one. This is why our teams pick fun names that have nothing to do with their project. Hot Dog and Cold Beer, Beach Buddies, Postal Titans, etc.

I find that these two ideas are the toughest for most organizations to accomplish, but once they start to think through the benefits of doing this, it does happen. Also, some teams "fake it till they make it."  They form into virtual cross-functional teams without asking for permission or for a reorg. They just act like it is real. Often this leads to the organization formally supporting their move after success start to show.

Start small with people which like and support the agile idea.
You need a sponsor a level above, to shield your team from the "old" thinking and reporting style.
Spread the good results to get the attention of the others.
Likely you have fast results, cause this first team, only includes of agile motivated persons.

Grow step by step.
Main problem will come later, when you need to move people to agile, which do not want to go this way.

all comments from Anthony are true.