There's a lot wrong with this post, especially the first few paragraphs. That part mostly just repeats a lot of tired myths and straw-man arguments w/r/t Scrum. There's nothing new or interesting there.
For an example of what I mean, consider this:
After the manifesto appeared, Scrum quickly declared itself to be “agile” in spite of its ...
But Scrum existed before the Agile Manifesto was created, and the creators of Scrum - Ken Schwaber and Jeff Sutherland - are signatories of the Agile Manifesto. So no, Scrum didn't just "declare itself Agile"... Scrum was part of the Agile movement from day 0.
But towards the end the post does get to an interesting point, which the author summarizes as:
If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies.
There's something to be said for that. I've always said that a lot of the core issue here is exactly the "impedance mismatch" between the way engineers see things, and the way "the business" sees things. One way to resolve that - albeit perhaps not the only way - is what the author proposes above.
It is definitely not the only way and the hardest one. Solution is actually trivial: talk to engineers about business more. There’s an anti-pattern of a god stakeholder who decides on everything providing very detailed requirements about “how” and “what” to build. Functional requirements should be “written” by engineers after they learn “why”, i.e. see the problem with the eyes of business. They don’t have to be founders for that.
I agree with that. But unfortunately, you cannot force a dev to get implied in the business aspect if they don't want to. Bad scrum practices are, in my experience, very often the consequences of the devs themselves.
I'm a scientist working in the R&D of my company, and I'm involved with business people (to know what the company needs and what will help) and the software development (to follow up to see the PoC properly implemented and put in production). While I see business people trying to follow and understand the need of the software side, I keep seeing the software side considering that trying to follow and understand the need of the business is not their job. They just want perfect "requirements", and when they interpret them in a way that is obviously not what was needed, they just say "the requirements were not written precisely enough".
I even remember in my previous company the software team joking that they redirect the company emails to the bin inbox automatically, and then complained that they were made aware very late and did not had their say in some decision. Because I have read these company emails, I knew that these decisions were discussed in time and that they have requested inputs from everyone from the company (and they took into account my feedback). This was so ridiculous from the outside, but from the inside, they were fully oblivious of how stupid they acted, they were convinced the problem was "the others". The lesson is that, now, when I have something to complain about, I first investigate if my own behavior is not also responsible of the situation.
That is not a trivial solution. Anything with the word "more" isn't a solution. How much more? how many times a day? It's just hand-waving the problem away.
I've been doing "agile" since before "Agile" was a thing, and I am a Scrum.org certified PSM. I don't need to go read anything to know that you're misrepresenting the situation here.
But to indulge you, here's what scrum.org says, in part:
If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go.
Continuous experimentation, adapting with feedback, and learning and improving as you go? That doesn't sound like "process over people" to me.
Note also that the Agile Manifesto never says anything about not having some process. I think almost everybody would agree that a certain amount of process for the sake of consistency is a Good Thing. The problem is when people over-elevate the process to where it's seen as its own end unto itself, rather than a tool to help the team deliver the $THING they are trying to deliver.
If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies. It’s a hard pill to swallow, but there just aren’t many companies doing it right. Luckily, I am guessing it is easier to teach business to a programmer than the other way around. Think of it this way: it HAS to be better than doing Scrum!"
===
My previous comment on the subject still seems appropriate.
The big problem is "How do I connect the money to the work". In large corporations, this becomes project -> plan -> work. The project gets a budget based on the plan, then you do the work based on the plan.
The problem is the link between plan and work. As you work, you learn. That is the primary activity of software development. Learning is a menace to planning. As you learn, you have to replan, but your budget was based on the original project plan.
You can talk about engineering and culture and whatever you want, but if you're working for money, the problem remains of connecting the work to money and the money to the work.
Yes, SAFe does attempt to deal with this issue, but it's like moving food around on your plate - it's still there, and management still wants to tie activities to budget.
Whatever framework or philosophy or concept you use, it gets implemented by people in an organization.
If that organization is new and growing, it is graded by things like active user growth (top line); if that organization is established, it is graded by profit (bottom line).
The journey from top line to bottom line is where all the complications come in.
So I think the author is correct in their conclusion [0], but not in depth.
0. Engineers will tend to be sad in established orgs [cost centers], and happy in new orgs [product development].
> Developers have no real power or seat at the table. They are not peers engaged in a common creative enterprise — they are hired, replaceable machinery, no different than the computers and monitors they use all day.
This is correct. Scrum (and all of the other PM rituals) exist because the people controlling the money need to attach budgets to projects in order to figure out whether they're worth doing or not (or more loosely to teams, to figure out if they're profitable or not). Once a project has a budget, then it needs to be tracked.
It's enormously frustrating to be on the other side of the table, and to have a recalcitrant development team missing estimate after estimate, sometimes by orders of magnitude. Either it's your money that's slowly being incinerated, or you have to go back to investors and tell them that you decided to spend on X, and X is only 1/3rd as far along as the tech lead told you it would be.
But it's also frustrating to be on the developer's side of the table. We're not generally included in the business strategy meetings, because we don't generally have MBAs. (Also because we're expensive, and having us sit in "irrelevant" meetings, especially when we're "behind" anyway, seems like a poor use of resources.) As a result, we're two steps removed from the decisions that matter - and not in the room when we could potentially have suggested a better approach to solving the original problem.
Personally I'm done with the corporate software world - I'm riding the fractional/freelance bus until retirement. But, I wonder if these kinds of dysfunctional dynamics could be fixed with multidisciplinary teams. E.g. imagine a team of several devs, a couple mbas, and a few sales people, responsible as a group for the team's financial position in the company. Strange bedfellows, maybe, but if each person's success depended on everybody else in the team hitting their goals, the communication patterns could end up being quite different.
> It's enormously frustrating to be on the other side of the table, and to have a recalcitrant development team missing estimate after estimate, sometimes by orders of magnitude.
I know this is just my anecdotal experience versus yours, but every time this has been the case for me in my life, it's due to dates being told to the developers instead of the other way around. Sometimes it's blatant "we need to hit this date because of the market / end of quarter" and sometimes it's passive aggressive such as "management didn't feel your date matched expectations, try again" and it gets sent back for another estimate which will now be biased.
I've also been on both sides of the table, and I'm glad I was a developer first and had those experiences. I already knew that humans can't estimate large things accurately, and that was one of the great takeaways from scrum: do smaller batches and estimate those to get more accurate numbers.
I worked on a project once, where the date was written in the law (financial compliance). Sometimes we have to accept and deal with the deadlines and the problem becomes the problem of quality and scope. In such situations you just throw away some of the best practices and just ships whatever works. Business is often totally fine with imperfections.
> Sometimes it's blatant "we need to hit this date because of the market / end of quarter"
You know what‘s blatant? "Deadline is MM-DD, and it’s non-negotiable, because that‘s the birthday of the boss‘s deceased husband". Been there, suffered that.
All important projects had that deadline, year after year, when they were so unlucky to have their projected end dates somewhere around that part of the year.
> E.g. imagine a team of several devs, a couple mbas, and a few sales people
A modern product engineering team is like that. Decent product manager (as a substitute for MBA), UX designers, researchers, devs, QA, some relevant business stakeholders and north star metric to align the work with it.
>E.g. imagine a team of several devs, a couple mbas, and a few sales people, responsible as a group for the team's financial position in the company. Strange bedfellows, maybe, but if each person's success depended on everybody else in the team hitting their goals, the communication patterns could end up being quite different.
You described a small business!
If society and school system weren't trying to hard to turn everyone in mindless employees (MAX(salary) so everyone ends up in a few huge corps), we would see more small enterprises: the economy and people' lives would be much better.
Upwork to start - set rates high enough and you'll find a steady stream of reasonable positions coming through. It's a bit of a slog until you build a reputation.
Eventually word of mouth and your network kicks in.
I think you'll find "distributed decision-making" is no panacea. I joined a company recovering from a distributed governance model, and the big challenge was that nobody had enough decision-making authority for the firm to change quickly and respond to the evolving outside world. Bringing a whole room to consensus is a lot tougher than getting a few people to disagree-but-commit and move on with their day.
Funny enough, you even see this paradigm in secret messaging with Signal: the ecosystem is moving[0]. If you want a system that can evolve in response to external change, centralization is useful.
This isn't a defense of scrum, but a voice of opposition to running businesses as distributed utopias. It sounds great on paper, but you'll be out-competed by the faster-moving entities with centralized power very quickly.
This post resonates a lot with me, enough that I want to comment. After 5 years working with a full-time SM (3 different ones) in my team, I still have no idea what value they are supposed to provide, or how they fill their day once the daily meeting is over. As the author states it is completely demotivating to feel like you are carrying a parasite on your back ("robs engineers of their productivity and self-esteem").
Note that among the devs at my company, I'd say more than half don't seem to have a problem with it, or at least go with the flow, so I might be in the minority but I feel strongly enough about it to consider trying freelancing, I just hope I can demonstrate enough technical skills to be able to "insist on being in control of how [I] work" and still be hired...
Developers should become owners! It is much easier for a developer to learn the business side of startups than it is for a business founder to learn how to code. Not only will learning the business side allow developers to become founders, it will improve their development decision making, allowing them to communicate better with customers and the rest of the company about priorities and strategic decisions. Once you know how to talk the language, it becomes easier to convince people that technical factors are important to strategic decisions. Even if you don't become an owner, learning the business side of business will allow you to play a larger role in the decision making.
I definitely want to become an owner and learn about the business. I've even conceived and executed projects to improve the bottom and top line revenue. That being said, as a developer in a small business, the thought is that I'm too expensive an employee to not be coding even if I had a lot of impact on my own initiatives. The thinking is that a lot of people can think about strategy but very few people can code so I get pigeonholed into just executing. This has been my experience at multiple startups at various stages of their lifecycle.
Sure, but the reverse of that is, you as the developer, are the owner, and you just hire the people to think about strategy, etc.
What you are saying is true, because coding is the high value work that relies heavily on the individual effort and productivity. The team effect of coding is effectively the sum of each coders productivity.
The business side is the opposite, it can be much lower value individual work, but the team efforts combined is exponential. If you want good software you can't really just throw more developers at something, in fact doing so can often lead to declining returns. But this is the idea behind things like SCRUM, Agile, Stand up etc. It's a way to try and figure out how to scale development by effectively just adding more manpower. It simply isn't a fit for development though.
On the business side however you can scale just by adding more people.
At the end of the day you can have excellent software that makes no money, and you can also have excellent business strategy that makes money and fails to deliver a product.
That only works in some business domains. If, for example, you're trying to build products for a complex healthcare use case it takes years for most developers to start making a positive contribution as product owners. A lot of customer requirements are counterintuitive and don't make sense to anyone without deep domain experience.
As a tech feudalist myself, I think software developers could be the best at accounting, tax and corporate entity structures too, which can guide the business decisions as well. I generally see a segregation of those interests, but as business owners the interdisciplinary nature can become clearer
Ok, but here me out - I think many things are missed in this take. This one immediately jumps out at me (from the manifesto): "Build projects around motivated individuals"
The manifesto is predicated on this basis - that the individuals are motivated and capable of delivering when empowered. In a large corporate environment, can you make that assumption? Is your hiring always that good? Can you provide the type of environment that always produces high morale?
I'm no fan of scrum, but I've also seen what happens when "unmotivated" individuals are given too much free reign - nothing. How do you, as a large business, address that? Mass firings, or more "active" process? Perhaps business can't get over the risk mitigation that scrum provides?
I don't know the author, but these complaints about ownership make me worry if they are not a team player.
By "not a team player", I mean they can't easily subordinate themselves to the rest of the team's consensus, to the enterprise culture/standards, to the limitations of the legacy codebase, to their product owner's direction, or to the laws of physics.
This programming stuff takes humility, and everything is hard to do. Non-team players make everything harder with the friction they add to every decision and the morale drain they put on the rest of the team with their sourpuss nature.
I try to win these folks over with love and help them to add many small wins to their name, but they're often energy monsters and they quickly exhaust me. It's often a relief when they remove themselves from the team.
The scrum people can also be non-team-players by not subordinating themselves to the team's consensus on appropriate methodology and level of ceremony. That adds friction, too. It's just that, since it's the "team players" pushing scrum, it's not obvious that they are in fact not team players. They're running over the team with their vision of teamwork, but they're not actually listening to the team protesting that it doesn't fit.
The "scrum people" you refer to are supposed to be the team itself, so it sounds like you're describing some scrummerfall-type organization. I agree ceremony would be largely meaningless and worthy of scorn in such a place.
Can you describe a scenario you were involved with where these other people weren't listening to the team's protestations, or were you just giving a hypothetical?
My favorite ceremony in Scrum is the retrospective because that's where we get to factor protests and pains into our backlog.
Here's how I got there. Author doesn't like the way decisions are made so they think they should be the decision-maker. The team is supposed to make the decisions in Scrum. So, I feared that in reality, they're just not a team player and feeling a little powerless in that dynamic given all the pushback they may be experiencing.
The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes.
The Scrum Master is supposed to be the unblocker and master of ceremonies. In my opinion, the best SM arrangement is as a rotating role for analysts/developers on the team rather than a dedicated position. The Scrum Master needs to be involved with the actual work to understand what a blocker is. Rotating SM is actually becoming more common in the industry, as I understand it.
The ideal Product Owner is the one neck to choke on the team for failure. The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Obviously, there are less-than-ideal PO's, and we can lament and complain about that separately, but author needs to better understand what a PO is in Scrum. I wonder if they think a Project Manager is the same thing as a Product Owner.
I think the link is that it is not at all uncommon to see someone who cannot play nice with consensus or be humble to blame everything on the company ownership.
It is possible there is a company ownership problem sometimes. But the article conclusions seem to be presented to be valid all the time.
I too had this impression reading the article. I would not have had this impression if the article was also mentioning that maybe sometimes a bad scrum implementation is the result of the software developers wanting to control everything while being uneducated on all the aspects that are slightly outside of their narrow field of expertise. This is common enough that there is a term for that: "engineer's disease", and that it was illustrated by a xkcd comic strip (1570)
When everyone is responsible for a project, when everyone owns it, it means that no one is responsible for it, that no one owns it, and therefore it is doomed to fail with about a 95% probability.
As for the "product owner", they only control direction, and they are not actually vested in the success of the project beyond their immediate direction.
Readit News
For an example of what I mean, consider this:
After the manifesto appeared, Scrum quickly declared itself to be “agile” in spite of its ...
But Scrum existed before the Agile Manifesto was created, and the creators of Scrum - Ken Schwaber and Jeff Sutherland - are signatories of the Agile Manifesto. So no, Scrum didn't just "declare itself Agile"... Scrum was part of the Agile movement from day 0.
But towards the end the post does get to an interesting point, which the author summarizes as:
If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies.
There's something to be said for that. I've always said that a lot of the core issue here is exactly the "impedance mismatch" between the way engineers see things, and the way "the business" sees things. One way to resolve that - albeit perhaps not the only way - is what the author proposes above.
I'm a scientist working in the R&D of my company, and I'm involved with business people (to know what the company needs and what will help) and the software development (to follow up to see the PoC properly implemented and put in production). While I see business people trying to follow and understand the need of the software side, I keep seeing the software side considering that trying to follow and understand the need of the business is not their job. They just want perfect "requirements", and when they interpret them in a way that is obviously not what was needed, they just say "the requirements were not written precisely enough".
I even remember in my previous company the software team joking that they redirect the company emails to the bin inbox automatically, and then complained that they were made aware very late and did not had their say in some decision. Because I have read these company emails, I knew that these decisions were discussed in time and that they have requested inputs from everyone from the company (and they took into account my feedback). This was so ridiculous from the outside, but from the inside, they were fully oblivious of how stupid they acted, they were convinced the problem was "the others". The lesson is that, now, when I have something to complain about, I first investigate if my own behavior is not also responsible of the situation.
Scrum is process over people.
It's the opposite of the agile manifesto.
But don't trust me: read the agilemanifesto.org and then go and read "What is Scrum" from scrum.org
But to indulge you, here's what scrum.org says, in part:
If you are just getting started, think of Scrum as a way to get work done as a team in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go.
Continuous experimentation, adapting with feedback, and learning and improving as you go? That doesn't sound like "process over people" to me.
Note also that the Agile Manifesto never says anything about not having some process. I think almost everybody would agree that a certain amount of process for the sake of consistency is a Good Thing. The problem is when people over-elevate the process to where it's seen as its own end unto itself, rather than a tool to help the team deliver the $THING they are trying to deliver.
If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies. It’s a hard pill to swallow, but there just aren’t many companies doing it right. Luckily, I am guessing it is easier to teach business to a programmer than the other way around. Think of it this way: it HAS to be better than doing Scrum!"
===
My previous comment on the subject still seems appropriate.
https://news.ycombinator.com/item?id=41080195
The big problem is "How do I connect the money to the work". In large corporations, this becomes project -> plan -> work. The project gets a budget based on the plan, then you do the work based on the plan. The problem is the link between plan and work. As you work, you learn. That is the primary activity of software development. Learning is a menace to planning. As you learn, you have to replan, but your budget was based on the original project plan.
You can talk about engineering and culture and whatever you want, but if you're working for money, the problem remains of connecting the work to money and the money to the work.
I'm reminded of the Oxygen Catastrophe - https://en.wikipedia.org/wiki/Great_Oxidation_Event - we need oxygen to live, but it also kills.
Ooh, that's a cool thought that the more learning needed, the more planning is hard. True, and I haven't put that together before.
https://scaledagileframework.com/lean-budgets/
Whatever framework or philosophy or concept you use, it gets implemented by people in an organization.
If that organization is new and growing, it is graded by things like active user growth (top line); if that organization is established, it is graded by profit (bottom line).
The journey from top line to bottom line is where all the complications come in.
So I think the author is correct in their conclusion [0], but not in depth.
0. Engineers will tend to be sad in established orgs [cost centers], and happy in new orgs [product development].
This is correct. Scrum (and all of the other PM rituals) exist because the people controlling the money need to attach budgets to projects in order to figure out whether they're worth doing or not (or more loosely to teams, to figure out if they're profitable or not). Once a project has a budget, then it needs to be tracked.
It's enormously frustrating to be on the other side of the table, and to have a recalcitrant development team missing estimate after estimate, sometimes by orders of magnitude. Either it's your money that's slowly being incinerated, or you have to go back to investors and tell them that you decided to spend on X, and X is only 1/3rd as far along as the tech lead told you it would be.
But it's also frustrating to be on the developer's side of the table. We're not generally included in the business strategy meetings, because we don't generally have MBAs. (Also because we're expensive, and having us sit in "irrelevant" meetings, especially when we're "behind" anyway, seems like a poor use of resources.) As a result, we're two steps removed from the decisions that matter - and not in the room when we could potentially have suggested a better approach to solving the original problem.
Personally I'm done with the corporate software world - I'm riding the fractional/freelance bus until retirement. But, I wonder if these kinds of dysfunctional dynamics could be fixed with multidisciplinary teams. E.g. imagine a team of several devs, a couple mbas, and a few sales people, responsible as a group for the team's financial position in the company. Strange bedfellows, maybe, but if each person's success depended on everybody else in the team hitting their goals, the communication patterns could end up being quite different.
I know this is just my anecdotal experience versus yours, but every time this has been the case for me in my life, it's due to dates being told to the developers instead of the other way around. Sometimes it's blatant "we need to hit this date because of the market / end of quarter" and sometimes it's passive aggressive such as "management didn't feel your date matched expectations, try again" and it gets sent back for another estimate which will now be biased.
I've also been on both sides of the table, and I'm glad I was a developer first and had those experiences. I already knew that humans can't estimate large things accurately, and that was one of the great takeaways from scrum: do smaller batches and estimate those to get more accurate numbers.
You know what‘s blatant? "Deadline is MM-DD, and it’s non-negotiable, because that‘s the birthday of the boss‘s deceased husband". Been there, suffered that.
All important projects had that deadline, year after year, when they were so unlucky to have their projected end dates somewhere around that part of the year.
A modern product engineering team is like that. Decent product manager (as a substitute for MBA), UX designers, researchers, devs, QA, some relevant business stakeholders and north star metric to align the work with it.
You described a small business!
If society and school system weren't trying to hard to turn everyone in mindless employees (MAX(salary) so everyone ends up in a few huge corps), we would see more small enterprises: the economy and people' lives would be much better.
The old "startup" I am working for is dying and I need to plan my next move…
Eventually word of mouth and your network kicks in.
Funny enough, you even see this paradigm in secret messaging with Signal: the ecosystem is moving[0]. If you want a system that can evolve in response to external change, centralization is useful.
This isn't a defense of scrum, but a voice of opposition to running businesses as distributed utopias. It sounds great on paper, but you'll be out-competed by the faster-moving entities with centralized power very quickly.
[0]: https://signal.org/blog/the-ecosystem-is-moving/
Note that among the devs at my company, I'd say more than half don't seem to have a problem with it, or at least go with the flow, so I might be in the minority but I feel strongly enough about it to consider trying freelancing, I just hope I can demonstrate enough technical skills to be able to "insist on being in control of how [I] work" and still be hired...
Hey, my SM can configure JIRA swimlanes! /s
What you are saying is true, because coding is the high value work that relies heavily on the individual effort and productivity. The team effect of coding is effectively the sum of each coders productivity.
The business side is the opposite, it can be much lower value individual work, but the team efforts combined is exponential. If you want good software you can't really just throw more developers at something, in fact doing so can often lead to declining returns. But this is the idea behind things like SCRUM, Agile, Stand up etc. It's a way to try and figure out how to scale development by effectively just adding more manpower. It simply isn't a fit for development though.
On the business side however you can scale just by adding more people.
At the end of the day you can have excellent software that makes no money, and you can also have excellent business strategy that makes money and fails to deliver a product.
The manifesto is predicated on this basis - that the individuals are motivated and capable of delivering when empowered. In a large corporate environment, can you make that assumption? Is your hiring always that good? Can you provide the type of environment that always produces high morale?
I'm no fan of scrum, but I've also seen what happens when "unmotivated" individuals are given too much free reign - nothing. How do you, as a large business, address that? Mass firings, or more "active" process? Perhaps business can't get over the risk mitigation that scrum provides?
By "not a team player", I mean they can't easily subordinate themselves to the rest of the team's consensus, to the enterprise culture/standards, to the limitations of the legacy codebase, to their product owner's direction, or to the laws of physics.
This programming stuff takes humility, and everything is hard to do. Non-team players make everything harder with the friction they add to every decision and the morale drain they put on the rest of the team with their sourpuss nature.
I try to win these folks over with love and help them to add many small wins to their name, but they're often energy monsters and they quickly exhaust me. It's often a relief when they remove themselves from the team.
The scrum people can also be non-team-players by not subordinating themselves to the team's consensus on appropriate methodology and level of ceremony. That adds friction, too. It's just that, since it's the "team players" pushing scrum, it's not obvious that they are in fact not team players. They're running over the team with their vision of teamwork, but they're not actually listening to the team protesting that it doesn't fit.
Can you describe a scenario you were involved with where these other people weren't listening to the team's protestations, or were you just giving a hypothetical?
My favorite ceremony in Scrum is the retrospective because that's where we get to factor protests and pains into our backlog.
There is no relation there.
The author's complaints about Scrum Master and Product Owner do not seem to be substantiated, just gripes.
The Scrum Master is supposed to be the unblocker and master of ceremonies. In my opinion, the best SM arrangement is as a rotating role for analysts/developers on the team rather than a dedicated position. The Scrum Master needs to be involved with the actual work to understand what a blocker is. Rotating SM is actually becoming more common in the industry, as I understand it.
The ideal Product Owner is the one neck to choke on the team for failure. The ideal PO is the keeper of the vision and the tastemaker and a buffer between the team and the business/politics and the subject matter expert when it comes to business requirements for the project. Obviously, there are less-than-ideal PO's, and we can lament and complain about that separately, but author needs to better understand what a PO is in Scrum. I wonder if they think a Project Manager is the same thing as a Product Owner.
It is possible there is a company ownership problem sometimes. But the article conclusions seem to be presented to be valid all the time.
I too had this impression reading the article. I would not have had this impression if the article was also mentioning that maybe sometimes a bad scrum implementation is the result of the software developers wanting to control everything while being uneducated on all the aspects that are slightly outside of their narrow field of expertise. This is common enough that there is a term for that: "engineer's disease", and that it was illustrated by a xkcd comic strip (1570)
As for the "product owner", they only control direction, and they are not actually vested in the success of the project beyond their immediate direction.