Your conversations are a delivery system

A team finishes a planning meeting. Everyone nods. The alignment felt good. Two days later, the same item is blocked. When you ask why, you get three different versions of what was actually decided. The architecture concern that one engineer raised quietly never made it into the ticket. The person who actually knew the integration constraint didn't speak. And the "decision" turns out to have been a shared mood, not a choice anyone owns.

This is not a soft-skills problem. It is a flow problem.

In a delivery system, conversations are where the real work of coordination happens. A refinement session, a planning meeting, an architecture review, an incident retro: these are the moments where teams surface information, expose constraints, decide who owns what, and turn uncertainty into a next action. When that conversation runs badly, the cost doesn't show up in the meeting. It shows up downstream, as rework, blocked items, decisions that get made twice, and the long tail of cycle time where nobody can quite say why a thing took three weeks.

So the question worth asking is not "was the meeting good?" It is "did the conversation reduce the decision queue?"

Conversation as infrastructure

It helps to stop treating meetings as overhead and start treating decision-bearing conversations as infrastructure, the same way you treat your build pipeline or your ticketing system. They move information from the people who have it to the people who need it. They expose constraints early, while they are still cheap to handle. They allocate decision rights. And they convert a fuzzy situation into something the team can act on.

When that infrastructure is degraded, the failure is quiet. An unspoken objection is hidden work-in-progress: it exists, it will block something, but it isn't on any board. A missing expert is missing information that you'll pay for later. Pseudo-agreement, the room going along because disagreeing is expensive, is a defect that ships and gets caught downstream. None of this is visible in a velocity chart until the rework arrives.

What the evidence actually says, and doesn't

The temptation here is to conclude "so talk more, talk better" and call it a methodology. The research doesn't support that leap, and it's worth being precise about what it does and doesn't show.

There is a consistent association between how teams work together and how they perform. In a survey of 477 respondents across 71 agile teams in 26 companies, Lindsjørn and colleagues (2016) found that teamwork quality had a positive relationship with team performance, but with an important wrinkle: the effect was clear when team members and team leaders rated performance, and negligible when product owners rated it. The strongest, most consistent effects were on learning and work satisfaction, not on delivered output. This is survey data, cross-sectional, based on perceptions, and rater-dependent. It tells you teamwork quality matters; it does not prove that improving a conversation causes faster delivery.

Rathor, Xia and Batra (2024), surveying 160 software professionals, found that communication and collaborative decision-making sat in the middle of the causal story. They mediated the effects of team autonomy, competence and iterative development on agility. In plain terms: autonomy and skill don't turn into agility on their own. They have to pass through how the team communicates and decides. Again: a survey, cross-sectional, not a direct measurement of flow.

The most concrete finding for our purposes comes from a controlled experiment. Miranda and colleagues (2025) put 72 students into 18 teams of four and had them do an effort-estimation task twice, once ad hoc, once with planning poker, while recording who spoke and for how long. Planning poker did not change the total amount of talking or attention. What it changed was the distribution: speaking time became more equitable. A simple structural rule redistributed participation without anyone facilitating it manually. The caveat is large and obvious: these were students doing an estimation exercise in a co-located room, not an industrial team shipping software. You cannot stretch this into "planning poker improves delivery." You can take it as a clean demonstration that structure changes who gets heard.

A more recent survey by Mensah (2024) points the same direction. Extended teamwork-quality factors, particularly mutual support and shared values, correlated with performance. But it's a new paper with few citations and the details are thin, so treat it as a weak corroborating signal rather than a load-bearing source.

Put together, the honest summary is narrow: teamwork quality, communication and collaborative decision-making are reliably related to performance and agility, the relationships are not clean or fully causal, and who you ask changes the answer. That's enough to justify managing decision conversations deliberately. It is not enough to justify a transformation programme built on "better conversations."

Structured participation is a flow intervention

