The conflict you avoid becomes WIP

Ask a delivery lead where their flow breaks down and you'll hear about dependencies, unclear requirements, or too much in progress. Ask the same person about conflict and the register changes. Conflict gets filed under "team health" or "something for the retro," a soft topic that lives next to the delivery work rather than inside it.

That split is expensive. A disagreement nobody resolves does not disappear. It reappears as a decision that keeps getting deferred, a backlog item that gets reopened, a stakeholder who quietly stops engaging, or an engineer who has a quality concern and says nothing. Those are not people problems sitting off to the side of the board. They are work in progress that never got a card.

Unresolved disagreement behaves like a hidden queue

Reinertsen's work on product development flow (2009) is useful here as a mental model, not as evidence about conflict specifically. His argument is that the most damaging queues in product development are invisible: half-finished decisions, work waiting on an input nobody has named, batches of assumptions that haven't been reconciled. Because these queues don't show up as inventory on a shelf, teams underweight their cost.

Avoided conflict fits that shape almost exactly. When two people hold competing assumptions about scope and neither raises it, the disagreement is still there, accruing cost. It surfaces later as rework when the build reveals the mismatch, as churn when a stakeholder relitigates a "settled" decision, or as a decision that sits in someone's inbox for three weeks because raising it means a hard conversation. The flow metrics you already track, cycle time, reopen rate, decisions-per-week, are partly a readout of how much unprocessed disagreement your system is carrying.

The practical claim is narrow: treat unresolved conflict as a category of hidden WIP, and you get a handle you can actually manage, rather than a mood you hope improves.

What the conflict research does and doesn't support

The strongest evidence on team conflict comes from organizational psychology, not from delivery data, so read it for direction rather than precision.

De Dreu and Weingart's meta-analysis (2003) pooled 30 studies and found that both relationship conflict and task conflict correlated negatively with team performance and satisfaction. The negative effects were stronger for complex decision and project work than for routine production tasks, which matters because software delivery sits at the complex end. They also noted that task conflict was less harmful when it stayed decoupled from relationship conflict.

De Wit, Greer and Jehn (2012) extended this across 116 studies and roughly 8,880 groups. Relationship conflict and process conflict (disagreement about who does what and how work is allocated) showed stable negative relationships with outcomes. Task conflict was more context-dependent: it looked more favorable only where it stayed weakly associated with relationship conflict, in top management teams, and for specific outcomes like decision quality rather than overall performance.

Two things follow. First, the popular slogan that "healthy teams have lots of task conflict" is not well supported as a general rule. Task conflict is, at best, conditionally useful, and the condition is that it doesn't curdle into personal friction. Second, process conflict, arguing about roles and hand-offs, is reliably corrosive, which is exactly the kind of conflict unclear delivery structures manufacture.

DeChurch, Mesmer-Magnus and Doty (2013) add the part most relevant to a delivery manager. Across 45 studies and 3,218 teams, how a team handles conflict explained performance variance beyond the amount of conflict present. Collaborating and openly addressing disagreement helped; competing and avoiding hurt. The state of conflict is one variable; the process for working it is a separate, controllable one. You cannot always choose how much disagreement your context generates. You can design how it gets processed.

On the software-specific side the evidence is thinner and should be held loosely. Shameem and colleagues (2018) surveyed 71 software practitioners, mostly in the Indian industry, and found requirements instability positively associated with relationship conflict, with relationship conflict hurting team effectiveness more than task conflict. It's cross-sectional and self-reported, so treat it as consistent with the broader pattern rather than as proof. Alami, Zahedi and Krancher (2024), combining 20 interviews with a survey of 423 respondents, found psychological safety supported behaviors that matter for quality: admitting mistakes, taking initiative, learning from earlier errors. That's a plausible enabler of surfacing conflict early, not a demonstrated line to delivery throughput.

Designing conflict-processing capacity

If avoided conflict is hidden WIP, the response is not to generate more conflict. It's to build the capacity to process the disagreement your work already produces, and to notice where it's piling up. Four moves.

Clarify decision rights before you need them. A large share of what looks like interpersonal tension is unassigned authority: two people who each believe the call is theirs, or a call nobody owns. The Scrum Guide (2020) is blunt on one piece of this: the Product Owner is accountable for maximizing product value and for Product Backlog management. Where that accountability is real, priority disputes have a defined endpoint. Where it's nominal, the same disputes recirculate as process conflict, the type the meta-analyses flag as reliably damaging. Name the decider for the decisions that recur. Ambiguous ownership is a queue generator.

