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

351–360 of 452 posts

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

#351

Post by theptip »

regularfry wrote: post #346
theptip wrote: post #339

Earlier quoted context omitted.

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

Neither "points" nor "velocity" appears in the scrum guide.

Sure, like I said, you don't need to do it if you don't get value from it.

I'm just giving some examples of ways that some Scrum teams do get value from the practice.

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

#352

Post by mmcnl »

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

I fully agree, but I feel you vastly underestimate the difficulty of having a team that more or less adheres to these few principles. In your average Fortune 500 corp, it's next to impossible to have it without prescribing. If scrum is just writing down common sense in a onepager, then that's actually useful stuff.

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

#353

Post by mmcnl »

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…

Presenting scrum metrics to management is definitely not scrum. That's the opposite of scrum.

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

#354

Post by dave1999x »

void_mint wrote: post #322
shados wrote: post #313

Earlier quoted context omitted.

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.

If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse.

It's like baking a cake without adding sugar; it's not really a cake anymore.

Sometimes teams don't understand practices and will discard them.

As an example - retrospectives. I've worked on teams where we inspected and adapted our process on demand. We didn't wait till the end of a sprint.

I've managed individuals on teams where they're discarded retrospectives. They've complained to me about certain processes (not scrum ones) and when I've asked, "why didn't you raise this in the retrospective?". "We stopped them, we didn't see any value".

No doubt they weren't getting value out of them, but that doesn't mean they were doing things well and they lost opportunity to improve as a group.

For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.

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

#355

Post by mmcnl »

bluGill wrote: post #337
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…

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…

"When a measure becomes a target, it seizes to become a good measure." - Some guy

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

#356

Post by wikibob »

la6471 wrote: post #141
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 author is not completely correct , in big tech project managers are assigned to manage projects , depending on complexity and collaboration needs.

Citation and credentials needed.

The author obtained first party data backing up what he wrote. You present nothing.

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

#357

Post by regularfry »

tootie wrote: post #311
softwaredoug wrote: post #6

At Shopify, we tend to do whatever our engineers want in this regard. My team meets weekly and looks at a kanban project board. If we need to adjust, we have retros, etc and change the process. We have the autonomy. In a past life you would be told Agile meant “self organizing teams”. But in practice that was only allowed in a narrow definition of change under the prescribed process being foisted on teams from above.…

I find this concept utterly baffling, but probably because I've never worked at this kind of org. I can see how letting engineers run their own process is great for engineering efficiency, but how do they know what to deliver and when? My conjecture (please confirm or deny) is that these self-organizing teams are a result of and not a cause of big successful companies. You are probably iterating on a very well-unders…

I can't speak for Shopify, but in general you want teams that don't need anyone to tell them what to deliver and when because they can be trusted to figure that out for themselves and make a good call. That can't be done without having customer representation on the team (which you should anyway), and having engineers capable of taking a customer viewpoint. That is what "self-organising" should mean, but few organisations are mature enough to transition to it.

If you're in a situation where you need to show you're "spending their budget on high value features" that's a low-trust feature factory being treated as a cost centre by a remote client, not a value-producing unit setting its own terms.

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

#358

Post by mmcnl »

I somehow feel something important is not being discussed, and that is competency. Perhaps in Silicon Valley it is normal that engineers take ownership and are smart enough to figure out what is valuable and what is not, but I can assure you that in an average Fortune 500 company this is not the case. In my experience a lot of engineers in these companies don't care about engaging without customers, like to complain about a management and take little responsibility.

You need to have rules (however dumb you might find them), you even need babysitters. There's no going around that. Someone making 1/4h of what a SV engineer makes is highly likely to be less competent.

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

#359

Post by gregorygoc »

faizshah wrote: post #168

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…

You’ve described Amazon. Google and FB are different kind of beast.

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

#360

Post by MetaWhirledPeas »

williamdclt wrote: post #74
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 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…

I don't even know if it's a thing with new developers or old developers; I think sometimes you just get people who don't want to play along. Half-hearted participation is as good as no participation. You end up with user stories that are poorly written, poorly estimated, and you can't really reap a lot of the core benefits of Scrum like velocity forecasting. What you end up with is I Can't Believe It's Not Scrum; a shoddy clone of Scrum that never comes near the mark. You're forced to keep going along this way because not everyone agrees that you're failing.

Maybe people are tired of the nonsense that systems like Scrum bring with them? Even the name is a bit silly. And when you start naming roles and inundating people with rituals the eyerolls really get going. Why add abstraction to common sense?

Or maybe Scrum is really just an attempt to turn bad team members into good ones?

Good team members...

- Provide good estimates

- Cooperate to create clarity around requirements

- Work to divide big problems into small chunks

- Keep good track of their work in a shared format

Bad team members shun all of this and expect someone else to do it.

Post reply on HN