[mikejholly]

Lemme guess, Scrum Master?

Although those faux titles may be technically wrong, the use of capital-A Agile usually implies association with Agile the brand (the noun), not "agile as in agility".

> That is so catastrophically false that I don't even know where to start.

Doesn't sound like a great argument. The highest performing teams I've worked with were small groups of highly skilled, talented (IQ and EQ) and passionate people. These groups are usually familiar with various development methodologies and able to come to agreement on which processes to adopt and which are cargo-culty and should be thrown out. I don't think OP is arguing for zero process. In fact the opposite is clearly stated in the Agile Manifesto list: "They figure out the process that works for them and for the current problem they are working on."

Here's a much better articulated criticism on Agile that I enjoyed:

https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...

[vacri]

> The highest performing teams I've worked with were small groups of highly skilled, talented (IQ and EQ) and passionate people.

The best performing teams you were on were the highly-skilled ubermensch? That's cherry-picking, really. "We don't really need good management practices because the cream of the crop, in small numbers, do well without them"

[libertymcateer]

Corporate lawyer, actually. However, before I was a lawyer I was a dev, and I try to stay current.

Like any methodology, Agile has its time and its place. However, I have found that the vast majority of people who categorically write-off agile don't actually do it right - and I am not talking "no true scotsman" here. I am saying that they actually do fall into cargo-cult behavior.

This aside, small groups of highly skilled and talented people can develop and ship products - sure. Maintaining them is a different thing altogether. Adding features, adding localizations, porting to new OSes - let's be serious, these require formalized practices, especially as (now very financially successful) developers move up and out onto other things.

Software is a business. Businesses are alive. Like any living thing, they must continually adapt or they will die. As a result, Software itself is also a process. Unless there are some formalisms in that process, you don't have a sustainable business - you have a business that lives and dies with its core team. That is not an investment-grade business. Nor is it a long-term sustainable business.

The link you sent has interesting points and valuable criticisms, to be sure - but this section:

>1. Business-driven engineering.

Nearly everything in it is wrong. Seriously. All businesses are business driven - and if you want your engineering teams to be purely engineering driven - go into academia. This is not to say that business goals must ignore engineering concerns - they must address them and take them seriously - this is what talented business people do. But software, like any other business, is business-driven tautologically. Even when an engineering decision is so categorically important that it becomes its own goal - it has now become a business goal. To put it another way: a purely engineering decision has results that are pari passu with regard to business impacts. When an engineering decision is no longer pari passu with regard to its business impacts - meaning that the decision will have disparate impacts on the business depending on the route that is followed - it is no longer a purely engineering decision - it is a business decision. In order to be a good business, then, you must have someone technically competent to understand the impacts making these calls.

Accordingly, I strongly belief people complaint the avalid criticism -- having non-technical people calling the shots on engineering decisions that have business impacts when they do not have the ability to understand how the technical decisions have externalities and other impacts -- has been utterly conflated with criticisms of management methodology. Just because your PM is a chump doesn't mean we shouldn't have PMs. It means you should get a better PM.

It is an unfortunate reality that, for whatever reason (and there are several clear ones in my mind) software - which is a technical discipline, make no mistake - has so, so many technically unqualified people in management. Compare this to any other technical business discipline - medicine, structural engineering, energy, mining - and the people at the top are typically also technically qualified. Software as an industry has to stop acting like it is privileged beyond these other technical disciplines and realize that its problem is not that "decisions must be engineering driven" it is that business people must be technically competent - which is a wholly different assertion, and one that I stand by fully. I.e. - we don't do away with the managers. We make sure the managers are competent. This is so, so different.

Which, by the way, is why I am a lawyer who codes. I wouldn't hire me to be on a dev team, but I can tell you with all honesty that I can sit down with your team and understand at a non-theoretical level the engineering problems you are having and their impacts into parts of the business that are not purely engineering based. This is what allows me to be - I hope - good at my job.

If you have a legal problem that relates to software - I am your guy. At least, I'd like to think so. I care about software deeply, and can tell you from experience that if you think that the lack of technical competence among PMs and scrum masters is bad - you have obviously never worked in law.

[mikejholly]

It seems obvious to me that he's referring to the dichotomy of management (top-down) versus engineering (bottom-up). I think most people understand that businesses are indeed businesses. The point is that some development methodologies commoditize engineering to such a level that engineering is disempowered. This limits potential for innovation. Innovation comes from both ends. For example, as an executive I can "ideate" a search engine faster than Google. How useful is that vision without being source by or informed by engineering innovation? Conversely, some nerd (endearing usage here) builds a new search algorithm and uses solely it to find episodes of Star Trek where Spock chastises Kirk. Not exactly serving shareholders. In a healthy organization, there's a balance between these units where both see the value the other brings.

I agree with your points about the need for managers to also be experienced (and sometimes elite) engineers. Although I'm not sure I would argue that case for Project Managers, specifically.

[ktRolster]

It is an unfortunate reality that, for whatever reason (and there are several clear ones in my mind) software - which is a technical discipline, make no mistake - has so, so many technically unqualified people in management

What reasons?