Surface competing assumptions early, while they're cheap. Reconcile assumptions at the point they're formed rather than at the point the code contradicts them. A short pre-mortem on a contested feature, an explicit "what would have to be true for each option," a written statement of the disagreement before anyone defends a side: these pull the assumption mismatch forward, when resolving it costs a conversation instead of a sprint.

Separate task disagreement from personal friction, deliberately. The research keeps returning to one hinge: task conflict is tolerable when it stays uncorrelated with relationship conflict. That separation isn't automatic; it's a facilitation job. Keep debate on the artifact, the design, the estimate, the interface. Attack the option, not the person who proposed it. This is close to what the Scrum values of openness, respect, and courage describe, and it's part of what a Scrum Master is meant to protect when they work on impediments and barriers between people.

Track where unresolved disagreement reappears in the flow. You already have the instruments. Reopened tickets, decisions logged but not made, review cycles that stall on the same interface, stakeholders who go quiet: these are traces of conflict that got avoided upstream. In a retro, don't ask "is there conflict on the team." Ask "which decision did we defer three times, and why," then follow it back to the disagreement nobody wanted to name. Strode, Dingsøyr and Lindsjørn (2022) describe agile teamwork as resting on shared mental models, communication, and mutual trust; a decision that keeps reappearing is usually a sign one of those coordination mechanisms has quietly failed.

Evidence and limits

Be honest about what this rests on. Most of the conflict evidence is team and organizational psychology, not flow data pulled from Jira or Azure DevOps. The link between conflict states and delivery metrics is inferred here, not measured. The software-specific studies are fewer, smaller, and mostly cross-sectional self-report, so they suggest rather than confirm.

The evidence does not say conflict always hurts. The meta-analyses (De Dreu and Weingart 2003; de Wit, Greer and Jehn 2012) support a more specific reading: relationship and process conflict are reliably negative, task conflict is conditionally and modestly useful at best, and the handling of conflict (DeChurch and colleagues 2013) is a distinct lever from the amount of it. Treat the WIP framing as a way to make a fuzzy problem trackable, not as a proven causal chain from unresolved argument to slower cycle time.

One thing didn't make the evidence list on purpose. A German-language practitioner article on the cost of Product Owner conflict circulated in late June 2026 with a headline putting the figure at six figures. The direct source was inaccessible, so it's a market signal that the topic has traction, not a number to cite.

The move for a delivery lead is small and concrete. Pick one decision your team has deferred more than twice this quarter, find the disagreement underneath it, and ask: what would let us process that disagreement in the flow of work, instead of leaving it to accumulate off the board?

Sources

• Alami, A., Zahedi, M., & Krancher, O. (2024). The role of psychological safety in promoting software quality in agile teams. Empirical Software Engineering, 29(5), Article 119. doi.org/10.1007/s10664-024-10512-1
• DeChurch, L. A., Mesmer-Magnus, J. R., & Doty, D. (2013). Moving beyond relationship and task conflict: Toward a process-state perspective. Journal of Applied Psychology, 98(4), 559–578. doi.org/10.1037/a0032896
• De Dreu, C. K. W., & Weingart, L. R. (2003). Task versus relationship conflict, team performance, and team member satisfaction: A meta-analysis. Journal of Applied Psychology, 88(4), 741–749. doi.org/10.1037/0021-9010.88.4.741
• de Wit, F. R. C., Greer, L. L., & Jehn, K. A. (2012). The paradox of intragroup conflict: A meta-analysis. Journal of Applied Psychology, 97(2), 360–390. doi.org/10.1037/a0024844
• Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing. search.worldcat.org/title/435994279
• Schwaber, K., & Sutherland, J. (2020, November). The Scrum Guide: The definitive guide to Scrum: The rules of the game. ScrumGuides.org. scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
• Shameem, M., Chandra, B., Kumar, C., & Khan, A. A. (2018). Understanding the relationships between requirements uncertainty and nature of conflicts: A study of software development team effectiveness. Arabian Journal for Science and Engineering, 43(12), 8223–8238. doi.org/10.1007/s13369-018-3375-z
• Strode, D., Dingsøyr, T., & Lindsjørn, Y. (2022). A teamwork effectiveness model for agile software development. Empirical Software Engineering, 27(2), Article 56. doi.org/10.1007/s10664-021-10115-0