Live data from Hacker News

Does scrum ruin great engineers or are you doing it wrong?

stackoverflow.blog

81–90 of 223 posts

Re: Does scrum ruin great engineers or are you doing it wrong?

#81
post #57
post #18

Very productive individuals that don’t work as a team I refuse to have those people on my team. One person who's twice as productive as everyone else sounds great, but if that person's work doesn't fit well and makes everyone else's work harder it always been a net loss in my experience. I'd prefer my team works well together than have some "brilliant loner" join it.

I've seen my FAANG division manager use brilliant loners quite effectively by requiring them to be remote. They don't join meetings or really check in with anyone but every six months they pop up and say "I re-architected System X and now it can handle 10,000x as much traffic" or something like that.

That sounds like a nightmare. How did they handle things like being on call? Was the loner responsible for their genius 24/7?

Re: Does scrum ruin great engineers or are you doing it wrong?

#82
post #34

We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because i…

>idea that ideal software development is just a continuous production of small improvements to the code. Many of us do believe this. Absolutely. >It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. But on the flip side, if you get it wrong you waste an inc…

> The smaller the steps you take, the smaller the risk you step in the wrong direction.

This is the route to local maxima.

Re: Does scrum ruin great engineers or are you doing it wrong?

#83
post #58

Earlier quoted context omitted.

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload. On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen? Planning…

> One of the one hand, the development team getting to control the estimate helps to control the workload. I think that's a kind of waterfall strawman. In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.

> In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.

I studied engineering in university and profs had plenty of stories about bosses sending business analysts to look at similar projects, generating a time estimate from those projects, and then send that estimate to the engineers as their deadline for completing the project.

It being insane doesn't stop people.

Re: Does scrum ruin great engineers or are you doing it wrong?

#84
Very few people care to read the official Scrum documentation. It is not a long read. Some posts on HN have more words than the Scrum Book.

As a result of not reading the documentation, not many understand what Scrum is and what they're criticizing. I have been in that situation myself at some point. One day, I found myself so frustrated that I read the Scrum book over and over again until I could complete the certification assessment with passing score, just to understand if Scrum was to blame for the problems I perceived.

What I learned in the process was that scrum does not recognize the role of a project manager and it does not make distinctions between development team members. The development team is defined as self-organizing and empowered to make decisions to a very reasonable extent.

The problems described here often start when some the self-organization and autonomy of the development team is taken away. This can take many forms, like adding roles like project managers or by redefining existing roles, such as making the scrum master role absorb responsibilities from the development team.

Those adjustments are suboptimal and almost inevitably result in an imbalance of power between product and engineering, and that's a really bad idea that will often result in engineering disasters.

Some companies create engineering holidays such as hackathons, where engineers can take the time to work on neglected aspects of projects. But then, in many companies, product people have started to intervene those events as well, perpetuating engineering frustration.

Re: Does scrum ruin great engineers or are you doing it wrong?

#85
post #41

(The linked article is a piece of content marketing and not the reflections of an individual expert in the field.) Typically for this type of article the merits of "Scrum" are debated without Scrum first being defined, thereby making any reasonable appraisal impossible, and inviting a "your doing it wrong" conclusion. At this point I am genuinely unsure whether this is some sort of master-level content-marketing trol…

It's a decent article.

Defining "scrum" in a debate-club fashion here is meaningless and is actually a valid strategy to discredit any criticism of it.

1. Scrum being a "philosophy" itself isn't clearly defined.

2. Different orgs practice Scrum differently, hence the more specifically you define Scrum, the less of the practice falls under that definition.

3. Best definition in this context is "set of practices most orgs call Scrum", which might as well be omitted.

And all of that has no bearing on the fact, that if team leadership busts out Scrum boards and Jira tickets more often than discussing problems, teaching/promoting knowledge and figuring out the best product design, then it's probably a mediocre shitshow.

Re: Does scrum ruin great engineers or are you doing it wrong?

#86
Complicated tasks get deprioritized

Features over robust code

An effect is "birth defects are forever". An early design mistake is very difficult to correct in a scrum-like "agile" process. The incremental nature of the process favors patching around it.

This is OK for webcrap, but not OK for systems that have strong internal consistency or time constraints.

Re: Does scrum ruin great engineers or are you doing it wrong?

#87
post #79

Earlier quoted context omitted.

I hear you. When Michael Jordan was an asshole to everybody, I hear they refused to have him on The Bulls and won multiple championships without him. Remember how The Beatles decided it's not worth it and didn't make any music? What a great decision by them, nobody would remember them long after they're gone anyway. When I look at giant corps with their HR departments and filtering out of anyone who isn't a 'team pla…

You're getting downvoted but I think you make a valid point. Brilliant loners can be really useful for a business. They're the visionaries. They're the ones who change industries. But imagine having Steve Jobs on your team, and trying to get the best out of him within the constraints of a project. It'd be impossible. Brilliant people like the ones you've listed need to be the ones leading. That's why I don't want the…

Yeah, but now you're most likely leaving the field of software engineering and are going higher up the promotion ladder.

Re: Does scrum ruin great engineers or are you doing it wrong?

#88
post #34

We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty). I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because i…

>idea that ideal software development is just a continuous production of small improvements to the code. Many of us do believe this. Absolutely. >It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. But on the flip side, if you get it wrong you waste an inc…

I am fine with the small improvements to code part, but I at least want an idea of where I am going. Small improvements to solve the problem? Sure. But I at least want an idea of what the entire problem is, not just the two weeks of problem shards I am given.

Re: Does scrum ruin great engineers or are you doing it wrong?

#89

The only right way to do 'great engineering' is by not having any middle management. The only right way to do great engineering, is by first asking what we ought to be engineering, not re-implementing the same shit over and over again, like we do web frameworks in every new language. Great engineering is completely unrelated to scrum. It is only in the delusional mind of a middle manager that his existence and though…

You'll have to define middle management, if you're including product management, then your statement would be pretty contradictory.

Can't know what you ought to build if to don't know what your customer wants.

Re: Does scrum ruin great engineers or are you doing it wrong?

#90
post #57

Earlier quoted context omitted.

I've seen my FAANG division manager use brilliant loners quite effectively by requiring them to be remote. They don't join meetings or really check in with anyone but every six months they pop up and say "I re-architected System X and now it can handle 10,000x as much traffic" or something like that.

That sounds like a nightmare. How did they handle things like being on call? Was the loner responsible for their genius 24/7?

No, basically the group managers assigned the “architecture astronaut” tasks to these brilliant loners. They would figure out the answer and then be assigned to a team to onboard them basically, they’d come into the office for a week or two to do design reviews, go back to being remote to get the stuff into production, and then the full crew would own the service and the loner would go to the next thing.
Post reply on HN