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

71–80 of 452 posts

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

#71

Post by brightball »

namdnay wrote: post #42
brightball wrote: post #12

Everything described in there is mirrored in SAFe fwiw, even though their survey said it was mostly used in large non-tech companies. Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and cont…

SAFe is beautiful in that it is the ultimate expression of Enterprise Agile Cargoculting: all pretenses of agility are lost, there are ten different levels of decision making, and all responsibility is diffused in a confused mess of worker bees running around under an all-powerful and all-seeing LPM > Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team) Except tha…

You have PTSD from a bastardized version of SAFe, based on your description.

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

#72

Post by brightball »

jon-wood wrote: post #30
brightball wrote: post #12

Everything described in there is mirrored in SAFe fwiw, even though their survey said it was mostly used in large non-tech companies. Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and cont…

I'm sure there's some nuggets of value in SAFe, but I just can't take anything seriously which welcomes you into it's world with this diagram: https://www.scaledagileframework.com/wp-content/uploads/2021... Also note up in the top left corner, where you've got the customer abstractly feeding work into this treadmill of... stuff. If your development team aren't talking to either the customer, or representatives of the…

I do hate that diagram.

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

#73

Post by twic »

sparsely wrote: post #55
whynotmaybe wrote: post #33

Earlier quoted context omitted.

Maybe have a look at this https://trunkbaseddevelopment.com/

This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)

> This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in

No, in trunk-based development, you push to the trunk, aka master.

The difference is perhaps not that big; with TBD, you have a branch, but only on your machine, which you merge to master before pushing, whereas with the second workflow, you push your master, then merge somehow.

> their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?

I don't understand this. Of course you can and should run all tests locally.

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

#74

Post by williamdclt »

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 explained principles is not enough to know how to apply them: Scrum is not a bad starting point to be in the right-ish track without really knowing what you're doing. As you gain experience, it's natural to want to shake off constraints, that's Ha and Ri

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

#75

Post by hatchnyc »

whynotmaybe wrote: post #43
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…

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.

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

#76

Post by sparsely »

twic wrote: post #73
sparsely wrote: post #55

Earlier quoted context omitted.

This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)

> This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in No, in trunk-based development, you push to the trunk, aka master. The difference is perhaps not that big; with TBD, you have a branch, but only on your machine, which you merge to master before pushing, whereas with the second workflow, you push your master, then merge somehow. > their intermediate setup seem…

> No, in trunk-based development, you push to the trunk, aka master.

If you follow the ops link there are multiple diagrams where that is not the case.

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

#77

Post by ryanmarsh »

Scrum is merely a batch oriented process. In (process) control theory there is over 100 years of study of batch, continuous flow (e.g. Kanban or Lean), and other types of processes.

Each has benefits and tradeoffs. Like all tools the proper process type for your project will be context sensitive.

For an industry so full of smart, supposedly logical, people ours is still quite immature and tribal in its management theory.

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

#78

Post by Scarblac »

mindvirus wrote: post #4

One pet peeve of mine: people often say they run a "lightweight" version of some project management philosophy and end up paying the costs of it without the benefits. For example lightweight agile scrum meaning sprints, but no retros and work constantly coming into and out of a sprint.

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.

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

#79

Post by whynotmaybe »

sparsely wrote: post #55
whynotmaybe wrote: post #33

Earlier quoted context omitted.

Maybe have a look at this https://trunkbaseddevelopment.com/

This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)

One of the premises is that the minimum level of competence of the team should be above average, which is not feasible everywhere.

And

"The short-lived feature branch should only last a day or two and never diverge from the trunk enough so that a merge back is problematic. After the seal of approval from code reviewers and CI daemons, it should be merged back into the trunk. It should be deleted, as proof of convergence. The developer in question may then go ahead and make the next short-lived feature branch for the next story/task they’re doing" https://trunkbaseddevelopment.com/youre-doing-it-wrong/#dura...

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

#80

Post by mandevil »

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…

In my experience, there is no good solution to this problem- when feature X comes along and it is decided that the ongoing work on A,B,C need to be paused because X is that important, there really is no way to quickly context switch back to A,B,C after X is finished.

The best thing you can do, in my experience, is make sure that the devs are fully bought in on why X is so much more important than A,B,C. Ideally, you want to present it to them as 'X enables us to get this contract/solve an uptime issue/whatever' and then let them decide, as a group, that maybe we continue on B while the two working on A and C instead focus on X.

Post reply on HN