Live data from Hacker News

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

stackoverflow.blog

41–50 of 223 posts

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

#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 trolling which is expertly crafted to goad engagement from senior engineers, or whether it is just sloppy, misguided, business-school nonsense.

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

#42
post #9
post #7

How about letting developers pick or come up with their preferred way of working instead of mandating Scrum?

The only potential result of a competently run scrum process is exactly that - a process that was designed by the team. If you are stuck in some weird cargo cult that doesn’t allow the team to iteratively change the process, you should call bullshit.

If scrum is any process designed by the team the term is worthless.

Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile.

Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway.

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

#43
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.

Yup, I'm not fan of the 10x-programmer moniker. The true 10x-ers are those that multiply those around them by a small factor in some way. If you can help all the members of your team to be 10% more effective, that has a bigger impact than even working twice as fast.

Or find ways to reduce the workload. For instance by questioning if the feature really is worth making that complex.

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

#44
As a manager you should think hard about what aspects of scrum are important to you and where you can let loose. This will heavily depend on the makeup of your team - how many experienced developers are there who don't need hand holding? How many of them will still deliver without some oversight? How many of them can mentor? How many inexperienced people do you have, how many will be onboarded in the next year? Things like that determine and change your development process.

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

#45
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.

[deleted]

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

#46
In my company we hired a CSM (certified scrum master) and we definitely did Scrum by the book. But we didn’t do it right, in the sense that after 2 years our productivity was worse than when we started.

In my experience, Scrum can easily become a series of little waterfalls, rather than bring a flexible and needs based approach to building complex products. This lead me to see that Scrum is not really Agile, where by “Agile” I mean [0]. Scrum is a process and Agile is a mindset. Some teams are able to hold both ideas in their head at the same time. But in my experience across multiple large customers and projects, teams think that by doing Scrum they are being Agile, and this is not the case at all.

Scrum is no more a solution to the social and political problems of a project than is waterfall or the spiral model (which Scrum mimics IMO) or anything else. A good team will succeed regardless of the project management methodology and a bad team will most likely fail.

Scrum is not the problem nor the solution. It’s management’s job to ensure that the teams are working well, that people have room to succeed and fail, and that the project management methodology suits the needs of the project. That’s certainly where I failed my business for a few years, until I worked it out.

[0] https://agilemanifesto.org/

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

#47
post #44

As a manager you should think hard about what aspects of scrum are important to you and where you can let loose. This will heavily depend on the makeup of your team - how many experienced developers are there who don't need hand holding? How many of them will still deliver without some oversight? How many of them can mentor? How many inexperienced people do you have, how many will be onboarded in the next year? Thing…

> what aspects of scrum are important to you and where you can let loose.

Scrum explicitly does not permit that. A criticism that didn't make it into that answer.

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...

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

#48
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.

As long as they aren't toxic, if you can't get the best out of brilliant loners, then, you don't deserve them, or possibly don't really need them. My experience is if the team culture is good, then they can fit in and you can accommodate their working style

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

#49
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.

Actually the brilliant loner should be the norm (to have one), not the exception. If you believe in the 20:80 rule, that 20% of the people to 80% of the work. This rule doesnt sound so bad but actually (lets take these numbers as strict and not as a probability distribution). It means your top perfomer are 16 times more productive than the lower performers. Lets say you have a team of 10 people doing 100 work units. So 2 do 80 work units which is 40 per person, and 8 do 20 units which is 2,5 units per person.

Of course you could say this principle does not apply to your team (good luck!)

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

#50
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.

Yup, I'm not fan of the 10x-programmer moniker. The true 10x-ers are those that multiply those around them by a small factor in some way. If you can help all the members of your team to be 10% more effective, that has a bigger impact than even working twice as fast. Or find ways to reduce the workload. For instance by questioning if the feature really is worth making that complex.

As a team lead, this is the approach I try to take. I spend most of my time tackling the problems that are blocking other team members from getting work done. It's not sexy but keeping 3 guys working is more valuable than me getting to work on feature work. Sometimes the things that are blockers are the more interesting challenges and sometimes it's just frustrating bugs, but either way it's satisfying to me when I see the team cranking through our assigned feature.
Post reply on HN