
Why do developers at Google consider Agile development to be nonsense? (2016) - rurban
https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?share=1
======
js2
> 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.

~~~
gordaco
> 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.

This is disturbing and, I think, a twisted form of grade inflation, mixed with
the usual suitspeak where words don't necessarily mean what they mean. If an
employee is as good as you think they should be, why would you put it at risk
of termination?

For the record, I also work in a big company with long product cycles, meaning
that the product I'm working on started more than one year ago, and the first
public release is planned for next December, so I feel your pain. Luckily our
process is a bit more sane and our manager follows our work closely, so I'm
getting good ratings (but I wonder if the grade inflation will continue in
such a way that "exceeds expectations" now means "subpar employee"...).

~~~
MAGZine
This is 100% caused by stack ranking, and the problem you identify is a very
real one. Chopping off the bottom 5% of employees works if you have a LOT of
dead weight, but realistically you can't really do it continuously or you
start removing legitimate talent and, just as worse, fostering a toxic
community that values playing politics over delivering value.

~~~
taftster
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 ranking as a significant contributing factor.

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

~~~
lonelappde
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.

~~~
Ididntdothis
Productivity is hard to measure. Insurance cost is easy to measure.

------
steelframe
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.

~~~
Mangalor
> "disconnect for 6 solid months and deliver a leapfrog for the masses"

What a luxury that must've been...

~~~
wolco
No it was g+

~~~
utopian3
Or one of the twelve messaging apps that got ignored by the masses because no
one longer trusts their products

~~~
mav3rick
Right. Everyone is using duck duck go , Proton mail and vimeo outside of HN.

~~~
ilikehurdles
Allo me on Google Messenger. Or was it Android Messenger? Anyway, my Duo
handle is xxHangoutsDudexx. We start a Google Talk session later.

~~~
mav3rick
Have fun using signal with your two friends.

~~~
utopian3
You missed the point by two miles. I still use Hangouts, but they’ve
introduced 12 other apps in the last 10 years that do the exact same thing.
All while making Hangouts / google chat / gTalk (whatever it was originally
called in Labs) worse.

~~~
mav3rick
Google is good at a lot of things. Messaging strategy is not one of them. HN
just hates Google doing well in anything so the expected harping on messaging.

~~~
utopian3
Thank you for agreeing with me.

~~~
mav3rick
Big companies have many blind spots. There is nothing new here.

------
hinkley
The hardest part of working with really smart people is that they can
rationalize pretty much anything. Worse still, if they have been on the
project for years and you’re the new guy, you’re working from a deficit of
knowledge and they’ve had plenty of time to cook up a “coherent but wrong”
model of the universe. The only thing that saves a group like that is
humility. Trying to see the system through the eyes of the new person helps
loads. I call people out for complaining about “having to” train a new guy.
It’s “getting to”, man. Take advantage of the opportunity.

The first time I worked with a stable group where everyone was a smart as me,
even the old new guy with a massive inferiority complex who managed to sneak
one really profound comment into every meeting, there was a lack of humility
on everybody’s part and things did not go well. Planning meetings were
exhausting because you could get them to bash their own old work but couldn’t
get them to admit to needing to change process at all. I should have quit, but
I had a string of experiences with persistence paying off and I had not been
beaten yet. That was the first time, and my current employer the second (I
should probably quit here, too).

Cognitive dissonance is at its absolute worst in the head of a scary-smart
person.

~~~
ellius
You probably know this, but a lot of studies back you up. Being smarter
doesn't necessarily make you more likely to be right, but it makes you a hell
of a lot better at rationalizing your position and persuading others. Also,
that comment about the "old guy with an inferiority complex who sneaks one
really profound comment in every meeting" really hit home. We have that guy on
my team too. You have to wonder what's going on when those guys are sitting in
the corner and us blustery people are doing all of the talking.

~~~
jammygit
> Being smarter doesn't necessarily make you more likely to be right (...)

