Hacker News Reader

Comment by elric | Hacker News Reader

Scrum is not an acronym, there's no need to write it in all caps.

Scrum is not intended to remove rigour from development. It acknowledges that people (the client) have no clue what they want (they're no Mozart), and that it's up to the development mean to help them figure it out. Ideally converging on something that the client wants, and works well.

Sure, plenty of projects fail for a variety of reasons. And sure, scrum (or agile in general) isn't perfect. But it's the best tool in our toolbox at the moment.

You, and all those other folks who like to tilt at the scrum windmill, are more than welcome to propose something that works as well as (or better than) scrum without the downsides. But so far, it's been crickets.

IMO there are three big issues: clients don't understand software development, and management doesn't understand software development, and software developers neither understand clients nor management.

View on HN

If you think that it's the role of a developer to figure out what a client wants, then well... We have completely divergent views of how the the process should be. A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product.

It's not that scrum is not perfect, scrum is an absolute garbage that unfortunately today fits very well with the micromanaging hunger of managers, no method is better than scrum.

> A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product.

That's a sad view. Reminds me of a couple past managers I've had who thought that software developers were assembly line workers.

US culture note: The cultural expectation for assembly line workers here is that they "shut up and color", it's the job of the managers and engineers to do the thinking. That is, even if an assembly line worker can see that something is wrong, it's not their job to point it out or fix it. They are disempowered in this culture.

What's sad about your view is you similarly want to disempower developers. You don't want them to have input into what they're making, you just want them to shut up and code. According to you the specification is, what, always given to the developers without their input? So if the specification is non-viable they should just accept it and sit in their corners making nonsense?

I'm not saying that developers should ideally be drones who have no say on anything. I'm just calling bullshit in the ADHD-fueled development of nowadays where people are not even sure about what the final product should look like and put on the shoulders of the developers the workload of dealing with the ineptness of the clients and the managers.

Scrum nowadays is essentially a tool for micromanagement, that's why managers love it and developers hate it. Dailys are completely useless and breaking the development of complex projects in 2 weeks sprints is outright harmful.

> calling bullshit in the ADHD-fueled development of nowadays where people are not even sure about what the final product should look like

Sigh. Of course people aren't sure about what a final product should look like. It's easy enough for something small, but once something gets big, how the hell are people expected to know how everything will work up front?

> Scrum nowadays is essentially a tool for micromanagement, that's why managers love it and developers hate it. Dailys are completely useless and breaking the development of complex projects in 2 weeks sprints is outright harmful.

Sure, some managers love scrum, and some developers hate it. But it's not a tool for micromanagent. It's a tool for course corrections in the face of reality.

I personally find dailies to be very useful, especially in a distributed team. It's an efficient way of figuring out what's up and making sure all noses are pointed in the same direction.

No managers are involved in any of my day-to-day scrum ceremonies.

If your manager hits you with a hammer, you might want to consider that your manager is an arse instead of blaming the hammer. When a tool doesn't work for you, sometimes it's not the tool that's to blame, but the larger context in which the tool is being used.

> A software developer should develop for a specification

Really? And where does this specification come from? Presumably from a bunch of analysts? Who then write a big fat document? Which is then handed over to developers, who then groan because it is incomplete, unclear, unusable, or unrealistic? This sounds an awful lot like the waterfall of yore which turned out not to be all that great.

> he or she should not be there to entertain clients in a game of creating a product

The client tends to pay people with the hopes of getting a working product. It should absolutely be the developer's job to ensure that they get it. Even if that means -- shudder at the thought -- talking to them.

Reply on news.ycombinator.com