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

331–340 of 452 posts

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

#331

Post by Traster »

deepGem wrote: post #222
Traster wrote: post #53

Earlier quoted context omitted.

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.

Ah right, generally I quite like having branch names because I can name the brach aligned to the jira ticket that it's associated with, I'm not a big fan of jira, but atleast it documents the feature request etc. And also you can track multiple different features in flight at once (I know it's not ideal, but sometimes you're doing several different things that need to be merged in order etc)

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

#332

Post by simplyaccont »

fredliu wrote: post #237
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…

Very interesting, do you have any examples of how FB manages long term (2+ years out) project that involves 100+ Engineers? Are those 100+ engineers all "individuals working on their own project"?

I worked at FB for a while, and the problem with long term projects were that they were long term. In FB you need twice a year to make self review that shows what kind of impact you created during last 6 months (and based on this you are rated, raises, refreshers, etc). In long term projects impact might be only at the end of project, which leaves you "impactless" for a long-long time. Because of this people didn't really want to join any long term projects.

While I was there management was trying to resolve this situation and transmit message that long term projects are impactfull and important (and strategic to company), yet they couldn't answer question of how impact should be calculated every 6 months.

Maybe by now they came up with some formula or something

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

#333

Post by fatnoah »

SkyPuncher wrote: post #247
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…

> 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 and quick. The only thing we religiously followed was daily, quick 15 min st…

When I ran Engineering for a startup, this is roughly how we did things as well. If a disagreement around pointing a story happened, we resolved it within seconds and usually just went with the larger size. It didn't really matter so much, since we weren't using velocity as a goal or something reported on a weekly basis. I did use it to roughly ballpark how many sprints it might take to deliver something, but that was as much story point math as I ever did and never used it to guarantee a date. I did have to fight a few battles with my CEO and other VPs around that, but, in the end, the results of mostly consistent and predicable progress with happier dev teams made those arguments moot.

We also found retrospectives to be pretty useful and each team was encouraged to find what worked for them. The result was that we had 5 teams that had some agile/scrum process, but created mechanics that worked well for them.

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

#334

Post by dboreham »

shepherdjerred wrote: post #277
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.

This kind of mass delusion has been pretty much de rigueur my entire career (decades):

Software is typically quite hard and mostly unknown at the beginning of a project. Most of the hard work is figuring out the things that weren't known. It's a learning/discovery experience. It's essentially impossible to predict how long that activity will take. The further out in time you consider, the less likely you'll have much of any clue about the subtasks to be done. And of course in the meantime the participants likely aren't even working close to 50% of their time on the new project -- instead they're fixing the bugs and technical debt in the last project.

And yet, the "stakeholders" simply wouldn't accept any narrative like the real one (we kind of have an idea how to do this but we're going to figure it out as we go and it'll be difficult and unpredictable). They'd go hire another bunch of folks who are willing to salute the flag. So instead we pretend that what we're doing is predicable and plannable, like building a bridge that's a bit longer or shorter than the last 10 bridges that we built.

The stakeholders probably have a pretty good idea that the developers are making it up as they go. But everyone behaves as if the reactor isn't on fire.

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

#335

Post by birthday »

Traster wrote: post #48

I think the core observation that teams are best allowed to adapt to their own situation is a good one. One thing I want to take on though is this: > “Kitchen sink teams” which have everything thrown at them, typically find that managing stakeholders with a heavyweight process like Scrum is a win. Stakeholders are educated to understand that an ongoing sprint cannot be interrupted and that new feature requests need t…

That's where short cycles come into play. If something is urgent for business (and often everything is "urgent") then it can fall in the next cycle which is just 14 days away. It's rare that something is so urgent that it should disrupt your entire dev team flow and focus.

Also what happens is you end up with a never ending dev cycle where business expedites an item making the cycle a little longer, business sees the cycle is longer and thus adds in more items to be included further lengething the cycle... I think you get where this is going.

At my startup company we have suffered from just this in past, where we would have never ending dev cycles while our maintenance back logs filled up and never got worked on properly.

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

#336

Post by theptip »

zeku wrote: post #197
nickd2001 wrote: post #143

Earlier quoted context omitted.

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

