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

111–120 of 223 posts

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

#111

Post by watwut »

jjav wrote: post #40
watwut wrote: post #27

Earlier quoted context omitted.

I think that Scrum leads to resignation for many people, because it takes away control out of individual and insists on everything being collective. So your personal options to improve or make decision becomes severely limited. Some people like it, because it allowed them to push themselves on the rest of the team. But people who dont thrive in such constant dominance conflict end up resentful and helpless.

That's an insightful concise description of "agile" experience. As an anecdote, I have an acquaintance who is a psychologist in silicon valley and he has mentioned he frequently works with patients suffering from mental health issues related to being subject to "agile" at work. I wish someone would do a proper study on this topic. Personally, agile hasn't driven me to depression but it has made me target roles that a…

I found that testers in particular find agile off putting and some avoid working at such companies if they can. I am not sure why testers specifically end up disliking that.

I think that agile ignores human psychology. First, in management theory, intrising motivation happen when one has autonomy, mastery and purpose. Imo, plus accountability. Agile removes that from individual, but has some rhetoric that places it on the "team". But team is not person, it is set of people.

Second, it kind of assumes that people are socially perfect and everyone is kinda the same and its answer to any social human problem is "that is team dynamic or bad individual". It does not help to deal with predictable human imperfections, emotions and conflicts.

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

#112

Post by wirrbel »

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…

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss.

Curious about that point because for many engineering tasks the variance in the estimates is so big that I wonder whether any formal way of estimation actually works. I did some analyses on the correlation between estimate and actual development time in a project I worked in and the correlation wasn't really there. Sure, there was a difference for the very large work items and the very small one but overall the estimates were fairly useless, especially when it came to anything that touched operations. I just googled formal methods for estimation in order to see what you might mean by that and nothing appeared to be something I'd assume to be more powerful (a priori) due to my lack of confidence in workload estimation overall.

Note, btw. that the Scrum Guide doesn't make any mention of estimation at all, neither prescribes it nor disallows it, just says that the team should plan a sprint (roughly speaking). Even the typical "story point estimation" stuff that people think is attached with Scrum, its more of an XP practice that has been carried over.

Personally I think that Scrum took a weird turn in its lifetime with Sprints becoming shorter and shorter to the point where there can be no meaningful work (with customer benefit / demoable in the sprint review) be completed within a Scrum. Maybe its possible to ship a couple of CRUD-website-features within 2 weeks, but for the B2B software I am working on a feature is too complex for 2 week cycles. And if your tasks are small enough to fit into two week cycles, why aren't you doing Kanban?

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

#113

Post by someguyorother »

jay_kyburz wrote: post #68
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…

>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…

>>idea that ideal software development is just a continuous production of small improvements to the code.

>Many of us do believe this. Absolutely.

Isn't Jeffries' attempt to do Sudoku with TDD pretty much the prime example that it's not always so?

Jeffries tried to write a Sudoku solver by starting from tests and incremental improvement, and got nowhere. Norvig knew about constraint propagation and did it in one go.

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

#114

Post by tragic »

MattGaiser wrote: post #53
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…

> 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…

> Why are we being asked how long it will take to do work in sections of code we have never seen?

It is common enough for those packs of estimation cards to include one with a question mark on it, to denote the "I can't estimate this sight unseen" scenario. The reason it's common is because often people are presented with stuff that isn't well-understood enough, and it's a very good idea not to pull a number out of one's rear in those situations. Don't be afraid to use that card (or do the equivalent and just say so).

If you are afraid because you will be marked as 'not a team player' or whatever, you have management culture problems that neither Scrum nor any other imaginable software development process will fix on its own. They will all end up feeding an idiotic garbage in/garbage out cycle of overpromising, crunch, burnout and general misery, with the superficial appearance of whatever process it was supposed to be.

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

#115

Post by sergeykish »

jyriand wrote: post #91

What i don’t like most about scrum is the sprints. Doesn’t matter if it’s one or two weeks long, we never have a successful sprint, the velocity chart looks like random numbers, and we spend hours on debating what the story points really mean. Sprints are artificial deadlines that don’t really make any sense, developers don’t care, business people don’t care. A project i could complete in a month will take at least t…

SCRUM highlights project management problems. If everything works its only overflow is a two hours boring retrospective. Morning meetings is 5 minutes maximum (status ok), estimation - about an hour. Last sprint day is a lazy day - no new tasks allowed, refactor what you can, make presentations etc.

Never heard of successful one week sprints, two weeks looks optimal. Sprint purpose is to show there is no hidden debt ("almost done, oh, no, three weeks more"). Roll out is a bonus.

Failed sprint should be an exception. It as marker, to resolve it you have to resolve real issues:

* team got to much points to implement properly

* no need to fight on story points, ±1 should not matter much

* you can't have two week story, commit something

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

#116

Post by WalterBright »

ckastner wrote: post #94
WalterBright wrote: post #72

Earlier quoted context omitted.

You just gotta trust that your top guys know what they're doing and let them do it. It's how Lockheed let Kelly Johnson run the Skunkworks however he wanted to. Johnson delivered the impossible again and again, and Lockheed was smart enough to not interfere.

I'm not entirely convinced that Johnson's example generalizes well. He might just represent an instance of survivorship bias. Some people can be brilliant at something while at the same time being toxic, with the toxicity ultimately winning. Kalanick at Uber might be an example.

Lots of companies have tried to establish a skunkworks, but with "improvements". None have done particularly well. (The "improvements" were taking away the autonomy of the skunkworks.)

https://en.wikipedia.org/wiki/Skunkworks_project

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

#117

Post by Supermancho »

js8 wrote: post #77
jay_kyburz wrote: post #61

Earlier quoted context omitted.

>Planning could be far more accurate if we just got a proposed task list a day before planning. Why don't you work that in to your process. It's called Agile for a reason.

Why don't they put it into Agile books? They're called books for a reason. Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it. It's a return to medieval times, where all the expertise was just the experience of the…

> Why don't they put it into Agile books? They're called books for a reason.

Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team.

In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.

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

#119

Post by seer »

irrational wrote: post #103
js8 wrote: post #56

Earlier quoted context omitted.

I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day. In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up,…

> and then these design decisions are vetted (and possibly changed) by everyone in an open discussion But don’t you dare try to have an open discussion at a stand up meeting. The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Honestly, that just kills the flow of communication. I have never scheduled a separate meeting to continue the discussion. We ju…

That sounds overly harsh. What we do in our team is "postpone" those discussions. When people have went through their updates, anyone who wants to stay is free to do so and can continue that discussion, usually in the same channel. This way you're not forcing people who _don't_ want to listen to that discussion to sit through it twiddling their thumbs - best of both worlds :).

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

#120

Post by C1sc0cat »

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 the obsession with tickets /Jira as the be all and end all of SCRUM is the main problem.

What is lacking in a lot of cases is an overall vison and plan for the desired end state -

I have seen doing a classic waterfall design stage with a RAD/AGILE/DSDM/SCRUM development stage right at the end work well.

Post reply on HN