I think that the PO criticism is this: An incompetent or indecisive PO can cripple an agile process. That's true, but (except possibly in the case of a startup), there's always a non-technical layer of management over you somewhere, and if that layer is incompetent or indecisive, your project is equally in trouble. Labeling that layer "PO" and the process "agile" changes exactly nothing about the problem.
I've been in an agile process. It worked, mostly, but it broke down when the PO didn't have the time to do the work. (It was huge for an agile team - 30 people - which put a huge amount of pressure on the PO position).
For the next project, the PO "didn't have time" to give us actual requirements - just "improved reporting". In the most amazing display of agile that I've ever seen, the development team lined up a series of customer conference calls to expose their requirements for reporting, and proceeded to run the entire development process without a PO. And that worked amazingly well...
... right up until three weeks before the scheduled end of the project. (We were probably going to miss by a week, on a six-month project.) Then product management showed up and said "We like what you're doing. But we need these additional things as well. Oh, and we can't change the end date." Predictably, that was the end of agile, as well as the end of any management reality for that project. (You think you can add three months of work without changing the end date? The real world will demonstrate to you that you cannot in fact do that.)
30 people in a single team? Yeah, that's way, way too big. I've been in some teams that were technically too big, but those were still less than half that.
Still, good job making it work despite utterly dysfunctional management there. Agile does require that management understands what you're doing and what their role in that is. But again, that's true in any other situation too.
Well, it worked really well for the release before that. It took a really strong proponent who was willing to hack process as we went along, but it worked - for us, for a while.
I've been in an agile process. It worked, mostly, but it broke down when the PO didn't have the time to do the work. (It was huge for an agile team - 30 people - which put a huge amount of pressure on the PO position).
For the next project, the PO "didn't have time" to give us actual requirements - just "improved reporting". In the most amazing display of agile that I've ever seen, the development team lined up a series of customer conference calls to expose their requirements for reporting, and proceeded to run the entire development process without a PO. And that worked amazingly well...
... right up until three weeks before the scheduled end of the project. (We were probably going to miss by a week, on a six-month project.) Then product management showed up and said "We like what you're doing. But we need these additional things as well. Oh, and we can't change the end date." Predictably, that was the end of agile, as well as the end of any management reality for that project. (You think you can add three months of work without changing the end date? The real world will demonstrate to you that you cannot in fact do that.)