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

311–320 of 452 posts

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

#311

Post by tootie »

softwaredoug wrote: post #6

At Shopify, we tend to do whatever our engineers want in this regard. My team meets weekly and looks at a kanban project board. If we need to adjust, we have retros, etc and change the process. We have the autonomy. In a past life you would be told Agile meant “self organizing teams”. But in practice that was only allowed in a narrow definition of change under the prescribed process being foisted on teams from above.…

I find this concept utterly baffling, but probably because I've never worked at this kind of org. I can see how letting engineers run their own process is great for engineering efficiency, but how do they know what to deliver and when?

My conjecture (please confirm or deny) is that these self-organizing teams are a result of and not a cause of big successful companies. You are probably iterating on a very well-understood and successful business model with a huge cushion for mistakes because you have some much revenue.

By contrast, I have mostly worked in consulting and non-tech orgs. If we don't show that we're spending their budget on high value features, we get layoffs. Hence we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.

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

#312

Post by samdjstephens »

Jensson wrote: post #133
jermeh wrote: post #125

Earlier quoted context omitted.

I work in a "traditional company" and the gatekeepers were installed to keep developers from going insane. When we have too much information back and forth between business and engineering, the loudest complaints from the business side (where the $$$ comes from today and tomorrow) drowns out the team's and department's internal goals, which are usually much longer term (meaning the $$$ is in months or years, not next…

The trick big tech uses to solve this is to not just pay extra for above average engineering talent, they pay extra for above average talent in all areas. So the people you talk to are almost always pretty reasonable and understanding, they want things done and complains but they don't ask for the impossible or unreasonable.

I think it’s deeper than that - these companies place product/engineering at the centre of the business, rather than at traditional companies that still see it as a cost centre.

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

#313

Post by shados »

void_mint wrote: post #297
shados wrote: 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,…

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

I think I'm expressing myself incorrectly.

Scrum "by the book" has a lot of material on the edge cases. How you handle almost every case that can happen in a software development team. So you can follow it like a workflow. Something unusual happens, you look in the book, do what it says. It's flaws are fairly well documented and understood, too. That's what I mean by being "on your own" if you don't follow it. At that point you can't just use a book to figure out next steps. You have to actually talk it out and use your brain to figure out what to do, because its unlikely your internal process has as much documentation around every single "paved paths".

It's also just a process. What does it mean not to find success here? If you ship broken software, it's unlikely to be because you didn't move the right ticket in Jira.

If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc.

Don't get me wrong: I very much dislike Scrum and you'll never see me push for it in a team. My point was merely that if you take an "On rails" experience like Scrum, and tweak a few little things, you lose on almost everything. The books no longer apply. When the entire point of this particular process is basically the books and documentations, doing "Scrum but not quite" really kills the point.

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

#314

Post by tombert »

datavirtue wrote: post #290
tombert wrote: post #236

Earlier quoted context omitted.

Yeah, I learned the hard way that one of the worst things you can say at a megacorporation is "this manager is just creating work to justify their existence in the company". In my case, it was directly applied to a specific manager (who heard me say it), and it led to me being lectured and yelled at and told that it was "unprofessional" talk (which to be fair it kind of was).

Yelling at people at work is unprofessional. Sometimes it's illegal if you are a federally protected class.

I'm definitely not a protected class (I'm a tall white dude), and I am not being 100% fair; they weren't screaming at me or anything, just an elevated voice and very angry words. I don't believe they said any curse words, and even if they did I was somewhat sympathetic to why they would be upset with me (even though I do stand by the content of what I said).

It was probably still unprofessional, but probably not as bad as I made it sound...my bad!

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

#315

Post by shados »

bitwize wrote: post #291
shados wrote: 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,…

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.

You're not wrong. Communism implemented perfectly would also work beautifully. It just can't.

The main difference here is that Scrum is not nearly as complicated to implement. Though the issue is the same. There's always someone somewhere who thinks the process doesn't apply to them and the whole thing falls apart.

