Live data from Hacker News

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

newsletter.pragmaticengineer.com

291–300 of 452 posts

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

#291
post #32

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

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

People say that about communism too. I'm not open to debate any of the tankies I know are on HN, but if a paradigm brings utopia if implemented properly, and misery otherwise, and there have been no known utopia-yielding instances of the paradigm despite repeated attempts, it's time to consider that maybe misery is inherent to the paradigm.

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

#292

Earlier quoted context omitted.

But is there evidence the force is actually multiplied in practice?

Pretty sure there isn't, otherwise FAANG would enforce it top down. They already enforce other practices top down like hiring etc, so if they had data saying that mandating Scrum would make the company X% more efficient they would absolutely do it. It might be a force multiplier in other types of companies, but it probably isn't in FAANG style companies. Similar to how FAANG hiring can make sense to them but still be…

I mostly agree with this perspective. Alternative agile methodologies may fit better with certain teams (e.g. Kanban, lean, etc) and so having a top down prescriptive method of "agile" doesn't make sense. Another perspective is that Scrum is agile training wheels. Once a team can discipline themselves enough to follow a Scrum workflow successfully for a significant period of time, it shows they are ready to follow a more flexible agile approach and therefore may no longer need a Scrum leader guiding the team.

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

#293
As someone who currently works at a Big Tech company, but spent most of his career prior to that at smaller companies, I found this article very confusing.

First of all, I work at Amazon (and posting this under our social media policy, this is just my experience, and I don't speak for the company), and Scrum is pervasive at Amazon. The article is right that many big projects start with a 6 pager, but once teams start executing, many teams run some form of Scrum (Kanban is also popular).

The second thing I found strange in this article was the idea of Scrum being heavy-weight. Early in my career I worked at a small company where our process guru was a big fan of the Unified Process. The point of Scrum is that it is lightweight (without being zero process). There really isn't a lot to it. You sync with your teammates daily, to make sure you're all focused on the most important thing today. You check in every 1-4 weeks by (a) demoing your software to figure out where you are, (b) you do a retrospective to look at what can be done better, (c) you figure out what is the most important thing to be doing the next N weeks. The teams that I've been on that have tried to not do these things either in actuality, did these things, but did them subconsciously, and therefore unintentionally. When I hear people say "Oh, I don't like Scrum because my old team did Scrum and I didn't like how we..." what follows is almost inevitably something that if you asked a professional scrum coach "Should we do that?" the answer would be no.

> Competent, autonomous people need less structure to produce reliable, high-quality output. Big Tech is able to attract, afford and hire these people.

I don't like this way of thinking. Start-ups have lots of competent, autonomous people. Big Tech companies have lots of people early in their careers that are still learning to be autonomous. In fact, when I was at start-ups I often heard the opposite (and equally untrue) claim: that start-ups required people with more autonomy, because the product is new and the team is involved in discovering the product, whereas in larger companies the products are more defined, so people needed less autonomy.

I appreciate the author surveying people and trying to make sense of the results, but in this case I think he just over-simplified a much more complex reality in a way that isn't particularly helpful.

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

#294

Earlier quoted context omitted.

SAFe is just waterfall management with agile keywords tacked on. It's not an engineering methodology. The only "problem" SAFe solves is reintroduction of deadlines and quarterly objectives, which flies in the face of everything agile actually stands for.

It doesn’t do any of those things. The quarterly PI’s are for planning because the most you can reasonably plan for with any degree of accuracy is about 8-12 weeks. There are no deadlines imposed. You plan what you’re going to work on and how long it will take. You coordinate with other teams for any dependencies they may need from you and when. But you as a developer are responsible for saying how long it will take…

> You as a developer are responsible for saying how long it will take and when you can have it done.

Which amounts to estimating software deliverables beyond the scrum window, which will invariably lead to disappointment, which will eventually fallback upon the shoulders of devs. It is impossible for delivery dates beyond the estimation horizon to not start being used by management as an anchor at some point in the near future. It only takes one manager promising stuff for the rest of the management team to try and emulate the savior.

Teams coordination only requires timely backlog priority management and does not need to be planned top-down for days on end with all members of all teams present.

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

#295

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

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

> It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt.

This is not just a scrum problem. Any agile process eventually reports to a layer of management that doesn't think in agile terms, and wants their PERT charts or whatever. The impedance mismatch at that boundary is one of the biggest difficulties with implementing agile.

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

#296

Shape Up: mentioned for a few venture-funded companies. Has anyone here some experience with Shape Up? Love to hear your thoughts. I just read about it so far and would love to hear some real-life stories.

We adopted it a year ago and the team still quite likes it. Reduced day to day stress and distractions and a good structure and shared vocabulary. Wouldn’t say it’s perfect but much nicer than the sprint treadmill.

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

#297
post #32

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

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

The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worked for you, you must've done it right.

> If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.

So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?

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

#298

Earlier quoted context omitted.

Sometimes importance is related to size. Points are arbitrary, but lets assume that on average a developer will work the entire sprint on an 8 point task. The PM might decide that feature is not worth the time investment in that sprint, if they could instead get 2 smaller features out the door, or some bug fixed - they might prefer to deliver that to stakeholders. That's why there's even a velocity expressed in point…

Bugs get resolved desk-side five minutes after being reported and pushed through on PRs that have 89% test coverage (still green!). Developer is a cowboy hero! The good thing is: you always get more bugs like this so everyone gets a chance to be a hero.

Must be nice. I've yet to see that happen at 'big tech' companies.

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

#299
post #249

Earlier quoted context omitted.

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?

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.

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

#300
post #83
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,…

>Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. I remember when Scrum came out. It's a very specific method for a very specific company type that was sold to work with any company. Before scrum, each company kinda figured out their own processes based on their size, team…

Anecdotally, I've experienced the exact opposite. The company I work with had been doing waterfall development for 15+ years. We switched to agile using the Scrum framework. It wasn't smooth sailing the entire way, there were teams early on that struggled with adopting Scrum. Most often it was due to the team attempting to solve every retro issue by updating "the process", which only addressed symptoms instead of fixing underlying communication problems within the team. The other major hurdle was getting product to accept that a roadmap isn't a set of commitments but is instead a list of prioritized "wants". Now, we're 3 years out from the switch and most of those pain points have been removed. It's lead to massive improvements in quality, predictability, and overall happiness across the company.
Post reply on HN