Why do developers at Google consider Agile development to be nonsense? (2016) • Hacker News Board

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#161

Post by doesitmatterwho » Sat, Aug 03, 2019, 8:34 PM UTC

paganel wrote: post #150

adrusi wrote: post #140

Earlier quoted context omitted.

Eh, the language makes a bit more sense than that. It's a bit too euphemistic for my taste, but it's reasonable. "Meets expectations" — which expectations? The expectations for the role of for the employee? If we're talking about the expectations for the employee, then obviously it makes no sense for meeting expectations to be a bad thing. But if instead we're talking about expectations for the role, it's perfectly c…

A bus driver that “meets expectations” is the perfect bus driver, I don’t want him to “continually improve” thinking that he’s the new Ayrton Senna, I don’t want to be driven around by drivers who think that they’re Formula 1 drivers. How are programmers different from bus drivers?

"How are programmers different from bus drivers?"

How does this guy have 7621 karma on HN? lol

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#162

Post by iovrthoughtthis » Sat, Aug 03, 2019, 8:46 PM UTC

Jtsummers wrote: post #14

This article makes a common mistake: Scrum and Agile are not synonymous. Given that error, the conclusion is nonsense. And besides, even Scrum doesn’t require a delivered product each sprint. Just an updated status and increment completed. If I’m building a new server and client architected system, the early sprints may be getting certain design details down. More documentation than code. Later on, I may have sprints…

Also, if you can’t get a thing done in one sprint then perhaps your sprint is too short?

The point is to adapt the process to the teams needs, not to dogmatically follow some other teams process.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#163

Post by abalone » Sat, Aug 03, 2019, 8:46 PM UTC

The main gripe I have with this analysis is it weds the short-term sprint cycle with customer exposure & feedback. It then argues that, well, we can't let customers change their minds every two weeks and Big Serious Things take 20 months to get working so this is just for like web contractors and stuff.

I don't see agile as exclusively requiring you to expose everything you do to your end-users as you make it. I get that it can accommodate that if that's what you want, but the real essence of it is about de-risking a project by breaking things down into shorter milestones.

Do you remember those Microsoft Press software management books? So good. One point was "Beware of a Guy in a Room".[1] Which is to say, don't let developers shut their door and go dark for months at a time without surfacing with something working. It can take a bit more work to adapt a big project into smaller "working" milestones and seem silly and inefficient, but in the end this helps avoid a lot of risks that can lead to deathmarches that can truly kill a project.

One way to adapt the "customer" aspect of agile is to not have an actual live customer but rather a "voice of the market" that the product manager represents. After all, you do want to empower them to course correct because the world can change over 8-20 months. This applies even to BigTable.

[1] https://blogs.msdn.microsoft.com/david_gristwood/2004/06/24/...

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#164

Post by mmcnl » Sat, Aug 03, 2019, 8:49 PM UTC

theworld572 wrote: post #48

Tharkun wrote: post #43

Earlier quoted context omitted.

> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a t…

Whats the point of SCRUM then? If all it does is to tell you "do what makes sense" why do we even need it? Thats a rhetorical question, I already know the answer is that we need it in order to keep SCRUM consultants, certifications, training etc. a profitable business. Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and…

Working is not vacation. Sticking to a process is a hygiene factor which doesn't necessarily has to be fun but it makes it possible for companies to be properly managed.

That being said, stop complaining. If you can find room to complain, you surely can find room for improvement right? It might just be me, but everywhere I've worked I've never encountered a manager who isn't open to solid ideas for improvement.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#165

Post by coldtea » Sat, Aug 03, 2019, 8:50 PM UTC

paganel wrote: post #150

adrusi wrote: post #140

Earlier quoted context omitted.

Eh, the language makes a bit more sense than that. It's a bit too euphemistic for my taste, but it's reasonable. "Meets expectations" — which expectations? The expectations for the role of for the employee? If we're talking about the expectations for the employee, then obviously it makes no sense for meeting expectations to be a bad thing. But if instead we're talking about expectations for the role, it's perfectly c…

A bus driver that “meets expectations” is the perfect bus driver, I don’t want him to “continually improve” thinking that he’s the new Ayrton Senna, I don’t want to be driven around by drivers who think that they’re Formula 1 drivers. How are programmers different from bus drivers?

>How are programmers different from bus drivers?

In that programmers are supposed to be creative, over-deliver, etc.

