Yep, that's pretty close. There are some considerations with teams-of-teams. Infrastructure, suppliers, scheduling, production support, release procedures, etc. There is also a bit of organization and dynamic scaling necessary: you don't want a program backlog with 4 thousand items on it. That's unworkable.

Usually it helps if you stay with fixed iterations instead of Kanban and do program planning all at once (Yes, 150 people all in the same room working out the next couple of sprints. Fun to watch and participate in!)

Other kinds of tooling issues become bigger in a large group, like how to integrate separate physical pieces, how many branches to have in your CM tool, how technical drawings will be cataloged, etc. But none of it is super hard, and lots of other folks have already gone down this road. The important thing is not to over-constrain your development environment just to make yourself feel safer.

The biggest obstacle to running a larger group like this is dealing with the parts that are counter-intuitive. It just seems natural with 100 folks that you'd have a detailed charge-code breakdown, for instance. Or that 100% capacity is something you want to achieve. There are a few more gotchas like this, but if people are open-minded, it can mean a huge increase both in performance and happiness.

The industry is moving towards plain kanban without the sprints. I like this idea with smaller groups, especially groups with lots of support work on existing code, but for larger projects creating something new, using sprints, having a fixed point of coordination for a lot of different stuff, works much better.

Note I didn't say you couldn't go total kanban at large scale, just that there was a trade-off involved with each path.