Why Scrum Is the Wrong Way to Build Software | Hacker News Reader

Why Scrum Is the Wrong Way to Build Software

medium.com

19 pointsaard5 comments

> 15. Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate.

Wait, you want me to create a webpage that didn't exist before. Sir, we are truly in new territory here; there's no way I could ever give you a reasonable estimation. It could be a day, could be a year! It's very hard to estimate such a monumental task.

If you'd like, Github has a wonderful selection of pre-built webpages that we could just copy and paste onto our site. Like this page for catpics2ascii.js. I realize that it doesn't do what YOU think it should do, but I'm an ENGINEER and you should trust me, I know what's best. WHY DO YOU TRY TO STIFLE MY CREATIVITY?

Seriously though, I think we've all worked with this kind of developer before. The know-it-all that can't get anything done and constantly bitches about all the obstacles holding him back. In my experience, PO's listen to developers much more than any one else. You just have to earn their trust by showing them you can do good work.

I think he covered it already!

> Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones

I think painting the picture that the author is "this kind of dev" is just as high-horsish as writing a blog post kicking and screaming about why scrum is terrible. I've worked in both settings, sometimes POs are insanely condescending and overbearing, sometimes they're great. Neither yours nor OPs opinions are unanimous to the industry.

Plus, that's kinda the point of blogging. If you want to kick and scream, the internet will totally let you.

Why <insert any philosophy> is a bad way to build software when you use it in <insert a bad way/abuse of the philosophy>. SDLC procedures have to interpreted correctly, their philosophy understood and its application to your organization investigated (e.g. Is your scrum team really cross functional?, can your work be divided into meaningful chunks? etc.). Agile practices are hard to understand and grasp, even harder to implement in a clockwork fashion unless you invest a huge amount of discipline and at the same time flexibility.

Scrum is even harder to do correctly and there is no one size-fit all recipe for it. Scrum should promote testing of features so better integration of a test team inside a scrum cycle should be possible, it invokes good discussions under pre-planning to come up with backlog tasks, Scrum master role is meant to be transferable if the designated person is not available, Scrum also focuses a lot on metrics and the idea is to gather that data, understand what process improvements are needed and do the next Scrum incrementally better.

Now all of this may not work in your organization, something else will maybe. It's not the fault of this particular SDLC.

That's.. not scrum. Your first point isn't anywhere within scrum at all. That's how people choose to treat it.

Reply on news.ycombinator.com