Live data from Hacker News

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

newsletter.pragmaticengineer.com

201–210 of 452 posts

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

#201
post #149
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…

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.

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

#202
post #161
post #145

Earlier quoted context omitted.

Interesting, I had a very similar experience in the past. I think we just were part of a software factory that is not necessarily bad, it's just a different approach to work. It's much more convenient for a manager to just apply "standard" principles (scrum, 2 weeks, story points, velocity, etc. like a mantra) rather than innovating at this risk of being wrong, difficult, etc. Too much bureaucracy is not good, maybe…

Agreed on the kind of religious adherence which can make the process feels a bit like..a staged show? Stifling instead of open discussion? "Metrics" though drive when something might be delivered which triggers marketing spend, hiring requirements and so on. It says "we're working on this now and that next" which drives all kinds of internal storytelling about priorities and cascades down (or up?) into quarterly call…

You set up long term team based goals (OKR's, Objectives and Key Results) and then evaluate how well those goals were achieved. It isn't 100% accurate or fair, but neither are Scrum burndown charts.

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

#203
post #149
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 this isn't actually what happens when agile and similar have gone wrong in my direct experience and the parent poster would note that this is the same kind of general "no true Scotsman" response to "it didn't work" that you get from self-help gurus. The system always works, all failures are that you did it wrong.

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

#204
post #84

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

>Some tasks take 15 minutes of discussion (no, they aren't complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless.

If you're not personally responsible for deadlines on the project, it could seem pointless. But the difference might mean pushing the commitment for a feature out two weeks, which in a commercial project could be a big deal. Planning is hard: you've got to try to estimate something with incomplete information, and then reconcile differing opinions. But it's definitely not pointless.

Velocity is probably one of the most misunderstood aspects of scrum. It's a key metric for long-term planning, but it's not intended to be manageable. It's also unique to the team, and not intended to be compared between teams. Many managers are not used to a metric that they don't manage, and that causes a lot (maybe most) of the bad experiences people have with poorly practiced scrum.

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

#205
The initial comparison - WhatsApp (18 employees) vs Skype (hundreds? thousands) is not a comparison of Project Management systems but a great example of the Clay Christensen Innovators Dilemma - Skype got killed by a mobile only, E2E encrypted competitor.

I think the big takeaway is "dont worry about your project managment system if you are playing the wrong game."

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

#206
post #164

I was there when Agile was invented. In my opinion, Scrum has always been the worst embodiment of a good idea. In terms of content, teams of experienced developers have always worked in the spirit of Agile (of course there are exceptions). This informal understanding was and is superior to a formal horizontal Scrum implementation. For example, it preserves seniority and true accountability - two things that Scrum pre…

It seems to me that the industry's original sin with Agile was treating it as anything other than a model for managing a team of software consultants. There are certain types of internal product teams that can meaningfully emulate this paradigm, particularly in a B2B context where a tight feedback loop can be cultivated with customers. Chances are, though, that product teams, particularly in DTC businesses, don't have close enough relationships with their end users to be able to practice Agile as written.

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

#207

There’s this image that big tech teams build software where everything is automated and has 100% test coverage and all the infrastructure heals itself and all teams are hyper efficient. It’s not really true, the biggest shared practice between big tech is letting the team’s manager pick whatever methodology works best for them. The big tech version of scrum is just sprints, stand ups and shipping often. There’s still…

I think your last point is wrong. Shipping big, complex projects at big tech companies, especially vendors who actually literally ship and can't do live patching to cover up shoddy practices, is actually something _everyone_ in the industry should do because you learn a lot about what it really means to build and release software.

Cloud-delivered CRUD apps are the easy mode of SW development and people who have never done anything else really end up quite stunted IMHO.

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

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

Or Alice is more familiar with that section of the code and would move more quickly in there and Bob would be doing more learning along the way.

Quick discussion of the differences is useful, but 15 minutes is ridiculous. Just take the higher value and move on. Eventually you’ll baseline at slightly more points per sprint on average, but they are imaginary numbers anyway and not really comparable across teams.

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

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

hm - I'm at a startup with plan/release/build. The truth is...there are almost no abrupt new features. If something is truly a new feature - it's gonna move into planning. We've had 1 instance in my 8 months on the team with an abrupt-ish full-on feature (that I know of at least). I worked on it - there was a lot of communication with me about the scope/timeline/expectations. The feature fit into an offering we have at a beta stage - so it helped us expand something we were working on broadly anyways and was in service of winning a particularly good logo/customer. Again - this is super rare for us, but broadly - we simply communicate priority and have alignment about working on the most important things first. Generally, someone is picking up the feature that's coming off some piece of work or is working on something low stakes. Other abrupt stuff comes up - generally if it's limiting a customer's ability to utilize our product - we prioritize it.

I think you want to have a culture where abrupt new features are incredibly rare.

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

#210

Earlier quoted context omitted.

A "scrum course" is to Scrum what a code boot camp is to programming. You're going to learn basics but you won't have the depth of knowledge to handle complexity in any form, nor how to answer questions about Scrum that inevitably are asked by leadership. There's a reason the Scrum leader (or master) role exists. It's supposed to be the person who has a depth of knowledge that goes beyond a simple "scrum course" and…

But is there evidence the force is actually multiplied in practice?

Pretty sure there isn't, otherwise FAANG would enforce it top down. They already enforce other practices top down like hiring etc, so if they had data saying that mandating Scrum would make the company X% more efficient they would absolutely do it.

It might be a force multiplier in other types of companies, but it probably isn't in FAANG style companies. Similar to how FAANG hiring can make sense to them but still be bad for typical companies.

Post reply on HN