Live data from Hacker News

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

stackoverflow.blog

191–200 of 223 posts

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

#191

Earlier quoted context omitted.

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

The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that: "Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't…

If a useful discussion happens during a standup the people discussing can just leave and let the others continue the standup without them. There is no point in being strict with these things.

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

#192
post #90

Earlier quoted context omitted.

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.

Interesting. How did the team feel about being maintenance people? I think I'd have found it a bit demoralising if someone gets parachuted in to work on the - I assuming - interesting stuff.

The team didn't become maintenance people. Basically the architecture astronaut did the first 6 months of 2-3 year projects. And everyone knew that they were geniuses, maybe there was a little grumbling but people got on board.

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

#193

Earlier quoted context omitted.

They are certainly part of Scrum-master training. I am certified as a Professional Scrummaster, and none of those things were taught as part of any training I went through, nor were they mentioned on the certification test. Referring to definitions is useful, when many people are misunderstanding the definition. If anything, we should be screaming from the hilltops "For the love of FSM, go read the Scrum Guide, and t…

Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team. Looking at 'scrum master certification test questions' online I don't see anything about technical debt, variable-length time boxes, re-prioritizing work during a sprint etc. A real and reasonable criticism of Scrum or…

Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.

That seems orthogonal to the question of how desirable (or not) scrum is. You can have scrum (or not), and/or have "an experienced team that respects the other team members to plan their time and prioritize tasks" and shitty management is still going to wreck things.

A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work.

I 100% agree that there are times when the structure imposed on a team in the name of Scrum (whether it's actually prescribed by Scrum or not) is harmful. Don't mistake what I'm saying here as a massive endorsement of Scrum. It's not actually my preferred methodology. But I do think Scrum can be useful to very many teams in very many situations, and I feel like a lot of the criticisms directed at scrum are somewhat misplaced.

If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.

I think I get what you mean by that, and I probably agree to a point. But I don't think it's quite "No True Scotsman", as Scrum has an actual definition, to an extent that "true Scotsman" does not. But I'll buy the suggestion that "if everybody is doing it wrong, then there's something fundamentally wrong with the whole situation".

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

#194

Earlier quoted context omitted.

The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that: "Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't…

If a useful discussion happens during a standup the people discussing can just leave and let the others continue the standup without them. There is no point in being strict with these things.

Agreed. I was just curious about why, specifically, the parent poster never schedules follow-ups. If the discussion in question was actually valuable, it seems like they would want to pick it up later (or use your approach of just forking off immediately. I look at those two things are being approximately equivalent).

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

#195

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…

> Nearly every other aspect of how work gets done is unspecified

No, it's not, the whole classic litany of scrum rituals (“scrume events” in the guide’s language) is prescribed in the Guide.

> Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually.

That’s strictly true, but somewhat misleading, as while it doesn't mandate two-week sprints specifically, the guide does specify that sprints are not more than one month. (And that they have “consistent duration throughout a development effort”, which is probably a more problematic command. But the most problematic is using synchronized iterations rather than flow for dev work, and locking the time cycle for product iterations to the time cycle for process improvement.)

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

Yeah, they are an attempt (and, used as designed, probable the best attempt yet) to deal with a well-documented hard problem un software development which Scrum just assumes is, and requires to be, solved without really commenting on directly. I have far less complaints about them (except that people cargo cult them badly) than Scrum, which, while also subject to bad cargo-culting, has a lot of it's problems baked into the fundamental spec.

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

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

> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.

Well, I think that Scrum (or, more widely, agile) can in fact be done "right" - done in a way that works well. So in one sense, "you aren't doing it right" is in fact a correct statement.

But then you look around, and you see how often it isn't done "right". If something is almost impossible to do "right", then yes, there may in fact be a problem.

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

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

In fact, scrum is something the messed-up management has tried to use as a magic bullet, rather than actually fixing themselves.

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

#198

Earlier quoted context omitted.

Agile builds on the premise that developers like to build. That we self organize our teams and don't like slackers. Bring transparency for business so it can trust us. Give estimates and accept priorities. Ship from time to time so all can see that process works. It is really easy to screw. I've seen far to many broken versions. Community building is harder than management. And for management there is no benefit besi…

You'd think products shipped on time as agreed with the customer was a benefit for management.

I thought same. I fought for roll out in time, velocity and quality. Now I'm burned out. PM had his own agenda - introduced a men who, he was like 1/10x developer on senior position, promised to fire in a few month, have not happened in a year and a half, this destroyed velocity and as tech lead I was blamed. I stayed so long because our customers were awesome, could not leave them.

Managers are not friends. The moment I've said I'm leaving I become nothing. Time to learn.

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

#199
post #155

Earlier quoted context omitted.

No True Scrum again...

Look, I've had good experience with SCRUM team. Later I've been searching for work, "SCRUM", interesting, interview, what? PM? Another place, PM? Yet another... I have not found. They would not tell that it is not SCRUM before interview. And oh, they failed so miserably, I knew how it works but couldn't do anything. It is regress. So often it is PM who destroys project. I've seen good PMs. Two. Great guys. Great mana…

> So often it is PM who destroys project.

How true! In my 30 years in the industry, I haven't experienced a single PM who was a net-positive (though I've heard that some are awesome), and some that simply made no positive contribution whatsoever.

I had one program manager who was awesome, even though we certainly didn't need a program manager (~40 person startup) per se. But she realized what was going on and then kept the PM (and everyone else) off my back so I could get the job done.

First and AFAIK only time in that company's history that a software project was delivered on-time.

Of course, after we shipped, it was all "congrats, but now you must do things properly like the rest of the company".

Not sure whether that's "sigh" or "LOL" or ¯\_(ツ)_/¯

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

#200
post #108

Earlier quoted context omitted.

Beatles/music analogy rather backfires, no-one remembers Paul McCartney albums or Freddie Mercury solo projects. I could spend years listing bands that have split up, the lead singer or guitarist tries to go solo, utterly fails, band goes for reunion tour 10 years later. It's a known band cliché. A large software project is a lot of hard work of basically a bunch of people trying to write a story together. It's diffe…

Counterexamples: John Lennon, Sting, Eric Clapton, Neil Young, Phil Collins, Lou Reed...

They're the exceptions to the rule, the converse happens far more often.
Post reply on HN