> (...), but it makes you a hell of a lot better at rationalizing your
> position and persuading others.

My reading has said the opposite: smart people are far more likely to be
right, but it does no good because the important thing is to be able to
communicate

~~~
ellius
So I included that "necessarily" on purpose. In general smarter people will
solve problems more correctly. But there is also a whole class of problems
where being smart is actually a detriment. Here is a good read on this topic:
[https://www.newyorker.com/tech/frontal-cortex/why-smart-
peop...](https://www.newyorker.com/tech/frontal-cortex/why-smart-people-are-
stupid)

------
streetcat1
I personally think that it is all matter of risk. The risk of contract work
(which is what the agile manifesto writers were facing most of their careers
[they are all consultants), is building something that the customer do not
want or did not intend do. The actual tech risk is very low (e.g. ruby on
rails on postgres) since most of them use mature technology. In this case the
agile manifesto make sense - I.e. we can build something really fast and
literally ask the customer if this is what he wants every two weeks.

When you building hard tech products (e.g. borg or tensorflow), the actual
risk is technology and competition, and since this is new technology, there
are not that many customers. In this case the risk is in the architecture
(i.e. it would be hard to change the core architecture) and in the technology,
since you do not know what kind of application will be build on top of this
new technology. In addition, you face general competition risk, since the
market can usually absorb only one dominant architecture.

So in this case, you invest much more time in design and careful construction.

~~~
hinkley
Even without mature technology, you want to shake down the new tech early to
find out if it’s going to crumble around your shoulders at the worst possible
moment.

While Agile is not perfect for this kind of work, it does have a lot of
facility in this area.

Now if you could just get any two people to agree on what constitutes the last
responsible moment...

And with new tech you often have to do it first or do it better. Oddly I find
Agile seems to work better for “do it better” because if it’s easier for you
to add features than your competitor, they will probably get burned out before
you do. If you can survive that long you start to pull ahead.

~~~
streetcat1
So, just from observation, when developing new tech, there is always LAST to
market advantage. MS was LAST to market. Google was LAST to market. Kubernetes
was LAST to market. Apple was LAST to market (After MS and Palm).

I think that Agile is good after the market is captured. But when developing
the core tech (usually with no customers beside product managers and based on
research), it might be too constraining.

~~~
hinkley
I’ve observed the same thing. I’ve also observed that the dogma in the startup
world is exactly opposite. Everything is about version 1 and there is nothing
left in the tank for version 2.

The whole MVP thing is more about selling demoware to investors. It just
sounds like it’s being supportive and it gets them what they want. They don’t
give one shit about what happens 18 months from now. That’s somebody else’s
problem. There’s always someone with a higher pain tolerance they can hire
(note: pain tolerance is negatively correlated with capacity to anticipate
problems before they become emergencies). And there’s always advertising or
mergers to mask the real problems.

------
kd5bjo
There 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.

~~~
bamboozled
This is mostly what I see happen too, "Agile" is used an excuse to introduce
some type of bureaucratic process to fix what is actually pathological
cultural / leadership issues.

~~~
logicchains
s/fix/try and fail to fix.

~~~
bamboozled
Yup, thanks for that, this is what I meant.

------
crazygringo
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
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.

~~~
pfooti
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.

~~~
insertnickname
Quarterly goals are not necessarily anti-agile. Extreme Programming has both a
weekly and a quarterly cycle.

------
Jtsummers
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.

~~~
jogjayr
> This article makes a common mistake: Scrum and Agile are not synonymous

It does not. It merely acknowledges that Scrum is the most popular and widely
practiced incarnation of Agile and is what most developers are familiar with.

From the article: "The simple high level Agile Manifesto is something I think
is close to the way Google engineers think about software development...Google
development style exemplifies the type of individual empowerment talked about
in the principles."

And: "While the high level Agile Manifesto is flexible enough to work with
these principles, these are very different than the short-iteration low
documentation Agile/Scrum process which has become synonymous with the word
Agile."

------
mmcnl
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.

~~~
theworld572
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.
Then spend the next two weeks implementing that plan. Software development
almost never works out so neatly.

What really happens is that you have a set of requirements and an idea of how
you are going to implement the feature. You start working on it, maybe you
discover that there is a whole area of code that needs updating in order to
allow for your feature to be implemented. This adds on another week of work
required.

In a common-sense based development team, what usually happens is the
developer has a quick work with the project manager and maybe other devs who
need to be involved and says "Hey, I've found out that we need another week to
complete this feature because X needs refactoring, do you still want me to
continue with this?" then the PM either says "Yes this feature is important,
even if it will take another week" or "No, the feature is not important enough
to be worth spending another week on". Its really not rocket science.

In SCRUM what usually happens is the SCRUM master will tell you that the rules
say that we have already committed to a set amount of work this sprint and
that extra week of work falls outside the scope so we should create another
card for the extra work and consider this card blocked.

The whole idea of having a rule for what to do in that situation just seems
absolutely crazy. Just do whatever makes sense! Its really not that difficult.

~~~
taneq
> What really happens is that you have a set of requirements and an idea of
> how you are going to implement the feature.

The thing is, your story cards or whatever are meant to be a live document.
You have the big meeting, the next day you realise that what you came up with
doesn't work, you grab a coffee with your stakeholder and talk it through,
come up with a new plan, and you change the card you're working on. Probably
check with the tech lead first, but it's that flexible.

> In SCRUM what usually happens is the SCRUM master will tell you that the
> rules say [...]

This SCRUM thing sounds evil.

> Just do whatever makes sense! Its really not that difficult.

This is probably the best advice ever for any development team. Just do the
thing!

~~~
Tharkun
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...

~~~
theworld572
That sounds like typical scrum-enthusiast double-speak to me! :D

[https://www.scrum.org/resources/what-is-
scrum](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 cannot say both that SCRUM is not authoritative and lets you do what you
want, and then also say "you're not doing scrum correctly".

~~~
empath75
All of the rules say the team is allowed to change anything that doesn’t work
for them. Scrum is a set of suggestions for organizing a team, it’s not Moses
coming down with tablets from on high.

------
gilgoomesh
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 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.

~~~
Retric
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.

~~~
collyw
>It turns out that most projects can be broken down into absolutely tiny
pieces, and that is generally a good idea.

Generally I agree, but I have noticed in doing things like that, no one ever
seems to bother about refactoring, or tidying things up at a higher level.

Our designer complained about the CSS organization and spend a couple of days
tidying it up. I have a feeling that breaking of tasks into small pieces takes
away focus from more long term commitment to code organization and
architectural patterns.

------
S_A_P
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.

~~~
ChrisSD
> questioning the status quo is futile at best to politically charged at
> worst.

Which is antithetical to the agile manifesto. The whole point of agile was to
question the current methods and be _agile_ enough to change them as needed.

------
dbattaglia
The most toxic example of Agile/Scrum I've come across so far has been in a
company that was non-technical at its core but wanted badly to pivot to a SaaS
business model. The type of company that 50% of the employees have the word
"manager" in their title yet manage no one (Digital Project Manager, Technical
Project Manager, Product Manager, etc). I think its just in a lot of companies
culture that if they can instill some process, any process really, then the
results will follow. And software engineers complaining about the demoralizing
effects of being micro-managed by junior coworkers who never wrote a line of
code in their life are just typical spoiled tech workers. Other companies I've
worked for that used Agile methodology were not all that much better, just
somewhat less absurd. I'm glad I've gotten out of that world, its left such a
bad taste in my mouth I don't know if I can even look at Agile objectively
anymore.

~~~
jrochkind1
Both my best AND worse experiences with process have been 'agile'. (Although
the best was NOT "Scrum").

And not just because all of my experiences have been agile (they have not
been).

For agile to work well, you need a competent team and manager, AND be embedded
in an organization (ie, who determines appraisal of your manager/team) which
truly is concerned with prioritizing value to business/customer over, say,
"looking good to other managers", or "trying futilely to predict what the
software will look like a year from now, because it makes me feel in control"
or "weird power struggles with other parts of the organization". Everyone (or
at least the majority of those with the power to make you miserable or break
your career) has to be really at least _trying_ to work together to maximize
business/customer value.

If you have that, is your experience (and your software) going to be good
whether you use agile or not? Probably. But agile is a really useful and
effective mindset for making your software product _and_ your experience
(stress-levels for instance) even better. It works, in my experience.

If you don't have that, is your experience (and your software) going to be
terrible using agile or not, in proportion to how much you don't have it?
Sure. And agile and especially scrum can probably make it even worse.

------
m0zg
Nobody can explain it better than Yegge: [https://steve-
yegge.blogspot.com/2006/10/egomania-itself.htm...](https://steve-
yegge.blogspot.com/2006/10/egomania-itself.html)

Worth a read or two if you want to be cured of the Agile affliction.

------
jandrewrogers
Agile as implemented at almost all companies fails to account for the
possibility of software with simple observable interfaces requiring extremely
complex and intrinsically non-modular internal design. Most high-end platform
infrastructure work looks like this if you are doing it correctly. As a
consequence, it becomes difficult-to-impossible to do any kind of hardcore
platform software engineering work in most organizations because their model
for what successful agile software development should look like doesn't allow
for it. There is no appetite for software development where there will be no
visible progress for many months and demonstrable functionality is extremely
backloaded.

A related issue is software that cannot be meaningfully prototyped because any
design that is reflective of the desired product has the same order of effort
as the actual product, for many of the same reasons.

There are certain kinds of high-value software that cannot be built inside
most tech companies now because it pattern matches so poorly to the way people
think "agile" software development should look like.

------
anonygler
At Google, there are too many complex systems and too many team dependencies
to break tasks down into granular chunks, or to shoot from the hip in a pair
programming session.

Google runs on design docs. You define the problem, dependencies, risks, end
state, etc, in a 20-page doc, and then you drive its development for 1-2
quarters. Google doesn’t do extreme programming, we do extreme ownership.

I really prefer it to the time I spent working with Pivotal or Carbon5. They
were great, but imo not a sustainable process for mature products. Agile is
good for driving a new, greenfield MVP... and that’s about it.

~~~
hinkley
There’s a lot of power in refactoring, but I’ll allow that some of it is
counterintuitive. Anything counterintuitive requires state of mind and
experience to line up and that’s quite hit or miss.

When that awful Design Patterns book was off the hype train but the new devs
had heard about it and asked if they should read it, I would tell them No,
read Refactoring twice instead, because it tells you why and when to use this
stuff, which is much more valuable. Like feature work, if you know why you are
doing something you can often reason out the gaps in the “what” on your own.

We sort of take a bunch of XP processes as a given and forget that this was
Agile for most people at the time of the manifesto. Scrum pretends it’s
separate but is essentially useless without half of XP.

~~~
anonygler
Google does refactoring, but you’re expected to sell the idea, plan its roll
out, and measure its impact... and then bring the codebase into a consistent
state. I would rather things be consistently “wrong” than inconsistently
right.

You can assign work to teams to complete, but you must drive the effort and
gain buy in. Otherwise it’s not actually worth refactoring.

------
erikpukinskis
I don't want to get into the specifics of what makes Scrum good or bad. But
one thing I have noticed working in software is that 99% of people who talk
about Scrum actually have not spent any real time learning it. Not the product
people, not the managers, and not the engineers.

Anyway, I don't want to get into the weeds, but if anyone is interested I just
posted a gist of all my notes I took while reading every Scrum document I
could find a few months ago:
[https://gist.github.com/erikpukinskis/a8a61b8fbd19f8063737f7...](https://gist.github.com/erikpukinskis/a8a61b8fbd19f8063737f7d7199dc2b1)

There's a lot to it, as a software engineer, learning more about it was
actually pretty exciting for me because there are some good ideas in there for
some of the standard headaches I see over and over in software companies.

------
insensible
> From tax-accounting software to computer games, some software is not suited
> to give to end customers when partially finished.

The original Extreme Programming project at Chrysler was a payroll system, so
many strategies for handling things like this have been thoroughly discussed
in literature and forums in that community.

------
abalone
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/...](https://blogs.msdn.microsoft.com/david_gristwood/2004/06/24/21-rules-
of-thumb-how-microsoft-develops-its-software/)

------
gumby
Agile was specifically designed for consulting teams /projects. Outside that
its applicability drops.

Different tools for different tasks. Neither a screwdriver nor a hammer is
nonsensical, though using either in the wrong application is.

------
curtis
If your software development organization can't ship software without an agile
process, then it's unlikely that it can ship software with an agile process
either.

I'm not saying that agile processes are inferior or even no better than other
software development processes. I'm just saying that there is some level of
fundamental capability that a software organization must have before the
process is even going to matter.

------
CivBase
> much of the work is not even visible to “customers”, so there is no way to
> write customer visible stories about it

If your work doesn't have a customer, why are you even doing it?

The customer doesn't have to be the business's end user. The can be another
team or even your own team. Someone must benefit from the work or else the
work should not be done.

------
eklavya
I am sometimes amazed by our industry. Somebody comes up with a solution to a
problem and then someone else starts applying it before they even have a
problem. Sometimes people ignore what mistakes/challenges others have dealt
with and win/lose their own battles. So many times, people just say X
does/uses it as some kind of validation or guidance. Well, if your business is
also like X, great, you are learning from other people doing the same thing.
Otherwise why are you looking at X and not "your" challenges, resources and
opportunities?

There is just too much religion here :)

If you need it use it, if it works, great, if it doesn't or you don't need it,
move on. The only advice I would give to people is that there is no rule book
or the good way. Use your brain and pick up things that work.

------
tarsinge
The 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](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.

------
dehrmann
> Companies like Google write revolutionary software which has never been
> written before

Also a lot of video chat apps.

------
keanzu
"The word 'agile' has been subverted to the point where it is effectively
meaningless, and what passes for an agile community seems to be largely an
arena for consultants and vendors to hawk services and products." \- Dave
Thomas (Manifesto for Agile Software Development author)

[https://pragdave.me/blog/2014/03/04/time-to-kill-
agile.html](https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html)

------
Demigod33
> Developers should create a Google Design Document (a fairly minimal, but
> structured design doc), explaining the project, what goals it hopes to
> achieve, and explains why it can’t be done in other ways.

Does somebody have more on this? I'm never sure how to structure my design
documents, how does a Google Design Document look like, is there a template
somewhere on how to write one? This would be super helpful, please.

~~~
cameronbrown
Golang has some examples of good design documents:

[https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft.md)

------
grok2
Anybody doing Agile/Scrum know how it deals with people issues? It seems like
with these practices everyone is on a tight leash -- how does it deal with the
fact that real people have a natural ebb and flow in their concentration
levels at work or interest in work. If your are scrumming all the time, how do
you get slow periods in your work cycle so you can recharge (aka slack-off
:-))?

