Live data from Hacker News

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

newsletter.pragmaticengineer.com

131–140 of 452 posts

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

#131
post #89

I really want to say this: SAFe is an awful process and a trend that will hopefully go the way of Unified Process/RUP. I won't go into it, but it's largely created and popularized by a vendor to sell their software. It is poison and exists to keep its practitioners employed. It attracts the highest-ego PMs like moths. I find it interesting that they author references Skype circa 2012. It sounds like classic "uppercas…

As a Dev, I loved SAFE. It changed everything about how our program operated to the point our delivery became extremely predictable and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted. That program purred like nothing else I've ever been a part of. Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen befor…

“Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen before we started doing PI events”

Pretty much every process will work successfully if everybody participates in good faith. I don’t think SAFe has special properties that people honestly work together. For example in my company it would just create a new bureaucratic nightmare where we would hire even more managers, project managers and consultants while senior leadership still would never talk to the lower ranks.

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

#133
post #125

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

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…

The trick big tech uses to solve this is to not just pay extra for above average engineering talent, they pay extra for above average talent in all areas. So the people you talk to are almost always pretty reasonable and understanding, they want things done and complains but they don't ask for the impossible or unreasonable.

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

#134

Earlier quoted context omitted.

I have been on teams like that. It's just biweekly planning meetings. I don't see how that means you pay the full costs of something like Scrum.

Is biweekly twice a week or every two weeks? My previous gig had grooming/internal grooming every week. We had stand ups twice a week (biweekly). Almost all of these meetings were relatively worthless imo. They existed to justify a BA's position and "track velocity".

Every two weeks, in our case. Confusing word, sorry. We had two week "sprints". Every day a 15 minute standup before lunch.

We planned what we were going to do the next two weeks. During that time urgent work would also be added and other things wouldn't be finished, but they just moved to the next sprint. Releases were quarterly (customers didn't like frequent releases) so not related to the "sprints".

Some managers described this as "Scrum light", fine with me.

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

#135
I don't get Jira hate. It may be clunky, slow and overcomplicated but really it's just system to document stuff. If you don't document stuff on a sufficiently big project (I'd day >10 engineers, and especially at >100) then it's a recipe for a disaster.

As for solutions to document stuff, specifically issues, then Jira seems to be ok and not lacking in any area, maybe not a leader but not a worst thing to use too.

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

#136
post #125

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

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…

The problem arises when the gatekeeper either no longer understands or no longer cares why their position exists. Then they just become an obstacle to the very communication they are supposed to be there to facilitate.

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

#137

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

My current company is like this. I work directly with the business people anyway. When anyone says anything I just point them to my output, quality, and the feedback from the business people - shuts them up every time.

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

#138
post #93

Earlier quoted context omitted.

We have sprint retros and generally find them valuable. I’m curious how one would even go about incorporating music and movies into a sprint retro? That does sound painful.

I think they mean when your retro board has a theme; I've seen various themes applied successfully i.e. sailboat: https://metroretro.io/templates/the-sailboat-retrospective

Is it just me or does this look great for a 2nd grade class.

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

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

> there's a good chance one of them knows something the other does not

Or that the assignment of points is arbitrary and imprecise and that different people have different ways of making up numbers.

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

#140

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * Devs make their changes locally,…

Every commit is code reviewed separately and merged to master after review + automated test gatekeeping as necessary. Additional testing may occur downstream post-merge which may cause your commit to rolled back automatically. Time to deployment into production depends on how those deployment pipelines are built, could be minutes to days before it lands.

It's very unusual to merge more than one commit to master at a time.

You can think of it as a branch and merge approach, but the set of changes is small - a 100-line diff would be a large change (automated changes and deleting unused code excepted). The process and tooling optimizes for small changes. Refactoring is done incrementally. Big changes are gated with flags so they can be built incrementally and rolled out incrementally and turned off at the first sign of trouble.

Post reply on HN