You'd worry if a bus driver got from A to B in half the time driving twice as fast suddenly.

But you'd be OK if a programmer you've asked to design system with features A, B, C and performance P, also delivers features D, E, F and performance 2*P without being asked!

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#166

Post by lonelappde » Sat, Aug 03, 2019, 8:50 PM UTC

Spooky23 wrote: post #139

taftster wrote: post #123

Earlier quoted context omitted.

Not only that, but chopping off the bottom 5% typically makes room for more hiring; these emptied jobs are likely to be filled with less-than-stellar candidates. It take the new hires a few years before they too are dropped down into that lower 5% rank. Stack ranking ensures that you have churn in your workforce, and not in a good way. You wonder why workers in the tech industry move around so much? Look at stack ran…

That’s by design. Keeps the workforce young and insurance cheap.

Why would companies prefer cheap insurance over productivity? If they want to pay less, they can just pay less. People would rather get paid less than get fired.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#167

Post by mmcnl » Sat, Aug 03, 2019, 8:51 PM UTC

theworld572 wrote: post #52

Tharkun wrote: post #46

Earlier quoted context omitted.

I think the OP is missing the point of scrum. The scrum master isn't supposed to tell you what the rules are. The rules are whatever the team decides they are. The scrum master is not the boss, they're supposed to be a facilitator...

That sounds like typical scrum-enthusiast double-speak to me! :D https://www.scrum.org/resources/what-is-scrum "This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together." Definitions, Rules, Roles, Artifacts etc. Sounds pretty authoritative to me. If it wasn't authoritative, how would you even know what SCRUM "really" is? You cann…

Why not try to find a perspective that will make things easier for you? You can look at any suggestion and shoot it down for reasons X, Y and Z - that's easy. Try to invest some time in finding out what works for you and focus on that.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#168

Post by mmcnl » Sat, Aug 03, 2019, 8:53 PM UTC

zamadatix wrote: post #37

mmcnl wrote: post #17

I feel like people who are opposed to agile and scrum often make out things of it that are in no way prescribed by these methodologies. For example, I see people mentioning the idea that with scrum, you should release working software every sprint. This is not the case. The idea is to deliver a _potentially_ shippable product increment - a.k.a. not building 10 bridges in parallel if there's no need for it. Some might…

The problem I've seen with agile is it's too easy to turn into "as long as we complete something that was defined as value this sprint the problem isn't what this team is doing" that many places end up having teams avoiding any large or external issues completely while reporting everything is going great. You may say it's not a methodologies fault when it's misused but I'd say it IS a methodologies fault if the feedb…

> teams avoiding any large or external issues completely while reporting everything is going great

This is what happens all the time in big companies, agile or not.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#169

Post by paganel » Sat, Aug 03, 2019, 8:57 PM UTC

coldtea wrote: post #165

paganel wrote: post #150

Earlier quoted context omitted.

A bus driver that “meets expectations” is the perfect bus driver, I don’t want him to “continually improve” thinking that he’s the new Ayrton Senna, I don’t want to be driven around by drivers who think that they’re Formula 1 drivers. How are programmers different from bus drivers?

> How are programmers different from bus drivers? In that programmers are supposed to be creative, over-deliver, etc. You'd worry if a bus driver got from A to B in half the time driving twice as fast suddenly. But you'd be OK if a programmer you've asked to design system with features A, B, C and performance P, also delivers features D, E, F and performance 2*P without being asked!

> In that programmers are supposed to be creative, over-deliver, etc.

Like I said, I don't want the programmer in charge of the software that manages my financial or health records to be creative or over-deliver, quite the contrary. I'd add personal-data to the mix, and now I've covered a huge chunk of SV companies. I think that the era of "move fast and break things" should be over by now, unfortunately relatively paltry $5 billion fines won't stop the creativeness of some companies.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#170

Post by lonelappde » Sat, Aug 03, 2019, 9:00 PM UTC

izacus wrote: post #134

js2 wrote: post #29

> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…

Huh, as much as I've heard, good luck ever getting a promotion at Google with a track record of MEs and a single EE. People with SEE regularly get their promotions denied.

That's because it's uncorrelated, not high bar. Until recently, the manager giving you EE and SEE is totally different from and actively distrusted by the promo committees.

And on top of that, the criteria are different. Working a little faster than your peers is EE, and is rewarded with raise and extra bonus, but that's different from performing in a higher level role with qualitatively different expectations.