The point put forth in this article is that a certain degree of scientific rigour is important in running a business and it's a principle that is broadly generalisable. In particular in software development one encounters the philosophy of "get it out the door quick" regardless of the cost to quality. Engineers are often viewed as a cost-centre rather than the actual producers of value in a business when the bottom line is evaluated. It should be clear to us that businesses that actively capture and nurture engineering talent (google, apple, facebook etc.) are the businesses that are doing better at the moment than those that focus on "unit cost" of "resources" (e.g. IBM, HP) and many are now trying to make that transition as we can see from the trend towards more engineer-friendly processes such as Scrum (away from the more punishing "waterfall" style approaches).
I'm with you except that I think the "unit cost" thinkers are only shifting towards Agile/Scrum because the cool kids are doing it. In the brand of Agile/Scrum that those shops create, it is anything but engineer-friendly, and they absolutely still view engineering and software development as cost centers instead of value centers. In fact, in a lot of cases, Agile is used explicitly because it enforces an aggressive deadline culture in which the sacrifice of quality in favor of short release cycles is explicitly codified into the work culture, and reinforced every day in every team interaction. These situations also foster extreme degrees of "surveillance culture" -- basically since the middle management over top of the so-called cost center of engineering can't do much, technologically, to mitigate the realities of creating software value, they opt instead for draconian surveillance and progress tracking environments, like stodgy Jira, and they take things like team burndown literally and draw sweeping conclusions from an extremely small set of burndown data. This all typically goes hand-in-hand with open-plan offices too, where everyone can be literally seen during their work and there is an implicit mandate from the company that your status is partially related to how much you 'look the part' while in the office. Even if you're a developer needing quiet time to creatively solve a problem, and you're seated smack in the middle of a loud group of sales associates whose job requires them to be on the phone all day, the business doesn't care. Your actual productivity as a developer isn't as meaningful to them as your ability to look like a good piece of office furniture most of the time by fitting into their surveillance and micromanagement culture. Typically, promotions and advancement are won in the environments not through technical skill or hard work, but through one's ability to sublimate your natural desires for reasonable working conditions and "endure it with a smile" better than peers can, a phenomenon which Michael O. Church referred to as "macho subordination." In my working experience, at least, this has been precisely how Agile/Scrum are used, whether in a start-up, a finance firm, or a long-standing education tech company.
