Live data from Hacker News

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

stackoverflow.blog

161–170 of 223 posts

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

#161
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 agree with this point of view. In my opinion, one of the greatest fallacy of Scrum and some agile methods is: "Another note on breaking down tasks into chunks" This is the management trick of "divide and conquer". But for real good dev, that is not a good development process. Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned: If you were in a…

As a follow up, nothing in the Agile Manifesto says that the process is important to ensure that a "developers" is not essential and can easily be replaced:

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

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

#162
post #125
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. If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this…

inherently dicatorial culture of corporate governance

Exactly. There's no point in blaming scrum for problems that are ultimately rooted in your corporate culture.... because those problems are going to (re)-appear no matter what methodology you adopt!

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

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

That's just it though: the fact that Scrum only works given this perfect "no management" ideal. It might work as a lightweight set of guide-rails in a self-motivated, experienced team which has 100% hands-off trust from management, but I'd argue that in that perfect-unicorn case Scrum is not the key to success but rather the fact that you have a good team and good management. In practice - as you are finding - this combination is very rare. Furthermore I'd argue that in the typical company with typical management, Scrum will lead to even greater micromanagement and overhead, and might actually be worse than, say, some version of ad-hoc Kanban-lite.

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

#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 framework to then, through inspecting and adapting, add what works for that team (and no other team) and discard/replace what doesn’t through experiments and retrospectives.

Does that sound like it’s liberating for engineers or something that ruins them?

Note: Kanban is also not a process but a system for continuous improvement. 99% of teams doing that are doing it wrong too most likely.

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

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

>that ideal software development is just a continuous production This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !

One think I havent read being mentioned on this thread is how Scrum discrete sprint units allow the dev team to focus in a task for some time.

I have been in both "sides" of scrum (dev and manager) and it is good not to have objectives changed every days. As a manager I even have had to split a scrum team in two (scrum and kanban) to maintain devs sanity.

Kanban is my preferred PMing process but only if there are defined "cutout" periods to perform releases or a CI/CD cycle.

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

#166
As a vendor of thought leadership, it's 100% in my interest to treat as exogenous the likelihood that my framework / best practice / etc will be implemented as I intend it to under ideal circumstances.

As a consumer of thought leadership — a sensible and responsible one, that is — I'm compelled to treat such concerns as endogenous to the framework / best practice / etc, and predict outcomes accordingly.

"You're doing it wrong" doesn't explain anything. At best it's the start of a conversation, at worst it's intentionally used to elide the costs of whatever it is you're selling.

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

#167
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-released open source libraries, etc. Other teams are building the nth iteration of some CRUD application that amounts to a database, some REST API's built using Spring Boot, and a UI built in React, where today's work isn't (usually) that different from yesteday's work.

Depending on which end of that spectrum your project falls on, it would make sense that the details of the methodology you use would need to vary.

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.

Unfortunately, I have found that few shops take either of these factors into account.

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

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

The amount of hours our team has wasted on estimating, re-estimating, splitting up stories, simply to make our burn down chart look great is amazing. We would often be forced to split up stories the day before a sprint review, just so that the chart would look like things have progressed, while in reality nothing was completed. Our sprint planning sessions were a FULL DAY, yes, an entire 8 hours of planning. Because…

I have suffered through those sprint sessions of hell.

What has worked for me is the following:

- let the most sr tech person ("the architect ") refine the stories maybe with the PM. Then, the same person will point the stories. - The sprint planning is only for presenting the stories to devs and giving some minor adjustments to the points if necessary - The architect may deep dive with a dev for a certain task while pointing it. - That way we have a standard complexity measure. We know different devs will perform different amount of points per sprint . We dont lose time in pointless neverending discussions - it also works well in Mexico where people are not so vocal so the standard poker planning doesn't go well

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

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

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 concern half the team, and the scrum master won't politely interrupt and ask them to schedule a separate meeting. So much time has been wasted by this that it's unbelievable."

I have never scheduled a separate meeting to continue the discussion.

Why not?

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

#170

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 they are therefore Agile), any canned process will be at most a starting point and input into what works for your team. But that is very much not Scrum as it has been propounded from the beginning, including by it's creators.

> Kanban is also not a process but a system for continuous improvement

Kanban is a very specific process element related to flow visibility and management.

Post reply on HN