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

91–100 of 452 posts

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

#91

Post by afarrell »

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…

> instead of trying to "processify"

A cause of this problem is when people are worried about what happens when they say "erm, I don't know how to do this cleanly" and so they want the "how" to be defined far far in advance. Solving this requires a mix of

A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden. Those activities will vary based on team members individual peeves and affinities.

B. Creating clear lines of communication for how and whom to ask for help. This often means more clear naming of responsibilities.

C. Ensuring there is enough slack time for people to be able to help each other out.

D. Creating trust in the team that asking for help won't lead people to question if you are fit to do your job.

> quantify everything

Many times, this is the https://en.wikipedia.org/wiki/McNamara_fallacy

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

#92

Post by pc86 »

whynotmaybe wrote: post #43
hatchnyc wrote: post #22

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

I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted". Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.

> Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.

I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private company you don't really have the option of saying "no" except with your feet.

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

#93

Post by jshmrsn »

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…

We have sprint retros and generally find them valuable. I’m curious how one would even go about incorporating music and movies into a sprint retro? That does sound painful.

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

#94

Post by wirthjason »

The article talks about big tech but it’s interesting to think of big tech in a couple ways. One is “Big Tech” (capital B and T) the other would be “big tech”. The destination is that the first is mainly the FANGs of the world that easily come to mind.

The second is other large companies that deploy huge amounts of tech but have different business models. Banks are an example. Apparently JP Morgan Chase’s annual tech budget is $12 billion!!! That’s a lot of money.

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

#95

Post by shadowgovt »

deepGem wrote: post #57

So the key takeaway here is that the Plan, build(iterate), ship cycle works very well. Most successful teams stick to this. What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say. So how do you fit in this new requirement ? You are already in the middle of a feature built on day 3 or 4. Devs are working…

Version control will let you set the work aside and resume it later. You might have to burn a few cycles merging your old code up to date, but it won't be lost.

I haven't really seen a better option. Urgent work is disruptive to schedule by definition.

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

#96

Post by brightball »

speed_spread wrote: post #47
brightball wrote: post #12

Everything described in there is mirrored in SAFe fwiw, even though their survey said it was mostly used in large non-tech companies. Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and cont…

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 and when you can have it done.

Even after that, you’re only allowed to plan 2/3 of your time and the final 2 weeks of the PI are unplanned specifically to build in more buffer for you. If you do finish when you originally planned to, that 2 weeks is equivalent to 20% time where you can work on anything you want for the company, training for yourself, etc. It’s a built in reward for being on schedule.

And then as a group you discuss all of the risks that could prevent one of these items from being hit schedule wise. So if something comes up that keeps a team from being able to finish something, everybody was aware of it in the beginning and had the opportunity to try to help address it.

There’s no waterfall to it unless you consider anything that acknowledges dependencies to be waterfall.

Planning for 8-12 weeks at a time is the ideal window that lets you set expectations, coordinate multiple teams and avoid derailment without the idea that you can plan forever into the future. The farther you get from now, the more any plans become pure imagination which is why year long waterfall plans are a joke. It’s entirely possible to plan 8-12 weeks at a time. Especially when the point of the system is to acknowledge that estimates are at best a guess.

There’s a balance between setting expectations that business people can plan around and working in a box without communicating anything other than “I’ll let you know when it’s ready.” SAFe strikes that balance better than anything I’ve seen.

But everything will always boil down to leadership embracing it. Until leadership can acknowledge the fundamental lack of accuracy from software estimates, you’re screwed no matter what the methodology.

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

#97

Post by pc86 »

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…

Why is it that every criticism of agile/scrum/safe is met with "well you just weren't really doing it?"

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

#98

Post by lordnacho »

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

> instead of trying to "processify" A cause of this problem is when people are worried about what happens when they say "erm, I don't know how to do this cleanly" and so they want the "how" to be defined far far in advance. Solving this requires a mix of A. Identifying those activities that will genuinely make people's lives easier if they have a process and designing those processes to be meaningful and low-burden.…

Also goes hand in hand with Goodhart's Law.

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

#99

Post by lloydatkinson »

hatchnyc wrote: post #22

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

I wish I could upvote this twice. So true, it's very frustrating.

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

#100

Post by [deleted] »

elzbardico wrote: post #68
brightball wrote: post #12

Everything described in there is mirrored in SAFe fwiw, even though their survey said it was mostly used in large non-tech companies. Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and cont…

> I really wish more people knew about SAFe. Yeah, I feel the same about nicotine, lead, mercury, dioxin and asbestos.

[deleted]
Post reply on HN