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.
As opposed to trying to create a couple of metrics because you don't really understand what people around you are doing.
We are better off building over-all engineers that know what they are doing, than trying to catch up with the latest shiny thing (Scrum, Agile, Waterfall, Kanban, ...Jesus Christ)
Look at Spotifys videos on their process. Every team is self-driving, because everyone knows how to do stuff. If you work at a company where there is no process, and not every is able to complete the whole task from A-Z, you end up with deadends and people who get stuck. If the culture doesn't encourage knowledgesharing, people end up making crappy solutions.
At the end was there ever an instance of the client not using what you produced because it wasnt what they wanted?
Like anything else there is no silver bullet. Sometimes you got the feature right, other times it misses the mark.