Hacker News Reader

Sounds like you indeed didn't read beyond the first line - this article argues that it is not scrum (etc.) which is horrible, but the context in which these systems are used.

The first 4 paragraphs were enough to know that it isn't worth the time. You can't spend 50% of the article being so off base and have the rest be worthwhile.

I thought the opening line "Scrum is horrible" made it immediately clear that this is an opinion piece. I can't speak for this author, but when I say something like "your data fits in RAM" or "just say no to microservices" I am well aware that some data actually does not fit in RAM and sometimes microservices are actually appropriate.

I'm pretty happy at a Scrum shop right now, but I appreciated reading this. If you have a passionate opinion forged from personal experience, I think it's best to just present it that way rather than trying to tone it down or dress it up into something tamer but more universally correct.

Who is Scrum for? I would argue it's not for the developers. In that case, whether or not some teams are happy using it doesn't really matter. It's a tool to give the illusion of metrics and estimation in an situation that is antithetical to it.

Someone looked at the Agile manifesto -- specifically that part of "people over processes" -- and decided what was really needed was a strict process and a bunch of ceremonies to go with it! Can developers be happy with this? Absolutely. Are there plenty of developers unhappy with it? Also absolutely. I think that means we should still look at it critically.

> Who is Scrum for? I would argue it's not for the developers

The point of Agile/Scrum is to give the developers total peace from interruptions for a sprint of development. _Nobody_ can come and tell them to change the plans mid-sprint. If someone tries it's the Scum Master's job to tell them politely yet firmly to leave.

If someone insists on changes, the Official Process says that they delete everything from the start of the sprint and start again - this is to give a clear price for interruptions.

"You want this door over there instead of here where we designed it a month ago? Cool" burns down the house "Let's start over then".

In 99.99% of the cases the request suddenly isn't THAT important and they can wait until the end of the sprint.

BUT

Scrum can only work if it has the buy-in of the whole company, you can't start it from the bottom down without some really big cojones.

> The point of Agile/Scrum is to give the developers total peace from interruptions for a sprint of development.

That part can be done without scrum.

However, you are omitting that scrum also drags: Product Owners, sprint plannings, poker, daily standups, sprint demos. And you know what follows a sprint? Another sprint...And every time you miss that (self imposed, totally arbitrary) deadline, you fail.

I simply don't understand why people do this to themselves.

If you keep missing "deadlines", you aren't planning properly. You can always take more work for a sprint, don't overcommit.

Product Owner is just the one who prioritises the features the team implements, they're the one whose job is to know what the client wants and translate it to more technical terms and individual features.

Sprint planning is just... planning what you'll do for the spring? Don't you usually plan your projects or do you just YOLO it? Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing.

Demos are the best part of Scrum, you get to show what you accomplished to people who understand the client's requirements and you'll get immediate feedback for the next sprint.

What kind of project model do you like if Scrum is The Devil Incarnate? Who takes care of customer requirements? Do you plan your time use? How do you teach other people in the company not to bother the team during implementation?

> Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing.

Why? So a middle manager can create a report and submit it to their superiors? What if we omit all these reporting steps (and the middle manager) and gather when there is need to gather only? The team knows what they are doing, they can see it in each other's commits and each other's tickets. Who are you trying to inform/report to here?

> What kind of project model do you like if Scrum is The Devil Incarnate?

Kanban

> Who takes care of customer requirements?

Developers. You can also implement a feedback form and read it as a team.

> Do you plan your time use

Roughly. If we knew exactly what each thing entails to plan it in detail, that'd be waterfall. Or scrum, which is mini waterfalls one after another, never ending. That time you spend on planning, better spend it doing, and without a ceremony master.

> How do you teach other people in the company not to bother the team during implementation?

We told them once. If you have a problem when business types are barging in all the time and bothering your devs, maybe the business types can get a course in patience and basic manners?

So you know at all times what everyone in your team does? Do you chat constantly with everyone on your team? Nobody just hunkers down and does stuff for a few days?

It's these cases where the standard checkup time (daily standup) comes in handy. It's not for "the middle management", it's for the team to know how everyone is progressing.

--

How do you manage releases with Kanban? Do you have a release train and release whatever happens to be complete at the time it leaves the stateion or something else?

--

So Developers take the time to arrange a meeting with the customer, talk with them about their problem, write down the features etc? And this is fine, but spending a Monday morning every two weeks planning a sprint is anathema?