Can you link me or someone else link me what you would consider the "ultimate kanban guide"? I work in an environment that had no project management tools or methods being used other than emails and I've finally gotten buy in on Kanban and I want to make sure I guide my team properly.

Kniberg has written extensively about agile practices, and this one talks a lot about Kanban:

https://www.amazon.com/gp/product/B00A32O00Q/ref=dbs_a_def_r...

Although I think he ended up with something more Scrum-like later at Spotify.

He also has lots of good videos about broader team organization (Tribes etc.) that I found useful for conveying some of these ideas to my non-technical peers.

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

#337

Post by bluGill »

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…

The purpose of metrics is to be something to game.

Now you do need don't to anything illegal policies in place, and you might have a [unwritten] moral code of what you can't do. However the purpose is to game the metrics. For all the discussion that follows I'm going to assume we are within these limits.

If the boss wants profit margin as a metric, then you need to figure out how to do things cheaper, and how to get more sales, or higher value sales or some such, and sometimes get something off the books. Note that this last is why smart investors always ask about the bottom line - because the rules of what you can hide from the bottom line are strict enough that the metrics cannot be gamed to your disadvantage. That said off the books is sometimes a useful thing to have - sometimes you know you need to do something hard and so you need to leave an approved way to hide specific things in plain sight.

The problem is most developer metrics are things where gaming the metric isn't good for the company.

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

#338

Post by romanhn »

fredliu wrote: post #237
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…

Very interesting, do you have any examples of how FB manages long term (2+ years out) project that involves 100+ Engineers? Are those 100+ engineers all "individuals working on their own project"?

+1 to everything simplyaccont said. Long term projects were a tough beast to manage given the short-term incentives. Usually those got done by breaking them up into milestones and hitting those. That said, my general impression (as a first-level manager who sat in on calibrations) was that unless you move some serious metrics in those milestones, it would be difficult to exceed expectations and much of the upper management encouragement for long-term projects was mostly empty air due to the 6-month performance cycle.

That said, large cross-org projects certainly do exist. To answer your specific question, there would normally be some sort of a lead on the whole project, tech lead or PM lead or, often, a pair of those. They would meet regularly with leads of various sub-areas, organized similarly, and ensure things line up properly. Now repeat recursively until you get down to team level, where there might be a tech lead, or perhaps just a senior engineer working with a few non-seniors on their portion of the larger initiative. At this point this would get broken down into individual projects that each person owns and is accountable for. Tech lead may or may not contribute code to this project, they (and their team at large) might be involved in a bunch of parallel initiatives that often don't have much to do with each other, other than the product scope the team owns. Things like daily stand-ups don't work when everybody has their own work stream (and often multiple streams at that).

Hope this clarifies. The setup works for certain types of personalities, but I found it to be a very individualistic culture that I didn't particularly enjoy.

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

#339

Post by theptip »

troupe wrote: post #106
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…

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

A couple things:

1. Sometimes your team needs to give an estimate of when it will deliver a feature. The idea of pointing in Scrum is that you establish a velocity, which lets you get a feel for how long it's going to take to deliver a given piece of work.

2. Sometimes your team needs to make trade-offs, and often the right lens here is ROI. You can't estimate ROI if you don't estimate the I. (Although I believe agile tends to somewhat overrate the usefulness of the ROI lens.)

3. In the absence of 1 or 2, the act of pointing can help to catch the case where you miss a piece of complexity; if someone thinks it's 8 and everyone else is a 5, then maybe they are aware of some gnarly code that everyone else has forgotten?

I'm not arguing in favor of discussing each story to death, just making a more general justification for the practice. If you never need to do 1 or 2, then maybe pointing isn't going to be useful for your team at this time -- and that's OK too.

I'm sure in some cases this is just driven by managers needing metrics to measure their teams by, but the above is an attempt to suggest some reasons that the teams themselves might find the practice useful.

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

#340

Post by theonething »

akudha wrote: post #84
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.…

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…

> The only thing we religiously followed was daily, quick 15 min stand-ups.

One of the worst parts of scrum in my opinion. Even if it's a "quick" 15 minutes (which in my experience it rarely ever is), the forced context switch ends up wasting more than 15 minutes of productive time every day.

Post reply on HN