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

281–290 of 452 posts

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

#281

Post by yupper32 »

deepGem wrote: 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…

> abrupt new feature with an urgent deadline

As someone who has spent most of their 7 year career at big companies that follow "plan build ship" cycles, I don't understand this post.

What abrupt new feature with urgent deadlines? Why can't this hypothetical feature wait?

Sure, for Coronavirus teams spun up and other work stopped, but that's a pretty big outlier. Most features are planned a quarter or so ahead.

> Do you just keep a copy of your old work, and start working on this new stuff

Sure why not? I don't understand how any "abrupt new feature with urgent deadlines" wouldn't require stopping what you're currently doing.

Besides, it's not like I sit on massive code changes for weeks. I submit code incrementally.

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

#282

Post by robertlagrant »

jerf wrote: post #81
shados wrote: post #32

Earlier quoted context omitted.

Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile". When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel. If you don't, or do "Scrum but not quite", then when things don't quite work out,…

If you do "Scrum, exactly", then when things don't quite work out, being "on your own" is the best case scenario. Worst case is that someone yells at you and blames you because Scrum Objectively Works so it must be your fault. I see no reason to believe that Scrum is a tightly tuned machine that must be precisely run to work at all, and any deviation from it makes it fall apart. In fact, if that is the case for Scrum…

> Since the only practical algorithm to explore this landscape is gradient descent

That's why an algorithm was not used. Effectiveness has not been sufficiently analysed to be reduceable to a line on a graph.

> Do real agile, all the time.

People who call something "real" without defining what "real" is may be well-practised at sounding nice and emphatic in meetings, but without any detail it's hard to see it as anything more.

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

#283

Post by datavirtue »

numbsafari wrote: post #165
jermeh wrote: post #125

Earlier quoted context omitted.

I work in a "traditional company" and the gatekeepers were installed to keep developers from going insane. When we have too much information back and forth between business and engineering, the loudest complaints from the business side (where the $$$ comes from today and tomorrow) drowns out the team's and department's internal goals, which are usually much longer term (meaning the $$$ is in months or years, not next…

This is because businesses chronically underinvest in developer/engineering resources. Developers tend to be viewed as something that is not "core" to the business, and generally only necessary on a project-by-project basis. So, projects are initiated, resource needs identified, and, since nobody wants to hire a bunch of full-time staff, most likely a consulting firm or off-the-shelf product is selected and configure…

You think they would be taken aback by the cost of a temp developer. In my case we easily charge the salary of two or three junior devs for one person and we are very sticky...not one contractor was out of work during the pandemic while those companies laid off FTE in significant numbers.

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

#284

Post by robertlagrant »

snuser wrote: post #249
optymizer wrote: post #194

Earlier quoted context omitted.

In my experience, junior developers like the rigid structure and senior developers would prefer more flexibility. Companies that implement agile to the letter typically treat their developers like consultants. You're treated as a mindless drone that is supposed to work on tasks that were predefined for you. You might as well be outsourced. I found that kanban-style works better imo. A prioritized backlog where you pi…

Every company I've worked at that followed some sort of rigid scrum process has suffered from burnout and general failure in one form or another It treats developers like consultants because it's really designed for agencies working on one-off short-burst projects ( this is the only setting I've seen it have a positive effect ) by nature it just chews people up if it becomes a day-to-day practice, the whole process r…

> the whole process revolves around the assumption that there's lack of trust and team cohesion

Where in Scrum is this defined?

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

#286

Post by robertlagrant »

osigurdson wrote: post #104
raverbashing wrote: post #46

Earlier quoted context omitted.

I suspect the prescriptivism and detail have one end goal and that is for someone that has no idea how software is done to follow the procedures. It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt. You also have to deal with people who needs to be told which shoe to put in first before they think the process is "confusing". Same reason for PMP, it'…

The issue with all of this addition process, ceremony and meetings is work still needs to get done. Sadly the only time to do work is often outside of working hours since then, finally, the meetings and ceremony have ended.

I don't think this is the case. A two week sprint should have about 100 minutes of standup, 1 hour of planning, 1 hour of refinement, half an hour of review and 1 hour retro, ish (I can't remember the exact timings). About 5 hours every 2 weeks. Saying that adds up to a full 2 weeks of work is just... pointless. So falsifiable.

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

#287

Post by robertlagrant »

hatchnyc wrote: post #75
whynotmaybe wrote: post #43

Earlier quoted context omitted.

I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted". Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.

My experience has been the exact opposite, if the developers understand what the business is trying to accomplish and what the incentives are then they are in a much better position to prioritize and build the right thing. Every single time I’ve seen 6 months of work on a useless or low value feature it has been the result of the dev team getting requests via some PM telephone game.

This is a tricky balance. Developers can also get overwhelmed with requests for estimates, automation tasks, etc etc, and get annoyed that people have so much contact with them. But it is a tricky balance; there's no obvious solution.

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

#288

Post by datavirtue »

hiptobecubic wrote: post #182
spaetzleesser wrote: post #126

Earlier quoted context omitted.

I have seen it more often that gatekeepers filtered user demands based on their own knowledge and not on technical feasibility or effort. So you are told that a user needs a certain thing in a certain way but when you talk directly to the user you learn that the user actually had a different need which you can fulfill in an easier way than the gatekeeper thought possible. In general I think there is a huge advantage…

The whole point is that this doesn't scale. What do you do when there are too many users to interview them all over coffee?

You have key business ops people AND their key users (direct reports) involved. It scales.

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

#289

Post by smusumeche »

bitwize wrote: post #246
commandlinefan wrote: post #214

Earlier quoted context omitted.

> whether they'd done exactly the "right" stories in a 2 week sprint Not only that, but if anything else comes up during the "sprint", you're expected to address it while still finishing everything that you (involuntarily) "committed" to during sprint planning.

WE committed. We made these commitments as a team. If you can't fulfill what has been committed to by the team, then we as a team have to have a discussion about that. I'll put the meeting for next Monday on everyone's outlook.

I'm triggered.

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

#290

Post by datavirtue »

tombert wrote: post #236
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…

Yeah, I learned the hard way that one of the worst things you can say at a megacorporation is "this manager is just creating work to justify their existence in the company". In my case, it was directly applied to a specific manager (who heard me say it), and it led to me being lectured and yelled at and told that it was "unprofessional" talk (which to be fair it kind of was).

Yelling at people at work is unprofessional. Sometimes it's illegal if you are a federally protected class.
Post reply on HN