I want to follow up on my Monday post about meditating on the Manifesto by digging into the 6th Principle:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“

Context matters here.

When this was drafted in 2001, reliable real-time video conferencing was not widely available. Large companies were also promoting offshore development to reduce costs, and it was common for 50–200 page requirements documents to be emailed to engineering teams 12 hours out of sync, with the hope that the document would carry the intent.

Principle #6 was softly nudging back on this common practice. It was elevating the quality improvements and time efficiencies that happen when two humans can actually talk to each other face to face.

In practice, many organizations interpreted this principle to mean teams must be colocated to be Agile.

My take is a little different.

I believe it was at the 2010 Global Agile Alliance Conference that I saw Alistair Cockburn present on his research. The point, as I remember it, was that spontaneous osmotic communication starts to decay in a half-life mirroring the length of a school bus. (Why a school bus? Because he didn’t want to argue over imperial vs. metric conversions with a global audience. We all know the approximate length of a school bus.) 

In lay terms, for every school bus of distance, it becomes 50% less likely that you will overcome friction, get out of your chair, pick up the phone, send the message, or walk over to engage a coworker with a thought or question. Think about what this means for open floor plans, cubicles, offices, and even the placement of doors between offices (side-by-side vs. opposing sides). 

When the Agile movement started sweeping through Philadelphia around 2006, I saw teams get clustered into shared rooms, walls knocked down, and communication skyrocketed.

But is “co-location” still necessary in this 2026, post-COVID, globally distributed economy when most teams now have dedicated chat channels and always-ready video rooms available to them?

My last team cluster was split between the US and Brazil; close enough in time zone that we could get online and talk face to face whenever we needed. Our team culture was such that someone could ask a quick question in chat, and everyone related would shift into the Zoom room for conversation. This was even part of our working agreement.

We also did standups on Zoom individually, so there was no advantage to 3 people huddled in a conference room while the other 7 were joining solo.

That felt pretty close to co-located. It was face to face, and when structured properly, it created meaningful conversation with very little friction.

In that setup, the school bus metaphor evolved. With one-click access to video conversation, physical distance was no longer the main constraint. Everyone was effectively less than a school bus apart. The real constraint became overlapping time availability.

That is the difference between following the perceived rule and understanding the intent.

Over the years, I’ve become a fan of distributed teams. But I’m still wary of distribution that crosses too many time zones, because at some point the friction comes back. And when the friction comes back, Principle #6 starts guiding us again.

For 20+ years, I’ve watched people reduce Agile debates to Scrum-centric thinking, and now often to SAFe-centric thinking. But the real reference point is the Manifesto, not a framework. The 17 signers in Snowbird agreed on 4 Values and 12 Principles without naming an approach because they were not all coming from the same viewpoint. That matters, because the founding mix was broader than many people remember. By my count, the mix was something like 7 XP, 3 Scrum, 2 Crystal, and the rest from other adjacent frameworks.

Scrum was not the center of the story, only part of it.

This is why it is important to remember that Scrum is Agile, but Agile is not Scrum. Prescriptive Scrum can be a great place to start, but instead of assuming a graduation to SAFe (or some other scaled framework), your path might be better served by Kanban, Lean, XP, Crystal, or some blend of tools across several frameworks.

Your goal should be a fit-for-purpose solution for the environment you’re actually in.

This is one of the reasons I like to periodically revisit the Manifesto, especially when joining a new organization. A weekly lunch with interested Agile peers, working through one Value or Principle at a time, can create space for a deeper 30-minute discussion. What did this line mean when it was drafted, why was it written? What was the context back then? Does it still hold up? Should it evolve? How does it apply to our environment here?

It still surprises me how many people in those groups have never really stopped to ponder these ideas in their raw form.

Before you argue practices, spend some time with the principles.

When was the last time you and your team meditated on the Agile Manifesto?

I was recently reading a post about how some Product Managers skip customer interviews.(I’ll set aside the issue that this step is being skipped, as real-world feedback after launch tends to humble that approach.) The post focused on starting with a few strong questions during customer interviews to identify the unknown, validate real issues, and understand associated costs to help prioritize them.

That all makes sense and is generally good advice. But I found myself thinking there was one piece missing from the conversation.

There’s a concept from Lean called “going to the gemba.” The oversimplified version is going to where the work actually happens and seeing it for yourself. When I think about user interviews, it comes down to adding one simple question:

“Can you show me?”

User descriptions can be notoriously mistranslated. People explain what they think is happening, or what they believe is important, and a lot gets lost in translation. Watching the work in action tends to remove that gap pretty quickly.

I saw this years ago working on software used in operating rooms. At the time, everything we built across the hospital’s ecosystem followed the same pattern: clean white interfaces across the entire product suite for consistency, simplicity, and ease of use.

But we kept getting signals that OR users didn’t like the UI, without much detail. It started to impact our ability to engage beta customers and have meaningful conversations about adoption in places where we already had a foothold.

So we went to the gemba and observed.

It turns out, operating rooms are dark environments. People are very intentional about what they focus on and how they see the procedure. Keyboards are covered for sterility and not easy to use, and the entire space is optimized around controlled and directed lighting.

In that context, a bright interface wasn’t just inconvenient, it didn’t fit the environment at all. It created a glow that disrupted the entire room.

That observation changed the direction of the design quickly. We shifted toward simpler interactions and dark-themed interfaces that worked with the environment instead of against it. It was something we wouldn’t have fully understood just by asking questions, as this clinical context was very different from the others our solutions had been optimized for.

What people say only goes so far, but you can uncover a lot by watching the work directly.

Go to the gemba.