Live data from Hacker News

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

quora.com

11–20 of 239 posts

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

#11

I think the answer badly misconstrues the purpose of "short term planning" and "continuous integration" as though these concepts preclude long proof-of-concept projects. The point of short delivery cycles is not to deliver a viable product to an external customer every two weeks. Rather it simply ensures that code remains in-sync with its intended use-case and guards against individuals going off on untracked tangent…

> I think the answer badly misconstrues the purpose of "short term planning" ...

'short term planning' appears to be your construct, not found in TFA.

Short term implies reactive / tactical -- not the planned / strategic level that TFA is talking about.

It may well be that Agile 'precludes long proof-of-concept projects', given its essence is 'better ways of developing software', which clearly hides a wealth of complexity behind the heading of user-facing software.

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

#13
post #2

Can the teams at Google experience processes where they talk to their customers, iterate, talk to customers, iterate again and move fast and break stuff - releasing at each step of the way and measuring their intended A/B/C tests? I suspect a company like that has committees and subcommittees and review processes and 100 layers of bureaucracy before anything even gets done I bet there are projects that reached a prod…

I went from waiter -> self-educated SW engineer founding own startup -> sold startup -> Google. (Been on 3 teams, all of which shipped to match HW deadlines) The only thing noteworthy about Google is _there is no process_. Hell, just last week, a coworker and I finally resolved a year-long difference of opinion when it clicked for him that there wasn't a defined system, insomuch as there was one I was defining it, an…

Can you explain that better? Basically in a nutshell they don't have worthless agile processes?

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

#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 that only establish the handshake between client and server and no real functionality. The point is taking milestones (big chunks of work) down to smaller chunks of work that can establish a clearer goal set for the near future.

And that isn’t even unique to Scrum. If you don’t establish small iterative goals it becomes difficult to measure progress. Saying, “We can’t measure success until this large number of lines of code are completed” is folly. If you have that design, you can measure your progress towards completion by creating inch-pebbles for the next few iterations. Like in my example, finalize design docs based on R&D efforts, make prototypes or simulations, create basic handshake code, then build up server and client features in tandem to ensure they make sense (maybe the design can be simplified when you realize several commands or messages are really specialized versions of a more generic one, or maybe something is more complex and requires a reexamination of the design). And yes, a lot of this is common sense to good engineers. Problem is, common sense isn’t common and you’ll get people pushing Waterfall again and again.

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

#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 even call this common sense.

Most people who are pessimistic about the agile development who I have spoken to are usually pessimistic because of poor implementations they've encountered. Any methodology is awful when misused or when hidden agendas are at play. No methodology will ever solve that.

That being said (probably onpopular opinion), I often also see engineers use agile to blame everything that is going wrong onto "management" and use it as way of avoiding responsibility. Complaining and arguing as if there are only absolutes is an immature and unproductive attitude. Calling agile "nonsense" is a prime example of that.

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

#18

I think the answer badly misconstrues the purpose of "short term planning" and "continuous integration" as though these concepts preclude long proof-of-concept projects. The point of short delivery cycles is not to deliver a viable product to an external customer every two weeks. Rather it simply ensures that code remains in-sync with its intended use-case and guards against individuals going off on untracked tangent…

also they don't seem to grasp the meaning of "customer" in the context of agile. if nobody ordered the software from you, the customer is you. so the project owner must be someone from the company. it can even be the scrum master assuming both roles

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

#19

This post feels a little disingenuous... First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity". Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believ…

> Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believe.

Honestly, it seems a bit elitist to me.

I work at a company that pioneered SOA for both technical and organizational flexibility reasons and I'd say it's worked out pretty well for us!

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

#20

This post feels a little disingenuous... First of all, it's not like most engineers at Google are working on Bigtable or Borg, with a "very simple interface and tons of hidden internal complexity". Plenty of them are working on normal consumer-facing products, the "software with a simple core and lots of customer visible features that are incrementally useful", although maybe that's not the hype people want to believ…

This is true. I'm a swe at Google. My team uses scrum methodology, and is responsible for a customer facing but thoroughly "normal" product. My work doesn't involve building heretofore unknown planet scale computational resources. It's just a normal product where I'm a full stack dev.

I'm sure there's ways we can improve our canonical agile-ness, but it's not lip service. We set quarterly goals sure, but they can change if situations change and the goals themselves are usually data-driven (based on prior quarters a/b testing and other research done by our UX team). We also have strong product and project managers, who own a lot of the scrum meta-work.

So, I guess #notallgooglers (which for context is an ironic, kind of self deprecating response here). There's tens of thousands of engineers at G. Some teams are agile, some aren't.

Post reply on HN