Sometimes the process worked better, sometimes worse. It depends a lot on the company culture and people. The company I'm currently at has a very good process (SAFe).

(I'm an engineer to clarify)

From what I've heard before my time, a lot of traditional organizations had a non-flat hierarchy and a set of 'bosses' - people in charge of personnel, planning, requirements, and technical decisions.

In 'modern' orgs this has been replaced by a 'matrix' structure with each team having a dedicated product owner, scrum master, line manager, requirements engineer, architect etc.

While the traditional org structure had some shortcomings, mainly having to do with the fact that if said boss didn't perform, then the team had no chance, and that so much institutional knowledge was locked up in said boss, that they were nigh-impossible to replace.

Modern management techniques are about replacing potential excellence with guaranteed mediocrity.

- the team was made up of primarily junior engineers with a small handful of intermediate and seniors

- the company's work was split between a product and N consulting projects

- the company had standardized on a specific "default" architecture (Spring Boot + Angular) with a bunch of pre-existing components that teams could use to accelerate their projects

- the projects (product and consulting) were generally managed by the intermediate engineers with a handful of juniors on each project doing most of the day-to-day work

- the seniors were mostly on the product side but had latitude to go help on any of the consulting projects if anyone was stuck

Scrum with the daily standups and bi-weekly retros worked great here. The seniors went to all of them. If someone was getting ready to start on something and they weren't aware of existing components that were either available from the library or available to libraryize from a different project, we'd help facilitate that. If someone was getting stuck on either a tricky debugging problem (of which Spring Boot was good at making) or a complex design problem, one of us would stick around and just get it solved with whoever had the problem right away. And on the other side of it, we were sufficiently looped into the various projects that we could use that as input for larger-picture architecture decisions etc.