How big tech runs tech projects and the curious absence of Scrum • Hacker News Board

Re: How big tech runs tech projects and the curious absence of Scrum

#271

Post by dta5003 » Mon, Sep 27, 2021, 5:16 PM UTC

bitwize wrote: post #246

commandlinefan wrote: post #214

Earlier quoted context omitted.

> whether they'd done exactly the "right" stories in a 2 week sprint Not only that, but if anything else comes up during the "sprint", you're expected to address it while still finishing everything that you (involuntarily) "committed" to during sprint planning.

WE committed. We made these commitments as a team. If you can't fulfill what has been committed to by the team, then we as a team have to have a discussion about that. I'll put the meeting for next Monday on everyone's outlook.

I've never had a more visceral reaction to a comment.

Thanks, I hate it.

Re: How big tech runs tech projects and the curious absence of Scrum

#272

Post by wittycardio » Mon, Sep 27, 2021, 5:19 PM UTC

mempko wrote: post #132

Alternative title: "Big Tech's Curious Absence of Innovation". Am I the only one who thinks Big Tech is slow at shipping?

Yes you are because they ship an insane quantity of products with very high quality. I'm guessing you're looking to justify the existence of scrum?

Re: How big tech runs tech projects and the curious absence of Scrum

#273

Post by Millenialboomer » Mon, Sep 27, 2021, 5:22 PM UTC

nickd2001 wrote: post #143

akudha wrote: post #84

Earlier quoted context omitted.

The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…

" I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how…

As a manager, we have been incentivized to game this system exactly as you describe, both from my end and my devs end. Moving to a company which only cares about delivered software instead of metrics saved my soul.

Re: How big tech runs tech projects and the curious absence of Scrum

#274

Post by vinay_ys » Mon, Sep 27, 2021, 5:22 PM UTC

romanhn wrote: post #212

My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views "no process" from a very positive lens, with no discussion of negatives. Like how at FB so many teams use spreadsheets to track their work (sometimes multiple spreadsheets per team, sometimes no tracking at all). There is some internal tooling, which is quite basic and…

Biggest difference between big tech companies and smaller companies is the sense of urgency to ship something to market and the time scale for that urgency. Bigger companies have lesser pressure to ship things too early and have slower (larger) time scales for product release cycles.

Both in enterprise space or in consumer space, smaller companies are on a much more rushed timeline, for varied reasons including but not limited to financial situation of the company.

Bigger companies can afford to build more slowly. This affects how the company plans and executes as well as rewards performance.

In a smaller company, when a complex thing has to be shipped on a shorter time scale, a lot of divide and conquer and quick coordination across large number of contributors is required. This is a necessity.

In a larger company, deep complex things are built by very small teams or just individuals over a relatively prolonged time. Individual engineers prefer to keep chiseling away at a particular problem until they can showcase a significant impact with high difficulty/complexity of the problem/solution. That's the consequence of individualistic performance measurement culture.

Both cultures have pros/cons and there are rotten extremes in both.

Re: How big tech runs tech projects and the curious absence of Scrum

#275

Post by postfacto » Mon, Sep 27, 2021, 5:23 PM UTC

commandlinefan wrote: post #225

pc86 wrote: post #92

Earlier quoted context omitted.

> Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do. I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private compan…

> in a private company, they're the ones writing the checks As long as they're being otherwise reasonable, I don't have a problem doing something that doesn't seem terribly "important" to me either. However, in my career I've had many frustrating instances where they were demanding something in a timeframe that I couldn't deliver it without ensuring that there wouldn't be any unintended side effects - and then blamin…

> they were demanding something in a timeframe that I couldn't deliver it without ensuring that there wouldn't be any unintended side effects - and then blaming me for the side effects when they came up.

Far too few developers understand: just because the people writing the checks ask you to do it and you implemented it exact as they ordered you to doesn't mean the people writing the checks will take responsibility for the resulting bad situations that can lead to them not writing you checks anymore. If anything, you'll be used as a scapegoat to prevent them from not getting any more checks written.

Re: How big tech runs tech projects and the curious absence of Scrum

#276

Post by AnimalMuppet » Mon, Sep 27, 2021, 5:24 PM UTC

shados wrote: post #32

lordnacho wrote: post #17

The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…

Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile". When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel. If you don't, or do "Scrum but not quite", then when things don't quite work out,…

OK, but scrum is supposed to be a way of doing agile. And "we're going to do agile by a rigidly defined process" is an oxymoron. If your process isn't one of the knobs you can turn, then you aren't actually agile.

Re: How big tech runs tech projects and the curious absence of Scrum

#277

Post by shepherdjerred » Mon, Sep 27, 2021, 5:25 PM UTC

romanhn wrote: post #212

My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views "no process" from a very positive lens, with no discussion of negatives. Like how at FB so many teams use spreadsheets to track their work (sometimes multiple spreadsheets per team, sometimes no tracking at all). There is some internal tooling, which is quite basic and…

