Scrum isn't bad, but there are better agile processes. Most people doing scrum don't really do retrospectives and make changes to the process. In a large company this isn't really reasonable as there needs to be some process in common with each team, and the processes you most need to change in scrum are the ones that can only be changed if every team does it at once.

I favor kanban processes - it locks in less at an organizational level and thus allows more freedom to make changes for the team. Though in my experience there is less change needed in the first place because the only processes specified are the ones that are locked in and everything else is whatever it takes to make it work.

Your thinking is part of the problem.

Agile is rooted on focusing on people. Make a group of good people and empower them and they will create a process that works well. Also on the cases the process fail, they will change it. But if you go and decide the process, that's more than half the way towards a failure already.

What you propose works in a small organization - which is the type of place where scrum was created and works well. In a large organization there would be too many people trying to make conflicting changes for that to work. Any individual change might be good, but they conflict and nobody can track what you are supposed to do now. That is why large organizations are so hard to change.

Agile focusing on people is a good thing. People are number one, but agile has always acknowledged the roll of processes.

> In a large organization there would be too many people trying to make conflicting changes

Ideally, even in a large organization, it should still be structured down into small teams that can self-manage. You'll end up with Conway's Law taking effect, but you'll also alleviate the O(n^2) communication problem. In my experience, it works a lot smoother than 50 person teams where everyone's tripping over each other all the time.

Right, thanks for the correction, I meant Scrum of course.