Designing a Communication Infrastructure That Reduces Friction

Last week, I wrote about how growing user stories signal the accumulation of communication friction. Teams compensate by adding text, creating the illusion of clarity while making everything slower.

This week: how to reduce friction instead of documenting around it.

The shift isn’t from “how do we write better stories?” to “how do we need less documentation?” It’s recognising that documentation serves conversation, not replaces it. Some friction must be accepted. The question is whether you’re managing it appropriately or avoiding the real communication problem.

Redefining “Done” to Enable Decisions

When I implemented availability windows with the team drowning in backlog grooming ceremonies, we also changed what “story complete” meant.

A story was completed when it achieved:

• All criteria are written on the back of the card
• The team’s definition of done
• The intent of the story—the “so that” clause

That third criterion matters the most. If developers made decisions that achieved the intent while the stakeholder was unavailable, and the stakeholder later wants corrections, that becomes another story for the backlog. The stakeholder can prioritise it or not for the following sprint. This approach requires trust. The product owner trusts the judgment of developers, and the developers trust that the product owner understood those decisions and accepted the story (even with changes that might come in the future).

This isn’t throwing work nor generating re-work nor technical debt. It’s recognising that perfect alignment requires conversation, and conversation requires availability. When stakeholders aren’t available, developers need authority to make decisions aligned with intent. If those decisions need refinement, that’s iteration, not failure.

The effect: developers stopped waiting for permission. They made calls based on stated intent, kept moving, and stakeholders adjusted in the next iteration if needed. Friction decreased because decision-making authority was distributed instead of concentrated.

When Documentation Is Genuinely Required

Regulated environments require documentation. For example, the ISO 13485 for medical devices mandates documented test cases. In this context, we defined that documented test cases were part of the story’s definition of done, and the domain expert must declare key quality criteria on the back of the card.

This is appropriate friction management. The constraint is real—regulatory compliance isn’t optional. The documentation serves its purpose: audit trails, quality assurance, and legal protection.

The difference from inappropriate documentation: this text captures decisions and criteria that must exist for compliance, not to avoid conversation. The team still talks. They also document what regulations require documenting.

Compare this to the team adding three-paragraph stories because they’d stopped talking during development. Both teams had long stories. One was managing real constraints. The other was compensating for broken communication by pretending text could replace dialogue.

Communication Infrastructure That Actually Works

Reducing friction isn’t about eliminating documentation or pretending conversation solves everything. It’s about designing your communication infrastructure deliberately.

Some teams need minimal cards because stakeholders are highly available. Some teams need intention-focused documentation because geography creates real distance. Some teams need documented test cases because regulations require them.

What doesn’t work: using documentation as a substitute for conversations, you’re avoiding the problem. Adding ceremonies that make communication more expensive while feeling more rigorous – you are adding to the friction. Front-loading detail that can’t actually answer the questions that arise during building – you are compensating for broken trust or poor availabilit. 

The difference between appropriate and inappropriate friction management is whether your documentation serves decisions or replaces dialogue. If it enables people to act in your absence, it’s serving a conversation. If it’s there because the team has stopped talking, it’s replacing it.

Next time your stories grow, ask why. Not “what detail are we missing?” but “what conversation aren’t we having?” That’s where friction lives. And that’s what coaching helps you see.

---

While the principles discussed here are straightforward, their effective implementation often requires a nuanced understanding of your team’s specific constraints versus behavioural patterns. That’s where evidence-based coaching makes the difference, helping you distinguish real friction from communication avoidance and design infrastructure that enables conversation instead of ceremony. Let’s explore how tailored coaching can help you reduce friction without adding more meetings or documentation. Reach out today, and let’s build a communication infrastructure that actually works for your team’s context.