Does scrum ruin great engineers or are you doing it wrong? • Hacker News Board

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

#131

Post by meheleventyone » Tue, Jun 30, 2020, 9:56 AM UTC

WalterBright wrote: post #116

ckastner wrote: post #94

Earlier quoted context omitted.

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

I've also seen it fail the other way where the Skunkworks becomes the preserve of "high achievers" not producing a lot that's useful. Almost every 'Office of the CTO' I've seen has suffered that failure mode. Lot's of things get built but none are more than fluffy experiments and there's no path to actually putting any of those things into production. Once in a while they'll be forced through and the production team has to spend a lot of effort fixing and making the project actually work.

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

#132

Post by leto_ii » Tue, Jun 30, 2020, 10:00 AM UTC

kevsim wrote: post #36

I interviewed a long time ago at a med tech company in Boston where Jeff Sutherland, one of the inventors of scrum, was the CTO (I believe). I had recently been through scrum master training at my current job and was quite keen to see how scrum was applied in the place where the guy who invented it was working. I asked my first interviewer how they used scrum on their team and his answer was that they didn't use scru…

This reminds me of the anecdote about Harry Markowitz, the originator of what is called modern portfolio theory (which supposedly tells you how to allocate your money efficiently). When asked if he applied his theory IRL he said something along the lines of: Hell no, I just put a third in stocks, a third in bonds and a third in cash.

I think a theory of any kind that is not applied IRL by its creator should be seen with great suspicion.

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

#133

Post by secondcoming » Tue, Jun 30, 2020, 10:01 AM UTC

ponker wrote: post #90

secondcoming wrote: post #81

Earlier quoted context omitted.

That sounds like a nightmare. How did they handle things like being on call? Was the loner responsible for their genius 24/7?

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.

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

#134

Post by christophilus » Tue, Jun 30, 2020, 10:04 AM UTC

kevsim wrote: post #36

I interviewed a long time ago at a med tech company in Boston where Jeff Sutherland, one of the inventors of scrum, was the CTO (I believe). I had recently been through scrum master training at my current job and was quite keen to see how scrum was applied in the place where the guy who invented it was working. I asked my first interviewer how they used scrum on their team and his answer was that they didn't use scru…

Part of the scrum retrospective involves a process review. You look at what is and isn’t working, then evolve your process accordingly. Sounds like that team decided that scrum wasn’t working, which means they used the evolutionary aspect of scrum as it was meant to be used. That focus on improving processes is the best aspect of scrum in my opinion, and the least used in my experience. Today, I mostly work on my own and am self directed, and boy... I don’t miss working in those old structured environments.

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

#135

Post by ckastner » Tue, Jun 30, 2020, 10:04 AM UTC

WalterBright wrote: post #116

ckastner wrote: post #94

Earlier quoted context omitted.

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

I'm not arguing against the autonomy part, on the contrary: I join you in arguing in favor of it, and also that such an autonomy requires a brilliant personality at the head of it.

However, while the combination of autonomy and brilliant personality might be a prerequisite of outstanding success, I'm not yet convinced that it's an overwhelming indicator of it. I believe that a brilliant but toxic personality with autonomy can lead to an ultimately fatal instability.

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

#136

Post by leto_ii » Tue, Jun 30, 2020, 10:05 AM UTC

> Build a team to do scrum, don’t expect scrum to build your team.

This is a very important takeaway I think. A development methodology can work to organize the processes of an already (relatively) well working group. Expecting process standardization to fix dysfunctional human interaction is just putting the cart before the horse. Scrum will not build trust between coworkers or between workers and management. It will not allow non-technical management to suddenly develop an understanding an appreciation for technical difficulties.

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

#137

Post by sergeykish » Tue, Jun 30, 2020, 10:22 AM UTC

jariel wrote: post #76

PaulKeeble wrote: post #21

In the one place I saw Scrum work really well it wasn't because of scrum we succeeded it was the amazingly talent team that groked their goals and understand how to build software well. The complete lack of an enforcer manager was a huge win, being connected directly into your customers and letting them drive what they needed and balancing it with the engineering, that worked really well. They executed well despite s…

"being connected directly into your customers and letting them drive what they needed and balancing it with the engineering," Lucky you however, letting 'raw' Engineers interface with customers is usually a disaster. Engineers build tech, the company builds products, and they are very, very different things. A lot of pieces in there - support, training, docs, price , risk, leverage, IP, know-how, relationship managem…

That's the idea - allow people to take responsibilities, learn, grow, communicate. It takes effort and time. And sometimes right person. But when it works it is a joy. I've seen young developers in what was their first project. It is bad but that moment I felt envy.

So often people complain about specification. Here you craft them as they fit you (as long as they resolve customers need).

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

#138

Post by danjac » Tue, Jun 30, 2020, 10:28 AM UTC

alexashka wrote: post #29

The only right way to do 'great engineering' is by not having any middle management. The only right way to do great engineering, is by first asking what we ought to be engineering, not re-implementing the same shit over and over again, like we do web frameworks in every new language. Great engineering is completely unrelated to scrum. It is only in the delusional mind of a middle manager that his existence and though…

While "middle manager" is often nowadays a negative term, having a good manager between yourself and the upper management/customer can be a godsend. They can act as a bullshit filter, they can deal with bureaucratic busywork, they can get you whatever resources you need, fight for more funding/people for your team, help out with HR stuff and so on. You need these people so you can get on with "great engineering".

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

#139

Post by someguyorother » Tue, Jun 30, 2020, 10:30 AM UTC

jay_kyburz wrote: post #122

someguyorother wrote: post #113

Earlier quoted context omitted.

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

I'm not familiar with the story, but it sounds like he started with a solution, (the tests) and tried to find some code that would satisfy them. Perhaps Norvig started with the problem, then tried to find a solution.

As I understand it, TDD works by that you say what your problem is, find the smallest thing that will get you there, and then implement a test for it. The test will naturally fail, so you then write code to make it pass, and finally refactor. It's fundamentally iterative.

But Jeffries didn't know how to get to the solution, i.e. what mechanism to make use of to get the computer to automatically solve Sudokus. So he wrote a few tests for the obvious things (like I/O and data structure) and then got stuck.

In contrast, Norvig knew considerably more CS and so knew that the right way to implement a solver is to use constraint propagation. So he did so in about a screen of Python code, all at once, job done.

The lesson of the story, as I read it, is that you can't iterate yourself out of a problem if you don't know how to attack it. If you're making a symbolic calculus program to solve integrals, it's unlikely that you can start off by going "okay, the integral of x is 1/2 x^2..." and somehow, through a series of small steps, end up at the Risch algorithm.

Similar arguments could probably be made about design. The less CRUD-y your application is, the more careful thinking is required. You have to know enough about the domain to know where the pitfalls are, and what the proper tools are.

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

#140

Post by sergeykish » Tue, Jun 30, 2020, 10:33 AM UTC

greatgib wrote: post #129

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

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