We have misInterpreted agile principle #6
Updated: Aug 3
by Julie Foster, December 2022
Agile Principle #6: Rethinking the True Essence of Face-to-Face Communication
Agile methodologies have revolutionized the way we approach development, emphasizing collaboration and adaptability.
Principle #6, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," - Agile Manifesto
In this exploration, we unveil a fresh perspective that transcends physical presence, making this principle more relevant than ever.
The common interpretation of this principle has led to substantial costs and relocations, mistakenly associating it solely with physical co-location.
However, delving into its origins and understanding the historical context reveals a deeper meaning.
Embracing Agile's True Spirit
Agile goes beyond buzzwords like "Scrum" and "daily stand-ups." It was born out of the need for collaborative value delivery and flexibility.
Let's reconnect with Agile's essence, acknowledging its broader spectrum and impact.
Looking back at the late 90s and early 2000s helps us grasp the essence of this principle. In an era without today's remote collaboration tools, teams were predominantly co-located. The challenge lay in effective information conveyance amidst project intricacies
Traditional project management
Comparing traditional project management practices with Agile methodologies offers insights into why Principle #6 was introduced.
The cumbersome process of translating requirements through documentation led to inefficiencies and misalignment.
Relying solely on comprehensive requirements documents assumes customers know precisely what they want upfront. However, complex environments often lead to evolving needs, rendering initial documentation outdated.
Modernizing the Requirements Journey: A Paradigm Shift in Agile Landscape
Over the past five decades, the flow of requirements from inception to development has seen limited evolution.
Remarkably, even entities professing Agile methodologies continue to heavily rely on meticulously documented business requirements.
Yet, a shift has transpired.
Rather than presenting a weighty 25-page document, many now opt to break down project plans into "user story" work items, utilizing digital Kanban boards like Azure or Jira – although this doesn't inherently encompass the full essence of agility.
Upon project approval, as a charter is penned and the scope is outlined, the business analyst engages in a series of meetings with stakeholders, meticulously documenting every intricate detail.
The creation of a requirements document is no simple feat – I've experienced this firsthand. It's a laborious process, marked by numerous revisions and iterations.
A stringent prerequisite is the customer's meticulous grasp of their desires, down to the minutest particulars.
Once penned, the document undergoes a "requirements walk" – a collective review by stakeholders, meticulously scrutinizing every line for potential changes or revisions.
Verbal confirmation typically ensues, followed by formal sign-off procedures. Although initial unanimity is rare, eventual consensus is achieved.
Upon obtaining this sign-off, the requirements document assumes a sacrosanct status, deemed immutable.
In cases necessitating modifications, the process cascades into a "change in requirements," triggering an approval cycle. Subsequent updates are incorporated, followed by yet another review and sign-off request.
Post-sign-off, the baton is passed to the design phase.
Upon design completion, a meticulous review and formal confirmation process ensue before the torch is handed over to the developers.
This marks the moment when developers delve into the comprehensive document, utilizing it as a guiding manual, ensuring precise adherence to the prescribed guidelines.
Each developer takes ownership of their specific segment, with integration concerns deferred to a subsequent stage.
Queries and uncertainties find their way back to the business analyst, who, in turn, engages stakeholders for resolution. Meetings convene to address these queries, often resulting in updates or change requests.
The response loop circles back to the developer, referencing page numbers and sections for pinpoint clarity, ensuring the alignment of implementation with the outlined requirements.
Upon culmination of development, the mantle transfers to the testing phase.
Testers meticulously pore over the document, crafting test cases.
Any deviations from the established criteria prompt bug identification and reporting.
Subsequent to thorough testing, the product embarks on its User Acceptance Testing (UAT) voyage – an inaugural encounter with the business stakeholders.
This stage often unveils unexpected behaviors, leading to the discovery of bugs or soliciting change requests, despite the technical adherence to requirements. Often stakeholders are not satisfied with the product delivered.
Does this narrative resonate with your organization? It's quite likely. This process, akin to the practices of the 90s, underpins the rationale behind the inclusion of Principle 6 amidst the foundational Agile principles.
challenges of Requirements Documentation: A Shift Towards Dynamic Customer Needs
The fundamental flaw lies in presuming that customers possess a crystal-clear vision of their exact desires, right from the project's inception.
Especially within intricate landscapes like technology, customers often possess a broad understanding of their needs, rather than granular specifics. Even when they do, articulating intricate details can prove challenging.
Compounded by this is the temporal gap between requirement formulation and approval, spanning a considerable 1-2 years until User Acceptance Testing (UAT).
This extended timeline frequently ushers in evolving business dynamics, leading to shifting needs.
Stakeholders might lose sight of the original rationale behind certain requirements, resulting in dissonance when they finally witness the product in action.
Reflecting back to the mid-2000s, I engaged in a sizable endeavor encompassing a customer-facing web application fueled by a complex amalgamation of 29 legacy systems.
This presented an arduous task of harmonizing inputs from 29 distinct stakeholders across the organization.
Juggling the intricacies of extracting comprehensive details and securing consensus felt akin to a Herculean feat.
A painstaking year was devoted to documenting over a hundred pages.
One might question whether developers would genuinely digest a document of such magnitude. Often, developers skim such documents for business rules and resort to illustrated designs for coding cues.
A case in point involves a user registration form within the application.
A requirement mandated that any user input violating field rules should prompt a red error message atop the page, accompanied by a red-bordered highlight on the erroneous field.
Debates arose when developers challenged this approach, advocating for preventive logic rather than post-entry error alerts.
Unfortunately, deviating from the sanctioned requirements was prohibited, with possible reconsideration contingent on future enhancements and budget approvals.
Upon reaching UAT, stakeholders accepted the requirement-driven error message, yet end-users raised objections.
The confusion stemmed from allowing users to attempt an action, only to be reprimanded afterward.
Such error messages can trigger negative user perceptions and even lead to process abandonment due to an inundation of errors.
To illustrate the disparity, envision constructing a house with meticulous detail, only to unveil the final result after it's fully built. The realized outcome might not align with the envisioned concept, leaving little room for adjustment.
Contrarily, builders embrace a more interactive model.
Frequent consultations with homeowners occur during pivotal phases such as framing, wall installation, and flooring, ensuring alignment with expectations.
This proactive approach avoids costly rework by validating choices before they're finalized. The same is true in software development. We must have shortened feedback loops to adjust and ensure the customer feels like they are receiving value.
Unveiling the Parable of Telephone: A Parallel to Contemporary Project Realities
Can you recall the classic playground activity known as "telephone" from your elementary school days?
Though it might have gone by various names, the essence remains familiar to many.
Imagine a group of children forming a circle.
The instructor starts by whispering a brief phrase into the ear of the first child. This phrase then travels from one person to the next, like a chain reaction. Ultimately, the last person vocalizes the message, often to discover that it has undergone subtle alterations along the journey.
This playful exercise serves a purpose beyond amusement – it mirrors the intricate dynamics of relaying, receiving, and retransmitting information.
With each transfer, nuances can be added or omitted, as every individual processes the message through their unique lens.
Educators employ this illustration to emphasize the significance of seeking information from the primary source.
When we encounter text, our interpretation is invariably tinted by personal experiences and foundational comprehension.
Each person deciphers the underlying meaning within their cognitive framework, potentially leading to distinct reactions, even when confronted with identical content.
Lacking a direct avenue for clarification, we lean on our existing knowledge to construe meaning.
When unfamiliar content arises, we instinctively correlate it with familiar concepts as a cognitive bridge for comprehension.
The above anecdote resonates as a striking parallel to our present-day project landscapes.
Consider the scenario: the client articulates their vision, yet its interpretation morphs during the intricate journey of project realization.
Discrepancies emerge between the customer's initial explanation and the evolving interpretation embedded within the process. Even the contrast between what the client articulated and their authentic necessities can be stark.
This phenomenon is akin to the experiences of the Agile pioneers in the late 90s.
Just as the "telephone" exercise illustrates the dynamic shifts of information, the Agile visionaries navigated similar intricacies decades ago.
Why Face-to-Face matters
When it comes to communication, a direct face-to-face conversation carries a multitude of advantages:
Elevates credibility and nurtures trust.
Fosters the building of robust relationships.
Facilitates immediate feedback.
Establishes and strengthens trust.
Enhances the art of persuasion.
Catalyzes active participation and seamless collaboration.
Facilitates conflict resolution with greater finesse.
Encompasses the auditory dimension, including tone nuances.
Presents a chance for crystalline clarity.
Empowers the interpretation of nonverbal cues like expressions and gestures.
Emboldens innovation and transparency.
Imparts firsthand reception of information.
Evades ambiguity.
Envision a scenario where a project manager, business analyst, designer, developers, and testers converge within the same space, collectively absorbing the customer's vision before embarking on the swing's creation.
This harmonious assembly constitutes a cross-functional team.
Amidst this unified presence, an environment conducive to query clarification thrives. During collaborative sessions, concepts are sketched out on a whiteboard, while the customer interjects with real-time insights.
Post-session, a synergy-driven endeavor unfolds, culminating in a proof of concept, meticulously crafted within a few weeks.
This prototype is then presented back to the customer for additional input.
Subsequent tweaks are made, with subsequent rounds of presentation and refinement.
The outcome: a swing harmonizing impeccably with the customer's requisites, its final form underpinned by an expedited feedback loop.
Herein lies the quintessence of Agile methodology.
Could it be that the pivotal aspect lies not in physical co-location, but rather in prioritizing dialogue over the written rendition of requirements?
Elevating Dialogue Over Documents: Unlocking Agile's True Essence
Amid the shifting sands of time, one revelation stands clear: it is the power of conversation that ignites the spark of innovation, not merely the ink on pages.
Rewinding to the late 90s, an era untouched by the ubiquity of remote work and virtual conferencing tools, we unveil the essence of Agile Principle #6, a beacon that transcends physical presence and delves into the realm of profound dialogue.
Picture a landscape where technology was a far cry from today's connectivity, where teams were often within arm's reach.
In this context, Principle #6 wasn't a plea for co-location but an ode to the dynamic tapestry of expressing and relaying customer needs.
Back then, customer aspirations were meticulously etched onto paper and dispatched to different departments like scrolls of old.
Yet, these written transcripts did not encapsulate the entire narrative.
The true conversations unfolded between business analysts and stakeholders, crafting a document that, while vital, was far from the sole storyteller.
The founders' message rang clear: documentation, though a cornerstone, was just one facet.
The symphony of conversation, collaboration, and feedback was the heart's rhythm that couldn't be transcribed. This is precisely why they honed in on "face-to-face CONVERSATION" – a clarion call to seize the power of interpersonal exchanges.
In the realm of Agile, conversation reigns as the most potent and streamlined conduit for information to traverse within a development ensemble.
This perspective catalyzes a shift in focus, with collaboration and discourse ascending the throne over written documentation.
It's the fusion of business, engineering, and QA, when they engage in harmonious interplay, that the veil of discovery and comprehension lifts to unparalleled heights.
Within this discourse, the question transforms from "what" into "why."
It's a realm where the enigma of problem-solving is unshackled, and the engineering teams are afforded the space to decipher the "how." For they are the maestros of implementation, requiring not a manual, but a shared cognizance.
As time advanced, the corporate world morphed into a kaleidoscope of evolution.
Remote work burgeoned, and the digital realm blossomed with platforms like Webex, Slack, Teams, and Zoom.
These conduits, akin to teleportation devices, bridge geographical gaps, enabling the same camaraderie, innovation, and collaboration as a shared physical space.
The founders eloquently inscribed, "In order to succeed in the new economy... deliver something timely and tangible."
This manifesto articulates a seismic shift away from archaic bureaucracy, embracing the heart of Agile – valuing individuals and interactions over processes and tools.
As we contemplate Principle #6, its essence resounds: the founders endorsed "face-to-face" not for proximity's sake, but for the symphony of firsthand revelations, orchestrated directly from the source, transcending the voluminous tomes of written requirements.
This principle, like a lodestar, navigates us towards Agile's core, where individual connections illuminate the path forward.