The practitioner Barry Overeem has written about how often the basic problem is mundane: monologues, interruptions, no space to actually answer a question. His suggested counter-move is almost too simple: start with silence. Give people a minute to think and write before anyone talks, so the fast talkers don't set the frame and the slower thinkers aren't lost. These are practitioner observations, not evidence, and I treat them as such. But they line up with the Miranda result: a small structural rule can change participation without heroic facilitation.

That's the useful reframe. Equalising who speaks isn't about fairness for its own sake. In a delivery context, the quiet expert holds information you need to make a good decision. If the room's structure silences them, you are flying with a known instrument switched off, and you'll find out at integration time.

A conversation-to-flow audit you can run Monday

Here is something concrete to try, no new tooling required.

Take your last ten decision-bearing conversations. Not stand-ups, but the ones where something was supposed to be decided: refinement, planning, an architecture review, an incident review, a stakeholder sync.

For each one, write down eight things:

• The decision question. What were we actually trying to decide?
• The decision owner. Who owned the call, by name, not by role?
• Who had the information needed to decide well.
• Who actually spoke.
• What dissent, if any, got tested rather than smoothed over.
• The final decision.
• The assumption left unresolved.
• The next observable action, and who does it.

A week later, go back through the same ten and check three things. Did the decision remove a wait state, did something that was blocked become unblocked? Did it create a rework loop, did the team have to redo work because the decision was wrong or unclear? Or did it simply reappear, getting re-decided in a later meeting because it was never really closed?

You will usually find that the conversations that felt worst were not the ones that cost the most. The expensive ones were the smooth meetings where dissent was never tested and the decision was never owned.

Two design rules follow naturally, and both are cheap:

One minute of silent writing before the discussion opens. Everyone notes their read of the question first. This is the Overeem move, and it stops the first confident voice from anchoring the room.

Decision closure before anyone leaves. Out loud, name four things: who owns this, which option we chose, what evidence we still don't have, and when we'll check whether it held. If you can't fill those four in, you didn't make a decision. You had a conversation about one, and it's still in the queue.

What this is and isn't

This isn't a claim that better meetings will fix your delivery. The evidence is associational, mostly from surveys, sometimes contradictory depending on who rates performance, and the one clean experiment used students on a toy task. Anyone selling you a "conversation transformation" is overselling. None of this licenses strong causal claims.

What the evidence and the practice together do support is more modest and more useful: decision conversations are part of your flow, not a soft layer on top of it. They can hold hidden WIP, generate rework, and leak decisions into the future. A Delivery Manager or Agile Coach who manages them as part of flow, designing participation, protecting thinking time, naming decision owners, and checking afterwards whether decisions actually removed waiting, is doing flow work, not facilitation theatre. The audit above is how you find out whether your conversations are paying their way. Use it as a diagnostic for your own system, not as proof of a general law.

Sources

• Lindsjørn, Y., Sjøberg, D. I. K., Dingsøyr, T., Bergersen, G. R., & Dybå, T. (2016). Teamwork quality and project success in software development: A survey of agile development teams. Journal of Systems and Software, 122, 274–286. doi.org/10.1016/j.jss.2016.09.028
• Mensah, A. L. (2024). The impact of teamwork quality (TWQ) on agile software development team performance. International Journal of Project Management, 6(3), 25–51. doi.org/10.47672/ijpm.2179
• Miranda, D., Noel, R., Godoy, J., Escobedo, C., Cechinel, C., & Muñoz, R. (2025). Quantitative analysis of communication dynamics in agile software teams through multimodal analytics. Scientific Reports, 15, Article 9898. doi.org/10.1038/s41598-025-91328-x
• Overeem, B. (2025, December 29). Designing better conversations starts with silence. The Liberators. medium.com/the-liberators/designing-better-conversations-starts-with-silence
• Overeem, B. (2026, January 11). Crappy conversations. The Liberators. medium.com/the-liberators/crappy-conversations
• Rathor, S., Xia, W., & Batra, D. (2024). Achieving software development agility: Different roles of team, methodological and process factors. Information Technology & People, 37(2), 835–873. doi.org/10.1108/ITP-10-2021-0832