I had the same experience at AWS. A team of siloed engineers working on projects for the same product, with very little collaboration. Projects were tracked in spreadsheets. Time estimates were created out of thin air to meet the desired (impossible) deadline.

Re: How big tech runs tech projects and the curious absence of Scrum

#278

Post by blululu » Mon, Sep 27, 2021, 5:26 PM UTC

ekianjo wrote: post #152

> It measured a Net Promoter Score (NPS) of -83. This is staggeringly low, and means that 83% of engineers would advise against JIRA No, that's not at all what it means. Another person who does not understand the bullshit that is NPS. NPS treats people rating at the lowest of the scale just like people rating at the middle of the scale, which is patently ridiculous.

It's not exactly what an NPS score of -83 means, but it's close enough and an NPS score of -83 is sufficiently awful that it should be considered a crisis for any business that does not have strong customer lock in. Actually a few promoters in the sample would potentially imply that more than 83% of engineers would advise against JIRA.

Of course NPS scores overlook some nuances. It's a single estimate of a complicated space. The imprecision is probably to its advantage. The goal is not to be perfect (no single number could do that), but to provide a quick estimate of quality with a single question (nobody wants to fill out a 3 page survey, and the executive team is only going to sit and listen for a single statistic).

As an exercise, consider how you chose a restaurant based on a standard Yelp 1-5 scale: you might find that you are using a similar methodology while reading product/service review. Ratings of 1-3 are considered bad reviews, 4s are decent and 5s are good. American culture as a strong bias for positive affect so a 3 is considered to be unfavorable. Additionally, there is a lot of variance in terms of how people get upset and express their anger. Someone may rate something as a 1 because they are more expressive of their angry, while another person rates it as a 3, but neither is really happy with the service. Try coming up with a better metric based on yelp reviews for restaurants you are familiar with and you might find that NPS does a reasonable approximation of what you have discovered.

Re: How big tech runs tech projects and the curious absence of Scrum

#279

Post by drspacemonkey » Mon, Sep 27, 2021, 5:32 PM UTC

tomc1985 wrote: post #261

erikwiffin wrote: post #157

Earlier quoted context omitted.

I've always done planning poker with the Fibonacci sequence - 1, 2, 3, 5, 8. The idea being that the more complicated the task, the harder it is to estimate accurately.

Why is story point estimation tied to fibonacci sequence? Two generations of managers at my previous employment thought this way. It just seems so arbitrary to me.

First, the more difficult a task is, the more inherent difficulty there will be in "accurately" estimating the difficulty of the task. Fibonacci is used to represent the inherent lack of accuracy in more difficult tasks, since the numbers get _very_ far from each other as they go up the scale.

Second, the numbers _are_ arbitrary. Completely, 100% arbitrary. It's a _relative_ difficulty scale. Say you've got 3 tasks - A, B, and C. A and B are approximately as hard as each other, they're 1 story point. C is more difficult than either one - it gets 2 points. That's it. Story points are not, and should not be used as, a unit of measurement. The biggest utility is to identify big, scary tasks with lots of unknown factors.

The fact that they are _numbers_ is what tricks so many teams/PMs/management/etc into thinking that story points are more meaningful than they were ever supposed to be. Incidentally, this is also why some planning poker teams use t-shirt sizing (S,M,L,XL,XXL, etc). No numbers means people are less tempted to punch them into a spreadsheet while deluding themselves into believing that showing numbers going down is the same thing as "showing progress".

Re: How big tech runs tech projects and the curious absence of Scrum

#280

Post by robertlagrant » Mon, Sep 27, 2021, 5:33 PM UTC

hiptobecubic wrote: post #166

williamdclt wrote: post #74

Earlier quoted context omitted.

The whole debating around agile, scrum, kanban etc etc, with seniors hating Scrum yet it being pushed ever and ever again made much more sense when I heard some guy talk about Shu-Ha-Ri ( https://martinfowler.com/bliki/ShuHaRi.html ). Having a strict framework à la Scrum is very helpful for new developpers or new teams, where they don't yet have their marks and need to get a feel of what agility feels like. Being exp…

Maybe if you don't fill a team with nine juniors that have no mentors, you don't get this problem? It's not like FAANG isn't hiring boatloads of new grads every year. Why don't those people need scrum to get on the right track, but half the rest of the industry seems to?

Those companies are very engineering-led. Boatloads of excellent engineers; deadlines are "it'll be ready when it's ready"; marketing is (and thus marketing deadlines are) light, so there's less planning needed; featuresets are largely defined by the engineering teams.

Anything that is reasonably unpredictable in terms of requirements but needs to be reasonably predictable in terms of feature delivery speed is a good candidate.

We use it because we need to release versions of our software a chunk at a time, and it's the closest we can get to continuous delivery given that constraint.