First of all, there's the truisms, which make this sound as if it was written by some HR drone:
> on the other hand it [Agile] improves productivity when correctly implemented.
Improves productivity over what? Over cases when it's incorrectly implemented? That's true for anything. Over cases when no policy is actually in place? That's also true for anything that introduces some form of order, at least in the beginning. Compared to other PM techniques? Good luck implementing Agile in projects that require hardware design.
> You don’t just need a good programmer, you need one with good communication skills, one that understands the business enough to work with it productively and one that is savvy enough about why tactical and strategic decisions are made.
Arguably, a programmer with poor communication skills, who does not understand what the system he's building does and why it's being done the way it's being done is not a good programmer. It may be a good programmer from the perspective of the head of recruiting, or from the perspective of someone in accounting who sees the smaller paycheck they're giving, but arguably not for someone who is interested in, you know, the programs that guy/gal is writing.
This perspective that focuses on the code churning aspect of a programmer's work rather than on the problem solving aspect is typical of people who have actually not worked on a non-trivial programming project. The truth we all painfully learn in our first four or five years on the job is that writing code isn't the hard part in programming (well, it is for those who made a wrong career choice...). Coding is the most visible and the least cryptic of the activities we do. To someone in a management position without any programming experience, it looks like the programming language and the technologies are the main obstacles to anyone becoming a programmer. Truth is, any idiot can write code.
> Programmer Anarchy presumes that everyone in the team is totally passionate about the project’s success
I'd say programmer anarchy presumes that everyone in the team is totally passionate about what they do.
Just in the paragraph above this, the author argues that PA worked for Fred George because he had a team of good programmers -- but this is a methodology that won't work for unskilled programmers. If the determining factor was actually passion about the project's success, why would the level of skill matter? A poorly-trained programmer can be just as passionate about seeing a project succeed as a good one, especially if he's just starting out and is a bad programmer as a result of lack of experience, not lack of raw skill. In fact, in my experience, I've seen a lot of poor programmers scoring high points on the passion thingie, simply because they tend to compensate their lack of programming productivity with really loud talking, and engineering skills with social skills.
Martin Jee seems to look at this with the eyes of someone who's managing names on paper, not real people. There are factors that the waterfall model doesn't put into play, like peer pressure and team solidarity. It also scores high points on other motivation factors like trust; good developers are skeptical to project managers whose methodology has more buzzwords than ideas -- and Agile's thin, broad tent is a prime candidate for people who do that -- and more favourable towards solutions which they perceive to be closer to their actual job.
> You find that many other members of the team prioritise their private lives more when it comes to spending time in the office, or that their minds are somewhere else when they are sitting at their desks.
This is true of any project management methodology. Unless I'm missing something, waterfall also presumes people are actually doing work during their work hours. PA also doesn't come with an increased number of work hours.
> With a central leader figure you also get one person who has staked the next part of their career on the success of the project and they become the driving force behind it’s delivery. Programmer Anarchy presumes everyone is their own leader, but again not everyone is like that. Lots of people don’t want to take control or drive through the delivery, they just want to do a day job.
This is fallaciously presuming that every central figure is "staking" the "next part of their career" -- i.e. that every central figure's purpose in life is to climb the corporate ladder. This is usually symptomatic of malformed meritocracies. Everyone in the team is staking their careers on the success of the project they're working on; it is far easier to find scapegoats when you have prominent leader figures, and scapegoating is a fundamental component of the corporate ladder. But informal leadership can functionally provide some of the needed advantages.
I think the fundamental difference in view is this:
> I think the most powerful idea in Programmer Anarchy is the idea that programmers take personal responsibility for the success of each project
There is a very small set of products whose success depends more on marketing, sales or the IP lawyers than on the product's technical merit. This is extremely small, confined to a handful of monopolized domains, more often than not with products that are not under serious active development, and while an investor might consider them successful, no self-respecting programmer would want to claim that as one of the high points of their careers.
For anything else, the success of each project preeeeeetty much depends on the product it aims to develop actually, you know, working as expected, which is obviously up to the programmers. This is true for any field: a well-financed real estate project will fail if the architects and builders come up with houses that crush under the weight of the roof, a heavily-advertised car that doesn't start or breaks down every hundred kilometers because the engineers and workers didn't do it right will not earn much income and so on.