Are Amazon and Google at odds with Agile?
Tags: architecture, agile, development
Published: 2021-07-20 15:18:50

---
title: Are Amazon and Google at odds with Agile?
published: true
description: Both Amazon and Google have a culture of creating written documentation, including specifications. Agile approaches are commonly resistant to such practices but it's obviously successful.
tags: architecture, agile, development
cover_image: https://unsplash.com/photos/ZrqrP9Xs2vI/download?force=true&w=1920
---

_Working software over comprehensive documentation_ is one of the core values of [The Agile Manifesto](https://agilemanifesto.org/). And even though this carries the caveat "...while there is value in the items on the right, we value the items on the left more..." it typically means that Agile approaches such as scrum, kanban, or XP avoid rather than emphasize documentation.

It is interesting, then, that two of our times' largest and most successful companies place written documentation at the core of their work.

Amazon is well-known for its [6-pager](https://www.cnbc.com/2018/04/23/what-jeff-bezos-learned-from-requiring-6-page-memos-at-amazon.html) approach to outlining positions, gaining consensus, and, finally, [disagreeing and committing](https://aws.amazon.com/blogs/enterprise-strategy/guts-part-three-having-backbone-disagreeing-and-committing/).

Google, on the other hand, expects that employees work together via [design docs](https://www.industrialempathy.com/posts/design-docs-at-google/). The constant collaboration on documentation promotes a deeper level of shared understanding.

Both approaches run aground of the now-traditional Agile recommendation to prefer working software instead. It wouldn't be hard to make an argument that by so blatantly ignoring such a core Agile principle, these two software behemoths are _not agile at all._

It has even led to the popular Quora question, ["Why do some developers at strong companies like Google consider Agile development to be nonsense?"](https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense)

![Jeff Bezos, founder of Amazon](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hf3n3vnugwycmoqedkrl.jpeg)

Yet, at a deeper level there is harmony between the underlying motivations here. Both companies have cited writing documentation as a way  to be _more efficient,_ which is the explicit goal of Agile. Consider the [following summary of an interview with Jeff Bezos](Jeff Bezos and the Six-Page Memo):

> Working out a careful six-page narrative memo, [Bezos] told Rose, calls for “deeper thinking” and “clarity.” When the meeting convenes, the leader distributes the memo and a thirty-minute “study hall” begins, during which the attendees read the memo and make notes. Only then does discussion begin. Bezos said that this method saves time in the long run because 1) everyone is reading it together so it will be fresh in their minds; and 2) the kinds of questions people tend to ask—ones that are often answered in the next slide or paragraph—aren’t necessary. This process of reading and discussing the memos, Bezos said, fuels the kind of inventiveness that Amazon is known for.

The questions this raises are fascinating and thought-provoking. The obvious question surrounding whether or not written documentation of this form can be considered "agile" will soon be replaced by the other usual questions:

- Is _not_ being agile really so bad?

- Are Google and Amazon perhaps successful in spite of focusing on written documentation and not because of it?

- In the age of remote work, where written documentation is often the best way to communicate, how can we reconcile the idea that we should prefer "working software" to "comprehensive documentation?"

- What does "comprehensive" even mean?

- Just because Google and Amazon do it, why should we?

I don't mean to answer any of these questions. But I think it's worth a glass of {coffee, wine, beer, tea, _________} and a think through. Whatever answer you land on, I hope your  team and company have a look at both sides of the conversation before jumping headfirst either way.