Nobody in the team is an introvert who considers root canal without anaesthesia more enticing than spending a full day talking with non-technical customers about project requirements?

--

You clearly have the cojones and corporate political power to tell business types and middle managers to fuck off. Many MANY other developers do not, if they tell the sales lead to fuck off with his "urgent" requests mid sprint, they'll be looking for a new job the next morning.

I think it's a management strategy to keep developers under constant pressure with feet close to the fire. There is always something to do, report, meet, discuss in a formalized way, damn everything else. Even if you didn't do much this week you still have to report something. Do this two weeks in a row and your already on the naughty list. Doesn't matter if your tenure was stellar so far.

In my experience the only ones loving it are of course management, and highly vocal and relatively young developers who seek refuge in arbitrary procedures and fake structure.

As others said, it's also a way to try to treat developers as assembly line workers, which can be replaced at any time. Doctors or lawyers have no such thing. Nor any other engineering profession that I know of.

Software development is a realm of snake oil salesman, move fast - break things philosophy, and no unions. So no wonder we get this kind of crap shoved down our throats. And just like with any mass of people, a certain percentage will absolutely adore it.

> As others said, it's also a way to try to treat developers as assembly line workers

Yes, a constant reminder that, even if you are highly paid cog in the machine, you are still a cog that can be replaced at any moment.

Because, you know, real decisions about what the product have to be made by a businessy dude, while developers are relegated to playing with their ci/cd and expensive toys. I guess what pisses me off the most is the patronizing attitude. All these methodologies scream: 'I don't trust you, so I will flood you with process where I can micromanage you'.

And I think it's a good way to communicate how the team works.

If you want new features, you talk to the product owner and they'll add it to the backlog - at a priority they choose.

You don't barge into the team's area demanding "just this one quick fix", there's a clear process to get your stuff in the queue.

If your workplace already works like this, you don't need agile, scrum or any other method with a fancy name. Keep doing what you're doing.

Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.

> Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.

How does it do that? If the sales guy sold feature X to a client you're going to have to build it -- Scrum be damned. Some process is going to get in the way of making money? I don't think so.

The it's not Scrum.

That's why it only works properly when there is FULL buy-in from the C-level down.

EVERYONE in the company must acknowledge that there is a clear process on how to get new features implemented and randomly barging into the team space demanding features is not it.

But I don't need Scrum to get buy in of non-shitty processes from the C-level down. I have that already without Scrum. Clearly people are doing Scrum that is awful. So it's neither a necessary nor sufficient property of Scrum itself.

I agree that not having management/sales directly involved in low-level development planning is a good. But that's not Scrum.

I have seen multiple teams using scrum and not a single one of them was happy. Members of literally every one complained when having a safe option to complain.

Scrum is widely disliked by people who work on teams. It is liked by managers and consultants.

I haven't read the article but in response to your comment here:

Scrum is widely used and also widely disliked. I find that apologists for scrum generally excuse the dislike as 'that's not how scrum is supposed to be implemented' - just as you have here. It's exactly the same form of argument you get from apologists for Marxism or Communism when confronted with the widespread dislike for those systems. If something has generally failed wherever it has been implemented, it's not because it hasn't been implemented properly, it's because it is fundamentally broken.

What I said is much more nuanced. I certainly wouldn't call myself a scrum apologist.

There are good implementations of scrum, and there are teams that like it. In my experience across companies and industries, it's a much larger percentage than unfounded comments like yours and the article would lead you to believe, perhaps 30-40%. Probably due to the SV slant on this site (also why people here always think they know everything). It absolutely has not failed everywhere it's been implemented, and starting from that position is simply incorrect.

My position is that the article (and you) are making incorrect assertions and that you don't even consider that it's a possibility.

Again, your experience is not universal. Stop claiming or thinking that it is and that you know everything. You don't.

I have seen excellent scrum and bad scrum.

I've been on teams where we got to pick what we could deliver in a sprint and utter peace to do it for 2 weeks. Daily scrums were mostly skipped and lasted 5 mins max while we had our morning coffee, standing up.

I've been on a team where "daily scrum" was a 30-60 minute daily Skype call with no agenda, goal or point. The only thing related to Scrum in that company was the terminology, basically a cargo cult.

I've also been on a team that used scrum terms and kinda sorta the process but it was closer to Kanban with releases. But it didn't matter, everyone on the team had 15+ years of experience.