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

Speaking as someone who has been at Google for about 10 years, I would caution against trying to paint "developers at Google" using broad strokes. Google is a multifaceted megacorporation housing a plethora software project categories. Through the years I've been deeply involved in a wide spectrum of them, ranging from "disconnect for 6 solid months and deliver a leapfrog for the masses" to "form an umbilical cord with a handful of enterprise customers." The techniques necessary to drive results in each case vary in accordance with the nature of the problem. This is where broad perspective and good judgement come into play, and dogmatic adherence to -- or dogmatic rejection of -- any particular development process presents a risk.

"leapfrog for the masses"

Is this how googlers refer to results of their work and people respectively?

>I would caution against trying to paint "developers at Google" using broad strokes.

I consider it nonsense because it becomes dogma at each organization. The problem with that is that they each have their own way of being “agile” and questioning the status quo is futile at best to politically charged at worst.

Secondly, well meaning management often thinks that the reason they are having trouble delivering on time is because agile needs to be implemented. If the developers and business analysts don’t have deep understanding of the problem set then the project is at risk. All the agile in the world won’t fix that.

Hiring developers is not easy, and finding those that can deliver is also tough. Agile doesn’t solve that.

That said I do prefer an agile like approach to dev ops because it usually encourages teams to communicate and break work down into smaller pieces. When that happens system wide issues come to light much quicker than they would in a waterfall style delivery.

As it relates to the quora question, I suspect that the person that asked the question is pretty new to development. Google is huge, there is probably a million different styles of dev ops happening there. Ok that was hyperbole, but steelframes comment is exactly right. Google isn’t a monolith and googlers aren’t all the same.

> 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 the customer.

At Yahoo, I designed and built a large project. This took about six months to deliver. At the time, the company was doing quarterly reviews that I think Marissa had imported from Google. Anyway, my manager had rated me as "meets expectations" for a few quarters because this project and the one I had previously worked on weren't visible to "customers" till they were delivered, so he didn't have any evidence to justify a higher rating against other managers' team members.

Little did my manager know that a few quarters of "meets expectations" had caused HR to drop me into the bottom 5% of the company and so I received a letter from HR that I was at risk of being terminated.

So I deliver the project and now it's visible and everyone loves it and I get an "exceeds expectations" rating and then a promotion and a raise.

From being warned I'd be terminated to a promotion in less than six months, with no change in my work, but simply it becoming visible. Whee big company fun.