We have misInterpreted agile principle #6 and here's why
by Julie Foster, December 2022
Agile principle six states " The most efficient and effective method of conveying information to and within a development team is face-to-face conversation".
Many believe to fulfill this principle, development teams must physically be in the same room talking face-to-face.
This interpretation has caused companies to spend millions forcing the relocation of employees to the same office or restructuring their HR reporting lines to ensure co-location.
But did the founders of the principles mean developers had to be physically in the same room for the frameworks under Agile to work? Could it be possible that this principle has been grossly misinterpreted over the years?
To better interpret the intent of this principle, we must first understand the environment of development and projects during the years when it was written.
Get acquainted with Agile
Many of us have been somewhat exposed to "Agile" Often Agile and Scrum are used interchangeably and the essence of Agile has been reduced in our minds as a daily stand-up and tons of meetings called ceremonies. Agile and Scrum are not interchangeable and the spirit of agility goes far beyond the Scrum framework.
The Agile Manifesto and principles were born out of the desire to find a better way to deliver value to customers and a desire to be freed from the heavy-weight process. There had to be a method that was more collaborative and inspired innovation while keeping the customer's needs at the center by adapting to those needs and allowing for flexibility.
I am assuming that if you are reading this, you know something about Agile, but in case you do not, take a moment to get acquainted by reading the Manifesto, Principles, and history.
Software Engineering in the late 90s and early 2000s
Why has principle six been interpreted as meaning co-located? Do engineering and product teams really have to be in the same room to be successful? First, let's take a look at the landscape of projects in the late 90s and early 2000s for better context.
In today's world, technology has advanced so much so, that it's common to work with people from across the globe. Many people work remotely from their homes and we have tools that enable remote collaboration such as Miro, Zoom, Webex, Teams, and Slack, but in the era when the manifesto was written, the folks you worked with were already in the same office and working together. Working remotely was almost unheard of and all that great technology we use today to enable remote collaboration did not exist.
So if technology teams and project teams were already co-located then what did the founders mean when they said: "face-to-face conversation is best"?
To better understand why this principle was important enough to include with the others, let's look at how information was conveyed to developers during that era.
Traditional project management and the transfer of information
So how was information being conveyed in the late 90s and early 2000s? It might surprise you to learn that it's not so different than it is today. If you are not in a true agile organization, then what I am about to lay out will mirror your daily work life.
The flow of requirements from inception to development hasn't changed much in the past 50 years. Even organizations that claim they are "Agile" still rely heavily on thoroughly documented business requirements.
The difference now is that instead of handing over a 25-page document many are breaking down a project plan into "user story" work item types in a digital Kanban board, like Azure or Jira. (Which isn't agile at all)
After a project is approved, a charter written, and the scope defined, the business analyst embarks on a TON of meetings with business stakeholders to document every single detail.
I don't know if you have ever written a requirements document, but I have, and I can attest it is laborious! Many, many revisions.
The customer must know exactly what they want down to the smallest detail.
Once written, the document is "walked". Requirements walk is where we gather all the stakeholders and read every line of the document and note any changes or revisions from the group.
After the walk, verbal approval is typically asked for then the document is sent out for an official sign-off. Rarely do all stakeholders provide approval at the first ask, but eventually, it is given.
Once that sign-off is obtained, then that requirements document becomes the holy grail. Absolutely no changes are allowed.
If changes are requested it becomes a "change in requirements" which causes a change request, which must go through an approval process, requirements are then updated and walked and yet another sign-off is requested.
After the sign-off, the requirements are handed over to the design. After the design is completed (which also requires a walk and official sign-off), the document transfers to developers.
Developers are expected to read the entire document and use it as an instruction manual, being careful to only code according to what is laid out. Each developer codes "their piece" and worries about integrating code later.
If there are questions, they go back to the BA who goes back to the stakeholders which lead to a meeting to discuss, which often leads to an update or change request.
The answer is then relayed back to the developer noting the page number and section for clarification.
Once all development is completed, the document is handed over to testers. They comb through the document and write test cases. Bugs are raised if they notice anything at all that varies from the written word. After testing, the product went to User Acceptance Testing, which is the first time anyone from the business saw the finished product.
UAT often raised bugs or asked for changes because the system doesn't behave the way they expected, though the requirements were technically met.
Does this sound like your organization? It probably does. This was also the process back in the 90s and it is what caused principle 6 to be included with the other 11 principles.
So, what is wrong with requirements documents?
The fundamental flaw is the premise that we assume the customer knows exactly what they want, in specific details, at the beginning of a project.
In complex environments, such as technology, customers often don't know all of the details of what they want, they just have an idea of their needs. Even if they know what they want, they often have difficulty expressing in detail those wants.
The other issue is the length of time between when the requirements were written and approved until UAT.
It's not uncommon to not see a finished product for 1-2 years AFTER the requirements were approved.
Business and customer needs often change within that length of time. Stakeholders may have forgotten why they made something a requirement and 2 years later when they see it in action, for the first time, they are left unsatisfied.
In the mid-2000s, I worked on a large project that involved a customer-facing web application that was powered by 29 different legacy systems. This means we had 29 different stakeholders across the company.
Trying to get 29 stakeholders to express every detail of what they wanted plus agree was nearly impossible. I spent almost a year just documenting over 100 pages! Do we honestly believe that developers are going to read a requirements document that is 100 pages? A lot of developers skim the document for business rules and use the illustrated design to code against.
The app included a form page that the customer had to fill out to register for an account. One of the requirements stated that if a user inputs something that violated the field rules, an error message <insert exact verbiage> should be displayed at the top of the page in red while highlighting the violated field with a red border.
The developers objected to this behavior stating it was better to put in logic to prevent the error rather than allowing the user to type in the field and then tell them they can't. Unfortunately, we were not allowed to make that change because it violated the approved requirements. We could consider it as an enhancement at a later date if the change is approved and budgeted.
When it reached UAT, the stakeholders didn't like it but it was in the requirements, so they accepted it. However, when it reached the user, they complained. They couldn't understand why we allowed them to attempt to do something and then tell them they did it wrong. Error messages produce a negative response in the minds of users and too many errors will cause a user to abandon the process.
Imagine building a house and laying out everything you want down to the smallest detail but not seeing the house until it is completely done. You walk into the house and it doesn't match up to what you had in your mind. It's too late to adjust because the house is built and finished.
Builders don't work that way. Typically a builder will bring the homeowner to the site frequently to review and suggest changes. When framing goes up, they bring in the customer. When the walls go up, they bring in the customer. When the floors come in, they bring in the customer to view the material BEFORE it goes down. Why? Because it's more expensive to tear it up and redo it than it is to validate this is what they really want and change it before it is installed.
The old game of telephone
Remember playing the game telephone in elementary school? It may have been called something else in your school, but many of you have surely played it.
The game starts with the children sitting in a circle. The teacher whispers a short phrase to the first person. That person then whispers to the second person and so on. In the end, the last person says the phrase aloud and it usually changed by the time it reached the last person.
The teaching moment is to illustrate how information is relayed, received, and relayed again. With each relay, words are either added or removed because each individual interprets it slightly differently. Teachers use this as a way to teach going to the source.
When we read something the interpretation is influenced by our own experiences and base-level understanding.
Each person reasons the underlying meaning within themselves and could act differently on the information, though they both read the exact same thing. There's no one to ask questions to for clarity, so we have to rely on what we know to interpret it.
If we are reading something we are not familiar with, we often relate it to something we already know as a means to understand it.
The above is a perfect analogy of what happens daily in our projects today. What the customer explained and how that was interpreted throughout the process are vastly different. Even the explanation the customer gave vs. what they needed doesn't align.
This is also what the Agile founders experienced way back in the late 90s.
Why Face-to-Face matters
A face-to-face conversation is more valuable than written communication for several reasons:
Enhances creditability and trust.
Builds relationships
Allows for feedback
Establishes trust
Allows for easier persuasion
Promotes active participation and collaboration
Better conflict resolution
Hear tones of voice
Provide the opportunity for clarity
Allows us to read nonverbal cues such as facial expressions and body language
Promotes innovation and transparency
Participants are hearing the information first-hand
Unambiguous
Imagine if the project manager, business analyst, designer, developers, and testers were in a room together to hear first-hand what the customer wanted before building the swing. (aka a cross-functional team)
By being together and hearing it first-hand, they have the opportunity to ask questions for clarity. During the collaboration session, someone goes to the whiteboard to sketch ideas and the customer provides real-time feedback.
After the session, they work together for a proof of concept that is done in a few weeks and present it back to the customer for more feedback. They make adjustments and show them to the customer again. The result is a swing that meets the customer's needs and since we kept the feedback loop shortened, the customer is satisfied with the final outcome.
This is the very essence of Agile.
Could it be the emphasis on the conversation over the written expression of requirements is the key rather than physically being colocated?
The conversation is the key, not the written requirements
If we consider that in 1999 or 2000 remote working was not prevalent, technology did not enable video calls and most teams were already co-located then it leads to the conclusion that Principle 6 was not referring to co-location but rather how customer needs were expressed and relayed to others.
Customer needs were expressed in very detailed written requirements that were passed off to each work function as needed. There wasn't a conversation between business and engineering. Rather, the conversation happened between the business analyst and stakeholders and then a document was produced.
The founders were saying though documentation is needed it's not all that was needed. We cannot replace conversation, collaboration, and feedback with a document.
This is why they specifically used the phrase "face-to-face CONVERSATION"
Conversation is the most efficient and effective method of conveying information to and within a development team.
We must place more value on collaboration and conversation than on written documentation. When the business area collaborates with engineering (front-end and back-end) and QA the discovery and understanding are unmatched.
It's through this conversation that we can understand what problem we are trying to solve and why and then allow the engineering teams to figure out "the how". They are the experts. They do not need an instruction manual, they need understanding.
The landscape of the corporate world has evolved and changed since the late 90s. We have more folks than ever working remotely and the teams we work with are spread across the globe.
We are able to come together using Webex, Slack, Teams, and Zoom.
Video calls allow us to see each other face-to-face, to see body language and facial expressions. We can easily access collaboration tools to whiteboard and brainstorm. All of the things we could also do if we were all physically in the same room. We no longer have to be in the same physical office to be innovative and collaborate.
The founders wrote this:
"In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers (you can’t use the word ‘shit’ in a professional paper) out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats— at least those that are happy pushing process for process’ sake versus trying to do the best for the "customer" and deliver something timely and tangible and "as promised"—because they run out of places to hide."
"We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan but recognize the limits of planning in a turbulent environment." -Agilemanifesto.org/history
When we think of Principle 6 we must understand the founders specifically used the term "face-to-face" to emphasize the importance of hearing and collaborating with firsthand information that comes directly from the requestor instead of through a large book of written requirements. Face-to-face had little to do with co-location. Remember the first Agile value is "Individuals and interactions OVER processes and tools".