Working software over comprehensive documentation is one of the core values of The Agile Manifesto. 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 approach to outlining positions, gaining consensus, and, finally, disagreeing and committing.
Google, on the other hand, expects that employees work together via design docs. 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?"
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:
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.
Top comments (2)
This is a mis-reading of what the agile manifesto is for and the behaviours it's designed to encourage. It doesn't say "don't document anything", it just states a preference where you have to make a choice. It's better to build something and get user feedback than it is to spend months building AND thoroughly documenting something only to find that you have to change it wholesale. You should still document things, but at the right time so that you don't waste effort. Agile dev is all about de-risking and being more efficient in the work that you do so that it better aligns with what the customer actually wants. Reading it as "don't bother doing documentation" is a mistake that a lot of people seem to make, in a similar way to Agile being some sort of black cheque for the user to keep demanding changes ad-infinitum (it's not).
What you alluded to in terms of efficency is absolutely right - it's more efficient to write something down once and refer people to it than to explain the same thing to multiple people from scratch. Rather than sending out an email or chat message, always think "could this be a wiki page?" and favour doing that and sharing a link over emails/chat where the info isn't necessarily saved for future reference.
No.
Amazon's 6-pagers are business documents, not software documentation. Besides both having "document" in the name, that's about all they have in common.
A development methodology is 'agile' or not based on a holistic appraisal of the team's practices and mindset, not whether or not they have written documentation.
I recently read the book "Software Engineering at Google" and my impression is that they are minimizing documentation. It's just that the level of documentation required to keep the wheels on a code base with billions of lines of code and tens of thousands of devs working on it all around the world is a lot different than the typical system (with perhaps less than 100 KLOC and a couple of devs). Scale matters a lot!
I doubt Google cares if someone calls what they are doing agile or not but I don't think you can figure that out with the information you've given. In my estimation they just don't want to get stuck in the position where their code base is a mess, it's a nightmare to work on, good devs jump ship, and every new feature costs more than the last.