~~~
InvOfSmallC
I work with agile and have 20% of time for personal stuff I want to try/study.
Every week.

~~~
grok2
Integrated in your work-load officially? That still doesn't explain stuff.
Scrum-masters, please weigh in...thanks!

------
somegoogler9876
First, 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.

------
dandigangi
That top rated answer is excellent.

Agile at its core, to me as an engineering manager, is: \- People over
process/tools \- Plan-able execution and pivoting quickly in rapidly changing
environments \- Create consistent, repeatable work delivery \- Retrospection,
learning and iteration over time \- Tools (can) support the process to
multiply efficiency but do not solve the core goals and problems

Like the author of the comment said, the details of how you execute "agile" is
where things get bumpy for teams.

~~~
streetcat1
The problem with agile is that it is a greedy algorithm. It can lead you to
local optima. Usually this is not an issue if you are doing contract work,

However, if you try to create a product in a market with competition, a non
agile competitor can reach a global optima (for example Apple vs MS in mobile
phones), and than you will lose the market (and sometime your future).

------
tootie
I would speculate that this philosophy is so far removed from the customer
that it's the reason they deliver so many consumer-facing duds and exhibit a
completely schizophrenic product roadmap in so many verticals.

Amazon is relentlessly customer focussed and is now a veritable hit factory
And mostly in industries that were already seen as mature.

