Live data from Hacker News

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

newsletter.pragmaticengineer.com

321–330 of 452 posts

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

#321
post #111

If Skype is an example of Scrum done well, perhaps that explains why Skype has been very unreliable from and end user perspective for 5+ years... the kind of unreliable where more than half of the outgoing calls are met with instant "So-and-so-contact is not available." responses [edit, added: failure responses so quick that you know the contact was never called, and the problem was within your client app or the Skyp…

That's not a fault of scrum. If you can't sell the value of refactors on to product, then either you're not making your case or they aren't being reasonable. But you'd have the same problem with any process. We run kanban mostly and we get refactors and tech debt into the backlog pretty regularly. We also reject them pretty regularly when they don't see any viable business cases.

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

#322
post #313

Earlier quoted context omitted.

The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worked for you, you must've done it right. > If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own. So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?

I think I'm expressing myself incorrectly. Scrum "by the book" has a lot of material on the edge cases. How you handle almost every case that can happen in a software development team. So you can follow it like a workflow. Something unusual happens, you look in the book, do what it says. It's flaws are fairly well documented and understood, too. That's what I mean by being "on your own" if you don't follow it. At tha…

> If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc.

Yeah this is the nonsense propaganda I'm talking about. "If it didn't work, it's because you needed to do it more", which I think is absolute nonsense.

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

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

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…

My team has a rule that if your Fibonacci point estimates are within one of a given unit, you just accept that estimate with no discussion - so if I think a story is a 3, and others think 5 and 8, we’ll take the 5 and move on. I think it gives a good balance of discouraging hair splitting and surfacing cases where having more discussion is actually valuable.

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

#324
Minor side note: My current employer has been pushing SAFe hard (training for everyone, etc.) recently. As a result (and I do mean "as a result") about 3/4ths of the senior technical people have resigned in the last three months. This is at a "Large, non-tech enterprise" (sort of; it's an engineery chunk of the federal government).

Now back to a personal opinion: Most "software engineering" "methodologies" are intended to appear productive without actually requiring productivity. Or, as I sometimes put it, "software engineering is about making people who are fundamentally not very good at writing code look as if they were producing code." Look at the number of managers, leads, coaches, trainers, and consultants required for every methodology and compare that with the number of such "overhead" positions in, say, open-source projects. (Note: I'm not trying to start a "which is better" discussion; open-source is just a convenient example since their development techniques are transparent, unlike everyone else's.)

Further, many medium- and large-scale initiatives in large, non-tech enterprises fail spectacularly, in spite of using the then-popular methodologies. I would go further and suggest that they all fail at some point, even if they eventually deliver a usable product.

The only solid generalization I can see is that good developers can develop good software with any (or no) methodology; poor developers cannot, and most formal methodologies are built around trying to get them to do so.

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

#326
Of the weekly "Scrum sucks" posts we see on HN, this was by far the most articulate and well-reasoned. I've spent most of my career in consulting or kitchen sink teams. Having Scrum or a Scrum-like process is simply mandatory because we are working with disparate stakeholders against constrained budgets with a team who are not dedicated to the domain we're working in. Getting a high degree of specificity into requirements in the smallest increments is life-saving. Over reliance on rituals is typically only necessary for a really immature team (which I have been part of in the past) but the core elements of backlog management are really valuable. Not just for developer efficiency, but for visibility on progress and priorities.

All that being said, I can easily see how a dedicated team with a very clear product strategy iterating on a hugely successful business model can just roll along without a lot of oversight. I'd still be a bit surprised that anyone working on a customer-facing product isn't running their design decisions through product experts. Idk what that world is like, but I've spent a lot of energy duking out product debates where nobody is really sure how a feature should work or it's even beneficial and developers usually have the worst instincts.

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

#327

Earlier quoted context omitted.

> These days, mandatory Scrum is a contra-indicator for any project that crosses my path as a freelancer. Yes! Although I don't agree that Agile is a good idea that scrum ruined.

How long have you been in the industry? Agile in 2021 means something different than Agile in 2002. Project Management was a different consideration 20 years ago. Which of these do you disagree with? https://agilemanifesto.org/principles.html I disagree with 2. Now, perhaps you disagree with 5. These were written in 2001 for problems in 2001. Now, some of these problems have been solved. Some of them are taken for gr…

I disagree with the whole thing. It was written by consultants to sell consulting services. The "principles" are empty aphorisms that have practically crippled the software development industry.

Edit:

> How long have you been in the industry?

32 years.

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

#328

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

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…

Ah. Nice reference. The fact that Aikido is notoriously ineffective made me chuckle.

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

#330
Not surprising that scrum works best for consultancies -- Scrum has just as much to say for how engineers should behave as it has to say about the people paying for the project should behave, and how to pretend to be that person when they seemingly abandon their duties.

The sprint is also a product of its time. A methodology for shipping new features on a monthly basis is great when your competitor is shipping Excel on an annual basis. But the shorter the turnaround time for a feature, the less use there is in planning timelines.

This is why the big tech companies don't have a unified process -- the process that works best for shipping operating systems is different than the one that works for shipping a mobile app, is different than the one that works for shipping a webapp. Any program office that tries to smooth out these wrinkles is hazardous to their wealth.

Post reply on HN