4 ms·

Why Scrum Is the Wrong Way to Build Software

3 points by aard 4y ago

streetcat1 4y ago
Right. Scrum was designed by consultants to optimize billing time, and reduce the consultant risk to minimum, not as an efficient way to build software.
docmechanic 4y ago
Did product managers come up with scrums and agile?
quantified 4y ago
Some points of it seem apt and some are overblown. I’ve never met a product owner who didn’t create priority for important bugs, or who didn’t go along with engineers laying in groundwork for long-term success, unless it was a case of “customer will not renew the contract without this”. But it is antithetical to agile, as this quote demonstrates: > Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices But an official scrum guide is as bunk/bankrupt as the official Scrabble dictionary: not reflective of the real world. So what if you’re not doing the “official” scrum? How arrogant of the authors to claim they had any basis to be “official”.
andrewstuart 4y ago
Agreed but what is the alternative?
johncoltrane 4y ago
Agreed but I've seen it work much better for _running_ software. FWIW, a common anti-pattern I've seen around here is to use the client's inexperience with "Agile" to justify having a PO from our side. A "product _owner_" that thus doesn't own anything and has no leverage whatsoever on anything on the client side. Scrum—and "Agile"—my ass.
lordkrandel 4y ago
I don't agree, most points are false, or a misthought version of scrum is taken as a reference. E.g. "minimal amount of work" doesn't mean that it must be cheap or rushed - it means that it has to satisfy the need of the stakeholder, whoever he is. It's the team to evaluate the costs of each point, and the PO decision starts from there. The product decisions taken by the PO are about needs, priority and value, not about implementation or experience. And moreover, the "pride" in making your own code part... that's where the author totally misses the point. The main shift of agile is mindset, the shift from "I did it so I know it and I take pride from it" to "WE did it, so WE know it as a team and WE take pride of it". If you're not ok with the sharing, please go back to waterfall.

3 points by aard 4y ago

Right. Scrum was designed by consultants to optimize billing time, and reduce the consultant risk to minimum, not as an efficient way to build software.

docmechanic 4y ago

Did product managers come up with scrums and agile?

quantified 4y ago

Some points of it seem apt and some are overblown. I’ve never met a product owner who didn’t create priority for important bugs, or who didn’t go along with engineers laying in groundwork for long-term success, unless it was a case of “customer will not renew the contract without this”. But it is antithetical to agile, as this quote demonstrates: > Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices But an official scrum guide is as bunk/bankrupt as the official Scrabble dictionary: not reflective of the real world. So what if you’re not doing the “official” scrum? How arrogant of the authors to claim they had any basis to be “official”.

andrewstuart 4y ago

Agreed but what is the alternative?

johncoltrane 4y ago

Agreed but I've seen it work much better for _running_ software. FWIW, a common anti-pattern I've seen around here is to use the client's inexperience with "Agile" to justify having a PO from our side. A "product _owner_" that thus doesn't own anything and has no leverage whatsoever on anything on the client side. Scrum—and "Agile"—my ass.

lordkrandel 4y ago

I don't agree, most points are false, or a misthought version of scrum is taken as a reference. E.g. "minimal amount of work" doesn't mean that it must be cheap or rushed - it means that it has to satisfy the need of the stakeholder, whoever he is. It's the team to evaluate the costs of each point, and the PO decision starts from there. The product decisions taken by the PO are about needs, priority and value, not about implementation or experience. And moreover, the "pride" in making your own code part... that's where the author totally misses the point. The main shift of agile is mindset, the shift from "I did it so I know it and I take pride from it" to "WE did it, so WE know it as a team and WE take pride of it". If you're not ok with the sharing, please go back to waterfall.