Live data from Hacker News

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

newsletter.pragmaticengineer.com

221–230 of 452 posts

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

#221

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

NPS is a marketing tool. I agree it's misused in this case, but the people at the extreme ends of the scale DO matter. They are the ones who will passionately voice their opinions, write reviews, do blogs posts, etc. The people in the middle of the scale can't be bothered with doing anything about their opinions.

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

#222
post #53
post #38

Earlier quoted context omitted.

I worked on a Tensorflow feature in 2018. There was no branching involved. Fork the main repo, build the feature on your child repo, make sure all unit tests pass and then send a pull request to the main/master of the parent repo. Typically someone reviews the code, you incorporate code review comments, pass all unit tests, CI-CD pass, PR approved. That's it. Your code is in the next production cycle. So yes, you wor…

How would you describe the difference between branches and forks? Functionally I can create a new branch, do my changes, get tests passing and PR from there, or I can fork master, do my changes, get tests passing and PR.

Yes technically this is a branch, but like a frictionless branch. You don't have to name a branch for instance. You don't have to worry about branch deletion, even though now this is all automated.

https://docs.github.com/en/repositories/configuring-branches...

A fork is still a lot less friction. Otherwise, technically yes it is a branch.

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

#223

Earlier quoted context omitted.

I have seen it more often that gatekeepers filtered user demands based on their own knowledge and not on technical feasibility or effort. So you are told that a user needs a certain thing in a certain way but when you talk directly to the user you learn that the user actually had a different need which you can fulfill in an easier way than the gatekeeper thought possible. In general I think there is a huge advantage…

The whole point is that this doesn't scale. What do you do when there are too many users to interview them all over coffee?

Honestly that's the whole problem with Democracies. And we solve it with sampling and surveys. Probably if we can come up with a better answer, we will improve Scrum, and Democracies :-)

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

#224
post #106

Earlier quoted context omitted.

> debating whether it is worth 5 points are 8 I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on. I think you are right that much of…

Sometimes importance is related to size. Points are arbitrary, but lets assume that on average a developer will work the entire sprint on an 8 point task. The PM might decide that feature is not worth the time investment in that sprint, if they could instead get 2 smaller features out the door, or some bug fixed - they might prefer to deliver that to stakeholders. That's why there's even a velocity expressed in point…

Bugs get resolved desk-side five minutes after being reported and pushed through on PRs that have 89% test coverage (still green!). Developer is a cowboy hero! The good thing is: you always get more bugs like this so everyone gets a chance to be a hero.

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

#225
post #92

Earlier quoted context omitted.

I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted". Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.

> 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 blaming me for the side effects when they came up. I only push back when they don't realize how complex what they're asking for is. Of course, then they play the "tell me how long it's going to take so I can argue with you until you agree that it will take as long as I originally asked for" game.

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

#226

Earlier quoted context omitted.

the idea that you can deliver a multi-month or multi-year project without ever looking past the next two week sprint is really misguided.

We just delivered a multi-year project under Scrum (edit: point of clarification, we did not have a due date). You still have a guiding vision and some idea of the major milestones you need to reach, you still define what the next set of milestones are. You will want several sprints worth of work lined up ready to be more concretely planned. You just do concrete planning for the next sprint or so and work to minimize…

the parent -

"The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense. Agile is about doing what is important now, not doing what we thought was important a few months ago."

I agree with you - i dont think its worth trying to set a date a year out in stone. but you have to do exactly what you say. keep the trajectory in your mind and update it with new information. and and some point turn down the rate of change so you can get some cook time.

maybe I reacted too strongly - but I've certainly been in shops where I try to talk about overall project arc and am firmly told to keep my gaze fixed at exactly two weeks.

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

#227

Earlier quoted context omitted.

I think they mean when your retro board has a theme; I've seen various themes applied successfully i.e. sailboat: https://metroretro.io/templates/the-sailboat-retrospective

Is it just me or does this look great for a 2nd grade class.

Get on the call and suck your thumb to fit in.

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

#228

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…

Funny that you mention spreadsheets. When I worked at Microsoft my entire business unit (multiple thousands of engineers, managers, PMs) exclusively used Excel for project management. Clean UI, filters, data rules, conditional formatting, validations, pivot tables..it was the absolute best. And with Excel data tools it was all hooked up to a central database (TFS) for live sync/updates.

Now I use Jira and hate every second of it.

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

#229
post #149

Earlier quoted context omitted.

A general goes to the commander of a group of soldiers and says "In 3 months, I want them to be able to demo the "march in formation" feature in front of the big-wigs who decide whether to give us more funding." So the commander says "Yes General, we'll do Drills™ to make it happen." And then the commander writes down "Do drills" on a TODO list, gives presentations to the soldiers about the importance of drills, and…

By your analogy, the purpose of doing Scrum (drills) is to get better at doing Scrum (parading) rather than doing actual work (soldiery things) - which I think pretty accurately sums up my experience with it.

As I understand the analogy, the purpose of scrum (and particularly reporting), similar to the purpose of parading, is to demonstrate that you have in front of you a large group of individuals trained to work in an organized, consistent and predictable way. The implication is that if given any other "somewhat similar" task, this group would be able to perform that task in a similarly organized manner too. The choice of what the task should actually be is then left to someone on a higher pay grade.

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

#230
post #200
post #155

Earlier quoted context omitted.

I think the biggest misunderstanding that always occurs when talking about Scrum and/or Agile is when people from radically different industries meet. From the perspective of my previous team, 1-3 days from PR to prod would be indeed quite long. For such a team, "two weeks per sprint" can seem like an eternity and will only slow things down. On the other hand, one of my best friends works for the largest insurer in t…

What would you do to go from PR to prod faster when you want at least 1 human who didn't open the PR to manually review each PR in a 10-20 developer remote team? 1 day doesn't seem too bad, often times it can be 2-6 hours. It really depends on what lines up and how big the PR is.

A code review for a smallish change shouldn't take more time than sending a few chat messages. You send them the code review, they look through the 20 lines in the code review tool, note that the changes corresponds to the change description, see that you added tests for it and that those tests passed, they ask you to clarify a variable name, you update the code and send it again a few minutes later, they review the new change and see that the name was properly changed and tests still pass and press accept.

This is how most of the code reviews went for me at Google. If you do a bigger change it will take more time, but I see no reason why smaller should take longer than that. After all you are just sending small bits of text back and forth, it really isn't more complicated than a few chat messages.

Post reply on HN