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.