The Agile Manifesto and the Twelve Principles of Agile Software are the most influential writings on the software development process. Twenty years later, the manifesto continues to influence. Phrases like “Individuals and interactions over processes and tools” and “Responding to change over following a plan” have yet to lose any relevancy. Principles like “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” still have a lot to teach modern software companies.

The Agile Manifesto and the supporting Twelve Principles are foundational readings for anyone involved in software delivery. However, one of the principles is not just misleading, but fundamentally incorrect. Agile principle #6 states “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” The emphasis on face-to-face communication is one defect with this principle, but there is a much deeper problem as well.

Face-to-face communication is outdated

In the time since Covid-19 appeared, it has become clear that engineers can be just as effective when working in a home office compared to on a tech campus. A good face-to-face communicator has no problem transitioning their in-person communication to remote-friendly mediums like instant messaging or video chat. During the two and a half years I worked as a software developer at Google, some internal metrics pointed to an overall increase in productivity during mandatory work-from-home.

Face-to-face communication is not the best way to communicate within a development team. It is a good way, but the forced experiment in remote work has shown that other synchronous communication methods are just as good.  However, there is a much better way to communicate to and within a software development team.  That method is asynchronous and is already being used by all major technology companies.

Document-driven communication is King

At Amazon and Google, my teams communicated technical designs through design documents. At Google, this was taken a step further and work was communicated to developers using product requirement documents, and work was launched using launch checklist documents. Sometimes I would write design proposals or alignment documents for smaller decisions.

Human-language documents are the best method of communication to and within a development team.  Here are five reasons why:

1. Documents are less ambiguous and less personal than spoken words. Everyone sees the same words on a page, but the words coming out of a mouth may not be the same words heard by a nearby ear. Clarity of communication is the expectation. It is easier to tell someone that their document is not clear enough than it is to tell someone that their verbal communication is not clear enough.
2. Documents do not require everyone to be in a room in order to have their voice heard. People can leave comments on documents at any time and responses can come at any time. This can slow down achieving consensus on the topic (I don’t think it has to), but it also reduces meetings, incurs fewer interruptions, and solicits more thoughtful feedback from more members of the organization.
3. Once documents have served their communication purpose, they can provide long-term value as documentation. Communication-focused documents provide documentation about decisions and considerations at a specific moment in time.
4. Templates unlock the true power of document-driven communication. Templates provide a starting point for documents. This speeds up the document writing process, but also allows organizational learning to be captured. If a design flaw causes a production outage, the design document template can be updated to make sure that the same design flaw does not reoccur.
5. Documents are searchable. When documents are stored in a shared, accessible and searchable location, their knowledge becomes accessible to everyone in the organization.

Document-based communication is not perfect.  Writing requires practice and skill.  It is not always easy to keep documents focused on a single topic and to know when documents should be split.  Nevertheless, the benefits are so strong and the adoption of document-based communication is so prevalent that we can ignore it no longer.

So what should we do with Agile Principle #6?

It is valuable for the Agile Principles to provide guidance on effective communication for software development. The principles and manifesto provide so much direction on proper interactions between members of the development process that omitting guidance on communication methods would be strange. Principle #6 should not be eliminated, it just needs an update.

Therefore I propose Agile Principles #6 be amended to: “The most efficient and effective method of conveying information to and within a development team is through written documents.”