Live data from Hacker News

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

newsletter.pragmaticengineer.com

251–260 of 452 posts

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

#251
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, 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."

I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't change, and sometimes fairly frequently?

I mean, just the difference in an iteration with a couple of people on PTO, or a holiday or two intruding into it, will throw the numbers off. Now factor in all of the other fuzziness that's inherent in the process... yeah, no. Don't bother trying to calculate or track "velocity". You'd probably get better results from Tarot cards or animal entrails.

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

#252
post #89

Earlier quoted context omitted.

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

SAFe has roles. If you don't have people doing those roles, you're not doing SAFe. If you have people doing roles that aren't in SAFe, you're not doing SAFe. It's really quite simple and I don't understand the pushback. Do it or don't, but trash it if you didn't actually do it.

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

#253
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, 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.

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

#254
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 i…

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

The thing I think that fails to be recognized about Agile (though there is a lot adjacent to it, without outright calling it out, in the central documents) too often is that Agile has fundamental tension with the project-oriented, and even to a lesser extend product-orient d, mindset, and really calls for a mindset in which technology is an integral component of continuous end-to-end business process improvement. It can be adapted to product- or project-oriented environments, but only with compromise.

> The flexibility of scrum is being able to say what is done represents a working though not fully featured product.

The flexibility of Agile in general comes in rejecting products as a goal to themselves, and recognizing that technology is part of a broader system of delivering value and any improvement in value delivery is worthwhile according to the value delivered compared to the cost of delivering it.

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

#255
post #200

Earlier quoted context omitted.

What would you do to go from PR to prod faster when you want at least 1 human who didn't open the PR to manually review each PR in a 10-20 developer remote team? 1 day doesn't seem too bad, often times it can be 2-6 hours. It really depends on what lines up and how big the PR is.

A code review for a smallish change shouldn't take more time than sending a few chat messages. You send them the code review, they look through the 20 lines in the code review tool, note that the changes corresponds to the change description, see that you added tests for it and that those tests passed, they ask you to clarify a variable name, you update the code and send it again a few minutes later, they review the…

Yep, what you described is how most reviews go.

The delay isn't always around the review itself taking long. It's having a dev working on their own tickets and then having an opportunity to check in and review someone elses code. You could end up getting a review on your code in 10 minutes or 5 hours based on what's going on for everyone at the time you open the PR. It might even take until the next day and for a bigger PR it could involve a few more eyeballs and time commitment for the review itself (outliers but they do happen).

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

#256
post #175

Earlier quoted context omitted.

... that's usually the people that try to bring this stuff in...

As a former engineer who used to deal with the bone-crushing tedium of fundamentalist Scrum, I have enough empathy for my team to not force this crap on them. I keep the process light, communicate a lot, and treat them like adults.

> I keep the process light, communicate a lot, and treat them like adults.

That sounds like fundamentalist Scrum.

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

#257
post #188

Earlier quoted context omitted.

At the last large traditional place I was at it seemed a lot like the upper management types had put these gatekeepers in place so they had people that would pander to them. The amount of times one of them told me they couldn't tell their boss some bad news for risk of getting fired or chewed out, but wouldn't let me go and tell them the truth was mad. From what I could tell no-one was firing engineers because it was…

A clear implementation of the Thermocline of Truth - https://brucefwebster.com/2008/04/15/the-wetware-crisis-the-...

Yeah that all sounds very familiar.

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

#258
I have come to the conclusion that is not about the methodology but the people. I worked in super productive teams that were not following any "agile" methodology, or really any particular methodology.

The goal was to get shit done and make customers happy.

On the other end of the spectrum, I have worked with teams that were pretending to embrace agile and scrum methodology though could keep standup quick and sharp.

It was an excruciating ritual that would take my most productive hours of the day: every day!

I always try to work with smart people. People who don't need much direction and know how to get things done.

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

#259
post #197

Earlier quoted context omitted.

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

Thank you I will look into it!
Post reply on HN