All the points it makes about Agile are utter nonsense.
In what way does the engineering team end up subject to the whim of the PO? The PO needs to provide the details of what the business needs (someone needs to do that, after all), and what the priorities are, but he's in no way in charge of the team.
If the team has no PO for a significant amount of time, that does mean that a vital part of the team is missing, but I'd like to see any dev team build something without any idea of the business needs. It's the PO's job to communicate those needs, and the great thing about Scrum is that he does so as part of the team, rather from some distant ivory tower.
I also don't see in what way Senior engineers get marginalized. If anything, everybody gets treated as senior, because everybody gets ownership, responsibility and decision making power about the project (though in reality, it's of course the seniors with the clearest ideas and tend to end up with most of the control over the team).
And there's generally plenty of room to include stories (even very large ones if they can't be cut up, though they usually can) about internals, infrastructure and R&D on the backlog.
It's absolutely true that it's not for everybody, but your criticism and that of the article don't hold much water.
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'm thinking we have very different ideas of what a Senior Engineer does. Or how capable a dev team can be when given a project, without micromanagement from a PO about which buttons go where. And whether its reasonable to cut a big project up into hash and try to (appear to) complete something useful to a customer every 2 weeks.
Maybe we do. I don't know what you think a Senior Engineer does. I think a senior should be able to take responsibility and ownership over his work and the work of his team. I don't think they're able to predict business needs without any feedback about those business needs. I certainly think a senior should be able to divide big chunks of work into smaller parts, because even a junior should be able to do that; that's pretty much the core of programming.
I also think a senior should be able to understand how a development process works without resorting to silly strawmen.
There are a multitude of processes for getting feedback; Agile is a contender but by far not the best. Please don't be disingenuous - Agile processes are often strict and brittle - anything that doesn't fit into the Agile round hold can't be done, and the 'sprint' is the worst of the awkwardness.
Strawmen are different from examples; its lazy to call any explanation a strawman.
In what way is Agile strict and brittle? It's entire point is to adapt quickly, on short iterations. To be flexible. In probably the most strict form of Agile, Scrum, constant improvement of the process is an intrinsic part of the process.
I'd like to see a process that handles this better while clearly being not Agile.
In what way does the engineering team end up subject to the whim of the PO? The PO needs to provide the details of what the business needs (someone needs to do that, after all), and what the priorities are, but he's in no way in charge of the team.
If the team has no PO for a significant amount of time, that does mean that a vital part of the team is missing, but I'd like to see any dev team build something without any idea of the business needs. It's the PO's job to communicate those needs, and the great thing about Scrum is that he does so as part of the team, rather from some distant ivory tower.
I also don't see in what way Senior engineers get marginalized. If anything, everybody gets treated as senior, because everybody gets ownership, responsibility and decision making power about the project (though in reality, it's of course the seniors with the clearest ideas and tend to end up with most of the control over the team).
And there's generally plenty of room to include stories (even very large ones if they can't be cut up, though they usually can) about internals, infrastructure and R&D on the backlog.
It's absolutely true that it's not for everybody, but your criticism and that of the article don't hold much water.