------
thewileyone
The worst part about Agile is that non-technical technical managers that I
worked with, convinced the non-technical business managers that using Agile
would lead to more and better innovation. And that's how they got training and
pseudo-experience to pad their resumes.

------
lkrubner
At most companies I’ve mostly seen “agile” used to justify a process that is
clearly broken. The one exception is when I worked with Mark Herschberg. He is
a talented CTO. He did Agile the right way. I wrote up his technique here:

[http://www.smashcompany.com/technology/the-right-way-to-
do-a...](http://www.smashcompany.com/technology/the-right-way-to-do-agile)

------
breck
> Simplicity - the art of maximizing the amount of work not done - is
> essential.

Interesting definition of simplicity.

------
rightisleft
a friendly reminder that your company is not google... unless you are at
google

------
lasthacker
Let's paraphrase: 1\. Don't talk to customers. 2\. Write down the design and
never change it. Make a lot of meetings. 3\. Maximize bureaucracy. 4\.
Maximally slow down the project. 5\. Don't finish anything earlier than
planned.

------
amsheehan
We don't

------
PasserBy2022
"leapfrog for the masses"

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

~~~
caconym_
Is "the masses" offensive?

~~~
malvosenior
For someone who doesn't want to be painted in broad strokes, it seems like a
very broad brush to paint non-Googlers with.

~~~
Udik
Who said that Googlers are not part of those "masses"? Surely they enjoy
products from their company as anybody else?

And then, of course, nobody said you're part of those masses anyway. Maybe
you're not. Do you enjoy Google product X as other hundreds of million do?
Then you're part of the mass that enjoys it. Otherwise you are part of the
mass that doesn't.

~~~
solidasparagus
'The masses' refers to the lower classes (look at any dictionary and how the
word has historically been used - 'opiate of the masses', 'the unwashed
masses'). It would not typically be correct to say that a Googler is part of
the lower classer. 'The masses' is definitely not the same as 'everyone'.

~~~
tom_
Another way of putting it: words have connotations as well as meanings.

People do sometimes seem to forget this! - so it's good to have a reminder.

~~~
solidasparagus
Well put

------
fareesh
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 production version and never saw the
light of day because of this very reason

~~~
anoncareer0212
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.

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

~~~
anoncareer0212
Overall picture: Google recognizes it's a large company that has an extreme
diversity of teams with idiosyncratic goals and personalities, and doesn't
prescribe _anything_

Dollars to doughnuts, there's multiple teams doing extremely prescriptive
Agile, but I've never seen one in 3 years in a 2,000 employee office.

By far the most organized team I've been on merely kept track of bugs using an
internal web app that renders bugs from the internal bug tracker as post-it
notes arranged in columns, with each column representing a bug status (ex.
assigned/started work/code in review/done).

This alone caused a ton of grumbling, meanwhile I'm sitting there gobsmacked
that Scrum and Agile aren't proper nouns that everyone has highly detailed
opinions on.

~~~
aurelianito
The team you are referring to is highly likely to be using kanban. Kanban is
the destiny of agile.

~~~
anoncareer0212
Nailed it, that's the name of the internal web app :) I always hesitate to
call it Kanban because my relative that's a university professor is obsessed
with Proper Kanban and it's nigh-unrecognizable to me beyond the post-it notes
and status

