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

361–370 of 452 posts

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

#361

Post by void_mint »

vkou wrote: post #343
_6pvr wrote: post #299

Earlier quoted context omitted.

A mandatory meeting in which all developers must be present and regurgitate status updates to the entire team, as an example, assumes this information wouldn't get to relevant parties organically and all team members must consume all status updates.

> and all team members must consume all status updates. This is because nobody can be assed to figure out who needs to communicate with who, on what.

Which goes to some assertions that have been made about this thread: Scrum is a tool to build standardized minimums in support of mediocre talent. Elite tech companies don't use scrum because they don't have (as much) mediocre talent.

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

#362

Post by alach11 »

pc86 wrote: post #218
cheschire wrote: post #103

Earlier quoted context omitted.

Of course you have the option of saying "no" unless the company culture / leadership climate does not allow it. That's far from the inherent obligation you're describing. I do however agree with leaving any organization that does not allow you to express disagreement.

I think that depends on whether "no" means a nice way of saying "this is stupid" - which I agree with, and have done before, to mixed results - vs. outright refusing to do work that's been requested. I don't think an employee who is being paid a wage by an employer has the right to refuse to do something just because it's a stupid idea.

I'd much rather have an employee who will refuse to do work that is stupid than one who will do whatever is asked of them. Especially if it's something as bad as the GP example of six months of dev work to save one person-hour per year.

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

#363

Post by a4isms »

hatchnyc wrote: post #22

> Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business. In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the…

> In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the business. If you try to get direct access to the business usually the business is quite happy but the gatekeepers get very upset.

“But I’ve got people skills, dammit!”—Tom Smykowski

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

#364

Post by void_mint »

dave1999x wrote: post #354
void_mint wrote: post #322

Earlier quoted context omitted.

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

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

Dogma.

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

Nonsense.

> No doubt they weren't getting value out of them

This piece goes against this piece:

> , but that doesn't mean they were doing things well and they lost opportunity to improve as a group.

Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end?

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

Less interested in size, more interested in throughput/attrition.

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

#365

Post by colinmhayes »

marcus_holmes wrote: post #305

Reading this, I'm struck by a thought: Are we the bad guys? According to the article, what the big tech companies have in common is engineer-led products. It's not the besuited MBA's making product decisions, it's us, the engineers. And the big tech companies are also united in having evil products. With the possible exception of Shopify and Datadog, every company on that list of "big tech" is doing things that activ…

People who sign up to work on ad services for google or engagement for facebook have already self selected as willing to do morally dubious work in exchange for more money. There's no question that engineers do work that decreases society's utility.

I don't think following incentives makes someone bad though, it's only human nature, and of course there are plenty of people queued up to replace you. The system that creates those incentives might be bad, but it can be impossible to untangle where the incentives stem from.

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

#366

Post by erikwiffin »

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

If you will do something different with a 5 than with an 8 then yes. If not, then the ambiguities you describe will be worked out when you do the work. It is just a vanity metrics if the results doesn't change what you work on next. It seems important but it has no actual bearing on the teams sequencing of the work.

If Bob had a plan for doing the work that didn't involve Alice's library, there's a good chance he would have just jumped straight in to implementation without talking to anyone, and maybe the library wouldn't have come up until code review (if at all). By identifying the complexity mismatch ahead of time, they saved 3 points worth of effort. This doesn't affect sequencing at all, but still seems valuable to me.

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

#367

Post by tharkun__ »

regularfry wrote: post #347
mindcrime wrote: post #251

Earlier quoted context omitted.

I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't chang…

I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason.

If you do that you can actually very easily switch to Kanban methinks. In Kanban you sort of have to size all work to be about (!) the same size so that you can make accurate enough predictions for your lead time and cycle time. That only really works if all work items are about the same size though, otherwise you get too many outliers from your statistics.

I've found that most Product Owners really care about predictability and less about actual estimates. They care that if you say you're gonna finish something by the end of the sprint, much more often than not, you will. Estimates and velocity and such things are just means to the end of trying to figure out which items are reasonable to take into a sprint together.

If your Product person knows that they can throw 10 "random" (but currently most wanted by stakeholders) work items into a "sprint" and 9 times out of 10 you will actually finish all of those, they're probably gonna be very very happy as they won't have to explain delays over and over again on their end.

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

#368

Post by tootie »

regularfry wrote: post #357
tootie wrote: post #311

Earlier quoted context omitted.

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

There's a vast difference between being a cost center and being willing to set money on fire. Our teams have a lot of autonomy or at least influence in product strategy but it's because we empower our product managers, designers and researchers to help business understand how to achieve their goals. A lot of these projects are greenfield where the team comes in pretty blank on what needs doing. Developers are part of the process too but they don't generate much insight into what customers want. Only how to execute.

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

#369

Post by wonderwonder »

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…

My last job, we each had a minimum required individual velocity in our weekly sprints. That velocity score was the same if you were a junior or a senior. So in that case convincing the team it was an 8 could mean the difference between keeping your job or not. It was the most soul destroying, stressful job I have ever had. The worst was the Rockstar programmers not seeming to grasp that by reducing the points total on a hard ticket they were dooming their teammates. It lead to everything you can imagine, tickets implemented as fast as possible so they met the letter of the ticket but crashed on anything not defined as the team raced to meet their velocity. Massive unpaid overtime and burnout. Constant crashes in production. Races to claim the 'easy' tickets, and sandbagging. Eventually culminating in 8 of 12 devs quitting in an 8 month window including all seniors. My new job is so much better.

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

#370

Post by mavelikara »

mmcnl wrote: post #355
bluGill wrote: post #337

Earlier quoted context omitted.

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

Ceases*
Post reply on HN