Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

151–160 of 452 posts

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

#151

Post by marijnz »

seanhunter wrote: post #139
erikwiffin wrote: post #128

Earlier quoted context omitted.

I think there's value in that debate (within reason) even as a developer. If Alice thinks a task is worth 5, and Bob thinks it's worth 8, then there's a good chance one of them knows something the other does not. Is Bob aware of some hidden complexity that bumps it up 3 points? Or is Alice familiar with a convenient library that solves exactly that complexity? Planning poker is a convenient time to get that knowledge…

> there's a good chance one of them knows something the other does not Or that the assignment of points is arbitrary and imprecise and that different people have different ways of making up numbers.

My experience is that in well-running teams, devs are usually pretty aligned what these numbers mean. A difference in proposed points for some task does then usually mean there's a discrepancy in knowledge about it.

As for its usefulness: You of course don't have to necessarily poker to get these discrepancies, but it's a pretty effective way of going about it, I'd say.

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

#152

Post by ekianjo »

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

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

#154

Post by whynotmaybe »

pc86 wrote: post #92
whynotmaybe wrote: post #43

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…

Completely agree on that.

Now imagine a government entity where the users and the dev are both paid by the gov.

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

#155

Post by WJW »

UK-Al05 wrote: post #41
nickjj wrote: post #34

Earlier quoted context omitted.

> You forget that there's a big administrative load added to a two week scrum It wasn't forgotten. Maybe the places I've done contract work for didn't follow scrum to a T. There was no daily planning. It was meeting once for 2 hours every 2 weeks to figure out what to work on and then a few small teams self regulating themselves asynchronously until things were done. This included doing the work, updating the ticket,…

That's a long time from pr to release.

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 the company. They do about one release per six months and working in two week cycles would be an unimaginable speedup for them. It frequently takes more than a month to get word back from the regulators that their proposed code changes have been approved at all.

Both of the groups ("scrum slows you down"/"scrum is uncomfortably fast") have trouble imagining that the problems of the other group can even exist.

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

#156

Post by mywittyname »

deepGem wrote: post #57

So the key takeaway here is that the Plan, build(iterate), ship cycle works very well. Most successful teams stick to this. What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say. So how do you fit in this new requirement ? You are already in the middle of a feature built on day 3 or 4. Devs are working…

> What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say.

Maybe the larger, successful tech companies avoid doing this. I believe that most of them define work at a quarterly level. So a team is unlikely to have the sudden changes in direction.

They are also unlikely to be resource-constrained, so when the odd high-priority feature emerges from the ether, they can put together a new team to tackle it.

Smaller companies need the discipline to know not to suddenly change everyone's priority, and instead, work emergent features into the current backlog at a pace appropriate for the size and scope of their teams.

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

#157

Post by erikwiffin »

jhugo wrote: post #148
seanhunter wrote: post #139

Earlier quoted context omitted.

> there's a good chance one of them knows something the other does not Or that the assignment of points is arbitrary and imprecise and that different people have different ways of making up numbers.

Exactly this. It's probably not an accident that one of those numbers is half of 10 (and the number of fingers on one hand) – a common made-up number for everybody – and the other is 2^3 – a common made-up number for programmers.

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.

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

#158

Post by WJW »

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?

Compared to who? Two-person startups can be faster yes, but all the Big Tech companies are legit racecars compared to (say) a bank or a pharmaceutical companie.

Also, shipping fast and actually innovating are not the same.

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

#159

Post by christopherbalz »

Kind of surprising that the article doesn't mention the profits and sway that Big Tech has to afford the approaches he describes. Borrow money very cheaply, buy back stock, profit from higher stock price. As well, Big Tech has market power (not necessarily monopoly) to allow for a lot of flexibility in deadlines.

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

#160

Post by Jensson »

mLuby wrote: post #149
pc86 wrote: post #97

Earlier quoted context omitted.

Why is it that every criticism of agile/scrum/safe is met with "well you just weren't really doing it?"

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…

But lots of developers actually hates Scrum even when done correctly. The problem is that Scrum is very rigid, it tells you how long your development cycle should be, what your meetings should look like etc. They'd prefer to just do what needs done, have the meetings that needs to be had, deliver features when ready rather than have arbitrary deadlines (sprints) etc. I understand that many developers loves having that rigid process since it is easy to just go and do your work without thinking about the bigger picture, but lots of people wants to do the other parts and feel constrained by Scrum.

And no, "adapting the process for your needs" doesn't work. The problem is having the process mandating meetings and timelines in the first place. If you just do everything freeform as these people wants then it isn't Scrum.

Post reply on HN