Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

stackoverflow.blog

Post reply on HN
Print view View original

171–180 of 223 posts

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

#171

Post by xtracto »

onion2k wrote: 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 have had someone in my team with some autism (diagnosed). The dev comes up as a VERY shy person who would barely talk during standups. Still a great developer and I love her to be part of my team. Even if interaction is different.

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

#172

Post by sergeykish »

greatgib wrote: post #160
sergeykish wrote: post #140

Earlier quoted context omitted.

You know you've described the opposite of agile approach, right? "management", "file by file, function by function", "exchangeable and a commodity"... at least not what agile was ten years ago. Actually the points in favor of agile were: * utilize persons strong points * reduce management * reduce burden * improve working environment

I agree also with your point. The real agile as of the "Agile Manifesto" has the spirit of what is good dev in my previous message. But was is used today as "agile", "agile in business", agile in real use, and especially Scrum is not what the Manifesto asked for, quite of the opposite in the end. That is even why some of the creators of the agile manifesto backed off when they saw what it became. In fact, at the mome…

I've seen it in work. It was very emotional when our Scrum Master left, we've got another one and he was great, but it has not felt same. This may be the biggest Scrum issue.

I've seen unreal Product Owner, it was so much pleasure to work with. Ever since I've found a joy in filling this niche if it was empty.

Yes, Agile Manifesto, Scrum is just some tools. It is like blaming axe [0] in Armenian cartoon.

[0] The Axe (1994), no speech https://www.youtube.com/watch?v=mA7H5KnyzJk

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

#173

Post by mindcrime »

usrusr wrote: post #63
remontoire wrote: post #60

Earlier quoted context omitted.

what does YADIW mean?

"You are doing it wrong", the first and last thing any scrum believer will say to someone for whom it does not work.

And in a great many cases, when you dig into the details, it turns out that they are - in fact - doing it wrong. Or at least blaming scrum for things that scrum does not actually entail. Or blaming "agile" for things that are 100% contrary to both the letter and spirit of the agile manifesto.

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

#174

Post by xtracto »

Animats wrote: post #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.

I disagree with this sentiment, well at least I disagree that it is SCRUM's fault. I think this is a problem that resides higher up.

I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt (or 20% tech debt, 20% product debt with a 30-30-20-20 split).

With this I try to show that the problem of development teams NOT fixing their crap i not an issue of the Agile/SCRUM process (or any other process), it is an issue of management that prefers to ignore the mounting technical debt (until it explodes and you have the Github downtime, or LinkedIn leaks or the fact that changes become slower and slower due to codebase complexity).

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

#175

Post by JoeAltmaier »

xtracto wrote: post #174
Animats wrote: post #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.

I disagree with this sentiment, well at least I disagree that it is SCRUM's fault. I think this is a problem that resides higher up. I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt…

Hm. That sounds like a process issue. Which is what SCRUM etc are part of. So its not process, but changing process will fix it? SCRUM + technical debt management is the cure? Then SCRUM was missing something.

I put the blame squarely on the process, whether its SCRUM or whatever.

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

#176

Post by mindcrime »

dragonwriter wrote: post #170
richliss wrote: post #164

99% of teams are doing Scrum wrong most likely. Scrum has been ruined by many different groups (large consultancies, certification bodies, the misinformed, bloggers etc.) and there is a movement called the Scrum Pattens movement trying to fix the damage and to make it more explicit. If you want to do Scrum properly read “A Scrum Book”. Scrum is not a process it’s process design framework- you start with Scrum as a fr…

> Scrum is not a process it’s process design framework Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Now, if your approach was actually Agile (unlike the many groups that do Scrum, either as defined in the Guide or some variation they've cobbled together from other sources and still call “Scrum”, and think that by doing so th…

Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework.

Scrum as defined in the Scrum Guide prescribes very little. It's not much more than "Have a development team, a scrum master, and a product owner, have a product backlog, have developers plan their work, and work in time-boxed increments." Nearly every other aspect of how work gets done is unspecified and can (and should) be evolved by the team based on empirical observation.

My observation is that people have a tendency to adopt a version of scrum that is based on certain "default settings" that everybody sort of assumes are required, when they aren't actually. Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually.

Or people complain about "velocity", and "story points" which are likewise not part of scrum at all.

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

#177

Post by dragonwriter »

mindcrime wrote: post #167
js8 wrote: 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…

I think in reality, SW development done right is nothing like that. I would argue that it's more correct to say something like "Not all software development done right is like that." Or in other words, some software development is closer to that model. Some teams are doing work that involves real "invention", things that require using cutting edge C.S. research, implementing algorithms from papers, or using just-rele…

> I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work.

I think this is basically true but incomplete; early and late are misleading a bit, because it can be early in the life of a product that is in a well-explored space and it will look “late”, while a product can experience change in requirements or external context which makes it look “early”. A product should expect to move between modes multiple times if it is long-lived.

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

#178

Post by JoeAltmaier »

mindcrime wrote: post #176
dragonwriter wrote: post #170

Earlier quoted context omitted.

> Scrum is not a process it’s process design framework Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Now, if your approach was actually Agile (unlike the many groups that do Scrum, either as defined in the Guide or some variation they've cobbled together from other sources and still call “Scrum”, and think that by doing so th…

Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework. Scrum as defined in the Scrum Guide prescribes very little. It's not much more than "Have a development team, a scrum master, and a product owner, have a product backlog, have developers plan their work, and work in time-boxed increments." Nearly every other aspect of how work get…

They are certainly part of Scrum-master training. They're a widespread practice. At this point, they can be grouped as 'part of Scrum' with fair confidence, in any implementation you can point to.

Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.

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

#179

Post by mindcrime »

watwut wrote: post #110
riffraff wrote: post #39

Earlier quoted context omitted.

what control do you feel is taken away from individuals? I mean, you discuss tickets with the rest of your team, but that doesn't seem such a big loss of freedom.

All the control and all the autonomy I would say. There is nothing I would be responsible for where I can make own decision and have them right or wrong. In the teams where I liked to work, I felt control over order in which I do tasks and general shape of something I was responsible for. So I could make my own decisions, decisions that would be really mine. So when there was mess or something was late, it was my fau…

So what process are you advocating for over scrum, that would restore this control and autonomy to you?

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

#180

Post by mindcrime »

fjfaase wrote: post #23

Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity. I also have seen that often it…

Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity.

BINGO. The "problem with scrum" isn't usually scrum itself, but the management and culture of the company. And bad management and toxic culture will, in my experience, lead to the same results no matter what process / methodology you nominally employ.

To me, most criticisms of scrum reduce to a (legitimate) claim that "scrum isn't a magic bullet that will fix the fucked up management and toxic culture at this shitty company."

Post reply on HN