Live data from Hacker News

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

newsletter.pragmaticengineer.com

241–250 of 452 posts

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

#241
post #84

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 problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…

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

This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."

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

#242
post #215
post #70

Earlier quoted context omitted.

You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.

Any workflow that involves breaking master for everyone seems broken at some level. Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.

Master isn't broken for everybody though? Its just broken for those projects whose tests are broken, everybody else can still work as normal.

So unless you have a ton of dependencies you wont notice much breakages from other teams.

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

#243
post #44

I worked at a big tech for many years and my team never managed to get Scrum working properly. Every year my team commits a delivering certain product/features at a very specific date (some sort of launch event), so we have to know very early in the year what's all the work required and report periodically whether project is on track. The deadlines are also always on the tighter end. The flexibility of Scrum becomes…

If you have a set date and a set scope you can't be agile. Agile needs to be ale to radically change scope or even cancel projects outright. You can get lucky sometimes that a feature takes less or about the same time as you have and make things look agile.

The flexibility of scrum is being able to say what is done represents a working though not fully featured product. You can generally send red flags a lot faster in scrum, but you still need management that believes and understands those flags.

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

#244
post #84

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 problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…

> 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 trackability, measurement, and metrics, because everything is. Trackability and measurement enable key decision makers to make accurate budgeting and execution plans and there is literally nothing else for key decision makers. Therefore, it makes less of a difference what you output than that it was properly planned for, tracked, and measured and that it hits organizational KPIs. That's why nobody cares that Scrum is a giant productivity suck. Code could be written faster, but that's not writing it properly.

Agile in the enterprise is a game of Mornington Crescent. The goal is not to foster the things advocated in the Agile Manifesto. It's to make it look like the company is fostering those things, while actually promoting the same Taylorist values corporations have always loved (and workers hated).

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

#245
post #84

Earlier quoted context omitted.

The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…

" I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how…

Very widespread. If you're working for a non-startup, non-FAANG-tier company, expect metrics to trump all other concerns.

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

#246

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". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how…

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

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

#247
post #84

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 problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…

> In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible.

This is exactly how I've seen it run with success at several different companies (including how I run it).

In my mind, the most important value of Scrum is having a cadence to give people reasonable timeframes to think in AND ensure that a variety of different conversations happen frequently enough (discovery, planning, prioritization, execution).

----

> And retro - gawd, I hate those.

It sounds like you hate these because you aren't actually empowered to make meaningful change within your team.

We've found retros are one of our most important rituals. They help us identify risks, process, and team issues; often while they're still small. We quickly work those in.

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

#248

My sole experience in Big Tech consists of Facebook and the post more or less matches what I saw there. It seems to me, though, that the author views "no process" from a very positive lens, with no discussion of negatives. Like how at FB so many teams use spreadsheets to track their work (sometimes multiple spreadsheets per team, sometimes no tracking at all). There is some internal tooling, which is quite basic and…

This matches my experience at Google.

Scrum/Agile tells you to split up a project into well defined tasks to be done simultaneously by multiple people.

That's counterproductive if, come perf, you need to show that you completed the project, and distinguish your contribution from others'.

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

#249

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

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 revolves around the assumption that there's lack of trust and team cohesion

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

#250
post #197

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". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how…

Can you link me or someone else link me what you would consider the "ultimate kanban guide"? I work in an environment that had no project management tools or methods being used other than emails and I've finally gotten buy in on Kanban and I want to make sure I guide my team properly.

Kanban in Action by Marcus Hammarberg and Joakim Sundén is a good introduction. In this book, the guiding principles of Kanban are presented almost like parables as the authors introduce you to their fictional team "Kabaneros".
Post reply on HN