Essentially the "process" was:
- Someone gets an idea to do something, e.g. PMs wants to add a feature.
- The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies).
- Get a very rough estimate from developer. Are we talking a few days, a few weeks or a few months?
- Manager, PM and other teams get together to figure out priorities, schedules and who's likely to be working on it.
- Based on some discussions, areas of expertise etc, some number of devs gets assigned to work on this feature.
From here the devs know what they're trying to accomplish, what the constraints are and who to go to for questions (PM, design etc). They also know who else from other teams they're collaborating with and they just figure out amongst themselves how to get things done. They'll keep their managers and the PM updated on progress and any blockers.
Every once in a while manager etc have to step in. For example if some big that was previous unknown came up, there is a big risk, priorities need to be adjusted etc. But for the most part things just worked really smoothly.
Sometimes we need to give estimates and really hit it (legal or security issues, big marketing launch etc), but for the most part we were trusted to be doing things as quickly and efficiently as possible. So none of the commits, sprints and burn down charts BS. It's not hard to gauge develop's productivity based on output anyways. If there was something slowing the team down, we communicated the need to the manager and PM, and we worked on fixing it.
So for me, if you have good competent people that communicate well, you don't really need much process.