Live data from Hacker News

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

newsletter.pragmaticengineer.com

441–450 of 452 posts

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

#441

Earlier quoted context omitted.

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…

Maybe if you don't fill a team with nine juniors that have no mentors, you don't get this problem? It's not like FAANG isn't hiring boatloads of new grads every year. Why don't those people need scrum to get on the right track, but half the rest of the industry seems to?

FAANG has a lot of metrics and rituals (planning/RFCs/6-pagers, retro, reviews, 360 reviews, some do sprints, some don't), the do their own scrum.

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

#442
post #381

Earlier quoted context omitted.

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.

Sometimes it's helpful to have some division of labor between field/sales/support engineers who go to handhold customers, understand their particular problems, and prototype fixes, and "product engineers" who have less customer interaction. This is somewhat similar to the SRE/SWE split at places like Google. If I were designing an organization with such a division of labor, those wouldn't be different job description…

> Bill Gates found it useful to answer tech support calls as late as 01989

This is good, but it's easier when you're a very extraordinary human, and your own boss!

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

#443

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, with pretty graphs describing "velocity" and other buzzwords. You've discovered the secret of Agile in the corporate workplace: that the key takeaways, as far as the enterprise is concerned, are not finding better ways to develop software and better customer-developer relations. It's all about trackabil…

Agile in the enterprise is a game of Mornington Crescent. That's probably the best description of "agile in the enterprise" I've ever read.

Almost:

"Interspersed with the turns is h̶u̶m̶o̶r̶o̶u̶s̶ 𝗯𝗼𝗿𝗶𝗻𝗴 discussion among the panelists and host regarding the rules and legality of each move, as well as the strategy the panelists are using. The actual aim of the g̶a̶m̶e̶ 𝗰𝗲𝗿𝗲𝗺𝗼𝗻𝘆 is to e̶n̶t̶e̶r̶t̶a̶i̶n̶ 𝘄𝗮𝘀𝘁𝗲 𝘁𝗶𝗺𝗲 𝗮𝗻𝗱 𝗺𝗶𝗰𝗿𝗼𝗺𝗮𝗻𝗮𝗴𝗲 the other participants and listeners with a̶m̶u̶s̶i̶n̶g̶ 𝗿𝗲𝗽𝗲𝘁𝗶𝘁𝗶𝘃𝗲 discussion of the fictional rules and strategies."

https://en.wikipedia.org/wiki/Mornington_Crescent_(game)

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

#446
post #381

Earlier quoted context omitted.

Sometimes it's helpful to have some division of labor between field/sales/support engineers who go to handhold customers, understand their particular problems, and prototype fixes, and "product engineers" who have less customer interaction. This is somewhat similar to the SRE/SWE split at places like Google. If I were designing an organization with such a division of labor, those wouldn't be different job description…

> Bill Gates found it useful to answer tech support calls as late as 01989 This is good, but it's easier when you're a very extraordinary human, and your own boss!

Yeah, but Bill Gates managed to do it too.

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

#447

Earlier quoted context omitted.

Maybe if you don't fill a team with nine juniors that have no mentors, you don't get this problem? It's not like FAANG isn't hiring boatloads of new grads every year. Why don't those people need scrum to get on the right track, but half the rest of the industry seems to?

Those companies are very engineering-led. Boatloads of excellent engineers; deadlines are "it'll be ready when it's ready"; marketing is (and thus marketing deadlines are) light, so there's less planning needed; featuresets are largely defined by the engineering teams. Anything that is reasonably unpredictable in terms of requirements but needs to be reasonably predictable in terms of feature delivery speed is a good…

Google Cloud is not at all "it'll be ready when it's ready" with light marketing and feature sets defined by engineers.

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

#448

Earlier quoted context omitted.

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.

Unless you work on an internal tool "business ops" are not your users. I'm talking about real products with external users that are only really identifiable as an "account" unless it's a massive contract with dedicated sales team.

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

#449
Pardon me for blowing my own horn, but as an alternative to all the usual approaches (Scrum, Kanban, SAFe, LeSS, etc.), for software engineering management at scale, my I suggest my own "TameFlow Approach"

It is based on Patterns and the Theory of Constraints.

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

#450

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

Constructive / progressive organizations can be built or transformed into, where collaborative knowledge-work happens at all levels.

Scrum is a parody and pretty much anti-agile.

Traditional organizations are driven by the cost-accounting mindset that creates gate-keepers and makes it impossible to share a common purpose, let alone collaborate across teams, units or vertically.

Post reply on HN