I did work in one company that had a fairly well implemented Scrum, and it did work pretty well. I've never seen it replicated though, so for all practical purpose, it's exactly as you say: it's not worth trying because it only works when done perfectly, and that almost never happen.

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

#316

Post by bennysomething »

hallway_monitor wrote: post #163
bennysomething wrote: post #107

Earlier quoted context omitted.

It also fits very well with feature factory shops: a story fits nicely into a single feature. God help you when you are trying to build a system from scratch with scrum overhead. Not everything is a story or a ticket. It's painful.

This one hurt, it's exactly what I spent the past 18 months doing - building a new system. Luckily my director was sympathetic but the Company loves Scrum and Metrics. Tried to change process unsuccessfully, so I quit to work somewhere saner.

Yeah it's awful, the amount of overhead each ticket generated. Testers want to test each ticket. The more I hear about Microsoft's old way of building software the more it makes sense: have a soec that can change.

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

#317

Post by giantrobot »

mindcrime wrote: post #251
robertlagrant wrote: post #241

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

I too find velocity to be one of the dumbest aspects of Agile. It takes the stupid of story points and doubles down on uselessness and arbitrariness.

Velocity in physical terms is an instantaneous measure. It's the same in Agile, you've done X things in Y time. But that ignores the context of those X tasks and the context of Y time.

The X+1 task might turn out more difficult or have some other challenge that makes it take longer. Time keeps passing so at time Y+2 the velocity measurement is lower than before. Now all the PMs and other team members jump in demanding answers which now makes the task take even longer.

As you mention, some span of time can see team members out or unavailable. So the velocity is "low" but rarely is that context captured or bubbled up the management chain. So your team has "low velocity" which ends up generating worthless meetings, bad reviews, or all sorts of problems.

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

#318

Post by clumsysmurf »

arcbyte wrote: post #89
throwaway5752 wrote: post #29

I really want to say this: SAFe is an awful process and a trend that will hopefully go the way of Unified Process/RUP. I won't go into it, but it's largely created and popularized by a vendor to sell their software. It is poison and exists to keep its practitioners employed. It attracts the highest-ego PMs like moths. I find it interesting that they author references Skype circa 2012. It sounds like classic "uppercas…

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…

> and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted.

We do PI planning from SAFe. We would get the last sprint of quarter for slack, improvements, they said.

Instead, we use it to clean up the mess created from waterfall scrum in the previous sprints.

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

#319

Post by ebiester »

g051051 wrote: post #171
mbeex wrote: post #164

I was there when Agile was invented. In my opinion, Scrum has always been the worst embodiment of a good idea. In terms of content, teams of experienced developers have always worked in the spirit of Agile (of course there are exceptions). This informal understanding was and is superior to a formal horizontal Scrum implementation. For example, it preserves seniority and true accountability - two things that Scrum pre…

> These days, mandatory Scrum is a contra-indicator for any project that crosses my path as a freelancer. Yes! Although I don't agree that Agile is a good idea that scrum ruined.

How long have you been in the industry?

Agile in 2021 means something different than Agile in 2002. Project Management was a different consideration 20 years ago.

Which of these do you disagree with? https://agilemanifesto.org/principles.html

I disagree with 2. Now, perhaps you disagree with 5. These were written in 2001 for problems in 2001. Now, some of these problems have been solved. Some of them are taken for granted today. However, we take them for granted in large part because a group of people got together and said, "we can do better."

I personally think it's time for another group (not the old agile luminaries but people with new ideas) to take a look at today's problems and take a fresh stab at it. Maybe it looks like "Plan-Build-Ship." But maybe it looks different.

But first, I think we need a clarifying question: What in the principles or manifesto do you disagree with?

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

#320

Post by sunwooz »

akudha wrote: post #84
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 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…

Oh god, this perfectly describes the company I just quit. They went from using Trello, allowing us to choose what to work on, loosely setting story points and ... that was it.

Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the product manager the power to dictate what I work on and in what order.

It went from being a great company to work at, to a company I ran away from. I have half a mind to send this thread over to them.

Post reply on HN