Why do developers at Google consider Agile development to be nonsense? (2016)
1–10 of 239 posts
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#2Can 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 production version and never saw the light of day because of this very reason
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#3Can 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…
Did you read the Quora answer or are you replying to the title?
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#4Can 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, and I was thrilled to have someone else help with that.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#5This 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 believe.
But either way -- he insists "companies like Google write revolutionary software which has never been written before, and which doesn’t work until complex subcomponents are written." But putting aside the "revolutionary" hype, there's no reason subcomponents can't have agile philosophies applied.
A big part of agile is ensuring developers actually understand the requirements (consensus via point estimation), seek to define requirements where they're suddenly discovered to be vague/undefined, and have frequent check-ins to demonstrate that their software is making progress towards those requirements and raising any potential blockers early on, and not accidentally going down a rabbit hole of building the wrong thing (despite best intentions) for weeks at a time which nobody notices until too late, and the project is delayed by months.
That's just as important for a subcomponent of a subcomponent, as it is for a service dashboard. To assume agile is only for "consumer-facing" software is a deep and fundamental misunderstanding.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#6The corollary is that for everyone else working on solving business problems in non-software industries (coincidentally there is a related discussion from today https://news.ycombinator.com/item?id=20599190) the principles are still perfectly sane.
In that kind of environment it doesn't lead to short-term thinking because a long-term business vision can exist independently of how a software solution is implemented.
Edit: removed the bit about Google being an exception.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#7I 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 tangents.
Basically, developers who try to develop 10,000 lines of code on their own, without sharing it for a month, create massive risks and are an impediment to their team. Forcing regular code curation and sharing among the team makes the project stronger – that's what "short term planning" does.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#8I 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…
Doing 1 month without integration is still fine. When agile was conceived doing 6 sprints per year would have been considered agile in many fields. The goal is to be able to be as responsive as reasonably possible not simply to add thousands of mostly meaningless milestones.
It turns out that most projects can be broken down into absolutely tiny pieces, and that is generally a good idea. However, the core idea is you need to adjust the methodology to the problem at hand and not the other way.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#9There is unfortunately a large gulf between “agile” and “Agile” development these days. The former refers to development generally in line with the agile manifesto, with processes tailored to the needs of the team and the project. The latter is a buzzword used by consultants to convince management to put their favored bureaucratic method in place, usually some variant on the scrum system.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#10First, I disagree with the author's post that all software developed at Google is revolutionary low-level technical infrastructure. But that's not the only type of software development that benefits from avoiding the productivity tax that agile imposes.
There are teams at Google that look to use agile methods. E.g. I see standups, there are internal tools that track sprints, etc. I think these are mostly front end teams.
I've never worked on front end but was on a team that used scrum at a previous job. I hated it. It seems like a huge impedance mismatch for my kind of work.
I'm guessing some consultants sold management on the miraculous benefits of scrum at my previous job, they like the snakeoil they were sold and forced scrum on everyone. The amount of overhead process it brings is an enormous tax on productivity.
Some people call this "corporate scrum" to try to distinguish it from real scrum. But this feels like a No True Scotsman fallacy. Why is it so damn hard to do "real scrum" and actually get the productivity benefits it promises? I've never met any SWE in real life who has tried scrum and liked it.
At Google, the development process is not just "develop 10000 lines of code on their own" like some posts here have imagined. There is typically a design phase that gets wide buy in, and then code reviews, and extensive testing every step of the way during development. This feels far more realistic as a process.
And it is NOT some "waterfall" process which only seems to exist as a strawman for agile consultants to knock down. There is no architect who designs the code and then hands it off to code monkeys to go implement exactly as written. That's ridiculous and now how software is written anywhere as far as I can tell.
If I were to answer the question in the title myself, it's that Google has allowed engineers to build a process that works for them, and they almost never pick scrum or other agile methods.