Fight, Wait, or Hope: Bion's Basic Assumptions and Why Your Team Is Not Actually Working
Every Agile team presenting as 'dysfunctional' is usually doing one of three things: fighting an enemy, waiting to be rescued, or hoping that a future moment will solve everything. Wilfred Bion named these group states in 1952. They have been running teams since long before Scrum existed.
The team that has been "dysfunctional" for months
Sprint seven. The retrospective follows its now-familiar shape. Someone mentions the deployment pipeline again. Someone else raises the backlog refinement quality — "stories still coming in half-baked." A third person, the one who usually says little, mentions that the architecture team hasn't responded to three requests. The Scrum Master notes all of it on the board. The team agrees to "follow up." Nobody says anything that changes anything. The coach sits with a feeling that is increasingly hard to name: not boredom, not frustration exactly, but the specific flatness that comes from watching effort produce no movement.
The team has been called dysfunctional in a steering committee. The word has been used twice in emails. The coach has introduced new retrospective formats, run a team working agreement session, facilitated a mapping exercise on dependencies. The team engages with all of it politely and continues as before: blame, escalation, waiting, repeat.
What the coach has not yet named — because the Agile coaching literature rarely names it — is that this team has stopped working. Not stopped delivering: they still ship, somewhat. They have stopped engaging in the shared cognitive and emotional effort that constitutes a group doing real work together. They are operating in a different mode entirely. Wilfred Bion called it basic assumption mode, and he mapped it sixty years before anyone wrote a sprint planning guide.
Wilfred Bion and the work group that couldn't work
Bion was a British psychoanalyst who worked with groups in the 1940s, first in a military rehabilitation unit and later at the Tavistock Clinic. What he observed — and what he spent much of his subsequent theoretical life trying to explain — was that groups do not simply work. They oscillate. At some moments a group is genuinely engaged with its task: curious, creative, tolerant of uncertainty, willing to think. At other moments the same group appears to be pursuing a different agenda entirely — one that has nothing to do with the stated purpose, and everything to do with managing a shared anxiety.
Bion called the first mode the work group: the group functioning in relation to its actual task, capable of reality-testing, able to learn from experience. He called the second mode the basic assumption group: the group operating from an unconscious shared assumption about how to stay safe. The basic assumption is not a decision. Nobody chose it. The group moves into it collectively, below the level of awareness, because something about the work has activated an anxiety that the group cannot yet think about directly.
Bion identified three basic assumptions: fight/flight (the group unites against or flees from a perceived enemy); dependency (the group waits for an omnipotent leader to rescue it); and pairing (the group invests hope in a future salvation, endlessly deferred). Each is a coherent, internally logical response to anxiety. Each completely prevents the group from doing its work.
The crucial insight — the one that most Agile frameworks are structurally incapable of incorporating — is that basic assumption activity is not a sign that the team is broken. It is a sign that the group is anxious about something real, and has not yet found a way to think about it. The basic assumption is information. The coach's job is to read it, not fix it.
Fight/flight: the team that needs an enemy
In fight/flight, the group's unconscious assumption is that there is a threat — an enemy that must be attacked or escaped. The group draws energy and identity from its relationship to this threat. Without the enemy, the group would have to face whatever the enemy has been helping it avoid: its own inadequacy, its internal disagreements, its uncertainty about what it is actually trying to build.
In Agile teams, fight/flight typically looks like this: the deployment pipeline is always broken (and the platform team won't fix it). The product owner keeps changing priorities (and doesn't understand engineering). The architecture standards are unreasonable (and were set by people who don't do real work). The escalation path is blocked (and senior management doesn't care). The team has a deep, sustaining narrative of obstruction — and within that narrative, the team itself is unified, competent, and blameless.
The signs are specific: energy rises when the enemy is mentioned; complaints about external parties carry an emotional charge disproportionate to their actual impact; the team returns to the same grievances across retrospectives without anything changing; attempts to redirect attention to internal process are met with "yes, but we can't really do that while the [external problem] remains unsolved." The identified enemy may be real. The function it serves is defensive.
What coaches do wrong: they join the fight. The coach who sits in the retrospective and begins sympathetically mapping the team's external dependencies, or who takes the escalation path on behalf of the team, or who validates the narrative of obstruction ("yes, that tooling is genuinely difficult") is giving the basic assumption exactly what it needs. The enemy is now confirmed. The group is now even less likely to turn its attention inward.
What actually helps: the coach notices the fight/flight dynamic without naming it directly. They hold a position of mild, curious scepticism about the narrative — not dismissing the external problems, but gently keeping the question open: "Given that those constraints are real, what could we change about how we work together within them?" The question is not an accusation. It is an invitation back to the work group. It will need to be issued many times.
Dependency: the team waiting to be saved
In the dependency basic assumption, the group operates as if there is or should be an all-knowing, all-providing leader who will rescue it from its difficulties. The group's energy goes into seeking, testing, and relating to this figure rather than into the work itself. If the leader is present, the group is passive and deferential. If the leader is absent or disappoints, the group is resentful and destabilised.
In Agile teams the dependency assumption is especially ironic, because the entire philosophy of Agile is built around self-organisation — and yet dependency is one of the most common patterns coaches encounter. It looks like: every non-trivial decision is escalated to the Scrum Master or coach. The team "can't" prioritise until the product owner tells them what matters. The team "can't" improve its process until management changes the conditions. The retrospective produces the same action items — assigned to the coach, the SM, or a senior stakeholder — sprint after sprint. The team is waiting. Not lazily: genuinely waiting, with an unconscious conviction that the conditions for real work do not yet exist, and will only exist when the right leader appears and makes them possible.
The signs: the team looks to the coach before speaking in group settings; questions addressed to the team are redirected back to the SM or PO; self-organisation exercises produce discomfort and rapid relapse to waiting; the team describes its constraints in ways that systematically position the solution outside the team's control. The dependency is often accompanied by warmth and compliance — which is part of what makes it so hard to name.
What coaches do wrong: they rescue. The coach who answers the questions the team should be answering itself, who takes action items from retrospectives, who adjusts the conditions on behalf of the team, is enacting the dependency rather than addressing it. The team's conviction that salvation comes from outside is confirmed. The coach may feel useful and effective. The team's capacity for self-organisation declines.
What actually helps: the coach becomes less available, consistently and kindly. Questions are returned: "What does the team think?" Decisions are held open until the team makes them. The discomfort this produces is the material: the coach names it rather than alleviating it. "I notice we keep ending up back at the same question about who decides this. What would it mean for the team to decide it without asking anyone outside the team?" This is not a confrontation. It is an invitation to notice the assumption.
Pairing: the team living in a future that never arrives
Pairing is the subtlest of Bion's three assumptions, and in Agile contexts it is perhaps the most seductive. The group in pairing mode generates hope — not through action, but through the investment of expectation in a future event, a future relationship, or a future state. Two people, or a sub-group, or an idea, becomes the carrier of the group's messianic fantasy: when this is in place, everything will be different. The hope is real. The action it replaces is not.
In Agile teams this looks like: "We'll fix the technical debt after this release." "Once we have the right architect on the team, the design problems will sort themselves out." "When we've finished the platform migration, we'll finally have the capacity to do this properly." "The new head of engineering understands what we need — once they're settled in, things will change." Each of these may contain genuine observation. What makes them pairing activity is the deferral structure: the group's energy for change is absorbed into waiting for the future event rather than acting in the present.
The signs: the team has a chronic list of improvements that will happen "after" something; discussions about current process improvements are short-circuited by references to the future state; there is an identified person, tool, or event that carries the team's hope and is rarely examined critically; optimism about the future coexists with passivity in the present. The atmosphere is not depressed — it can be quite warm — but it is waiting.
What coaches do wrong: they encourage the hope. The coach who helps the team plan for the future state, who validates "yes, that architectural change will make a real difference," who engages with the messianic narrative as if it were a project plan, is extending the deferral. The team's capacity to act under current conditions is not built. When the future event arrives — as it sometimes does — the team discovers that the conditions it was waiting for do not, in fact, transform the group's anxiety. A new future event is then identified.
What actually helps: the coach keeps returning the group to the present. "What is one thing we could actually change in the next sprint, given the conditions we have right now?" The question is not a dismissal of the future aspiration. It is a refusal to let the future aspiration become a substitute for present action. Done consistently, it begins to interrupt the deferral pattern — slowly, because hope is a particularly durable basic assumption.
Hopper's incohesion: the distributed team that cannot cohere
Earl Hopper, a group analyst working in Bion's tradition, proposed a fourth basic assumption particularly relevant to organisations under trauma or extreme threat: incohesion. Where Bion's three assumptions represent ways of being together — however defended — Hopper's describes a group that cannot hold together at all. It alternates between two equally dysfunctional poles: aggregation (total fragmentation, everyone isolated, no real contact between members) and massification (merger into an undifferentiated mass, performative unity, differences denied).
For distributed and hybrid teams, this framework has striking explanatory power. The aggregation pole looks like: cameras off in every meeting, no conversation in the Slack channels, people working in silos that were supposed to be broken down by Agile, nobody raising problems, nobody sharing discoveries. The massification pole looks like: forced enthusiasm in all-hands calls, identical positive responses in retrospectives, a team that performs cohesion for external audiences while having no real exchange between members. Both poles prevent genuine contact. The oscillation between them is a sign that the team cannot tolerate the vulnerability of actual interdependence.
The incohesion assumption typically arises when groups have been through significant loss, restructuring, or repeated disappointment — when belonging itself has come to feel unsafe. Remote and hybrid settings amplify the risk because they remove the informal contact that builds enough felt safety for genuine exchange. The team looks, on paper, like it is functioning. The coach who pays attention to the quality of contact — not the outputs but the actual relational texture of meetings — will notice that something important is absent.
The work group is the goal, not a state you achieve once
One of the most practically important aspects of Bion's model is that the work group is not a permanent achievement. No team simply becomes a work group and stays there. All groups oscillate between working mode and basic assumption mode, sometimes within a single meeting. A team that was genuinely engaged with a difficult problem can shift into fight/flight the moment the problem becomes too anxiety-provoking. A team that was functioning in dependency can briefly access work group functioning when the stakes are low enough. The shift is continuous, and the coach who understands this stops looking for a point at which the work is done.
The practical implication is that the coach's job is not to fix the team's psychology permanently. It is to notice which mode the group is currently in, and to provide whatever gentle invitation back to the work is available in the moment. Three moves are particularly useful.
Naming without shaming: the coach names the pattern at a level of abstraction that makes it available without making it an accusation. Not "you're in fight/flight" — which produces defensiveness — but "I notice we've spent the last twenty minutes on the platform team's response time; I'm curious what would happen if we set that aside for now and looked at what we can change independently." The name is implicit. The invitation is explicit.
Returning attention to the actual task: when the group has drifted from its work, the simplest intervention is often the most powerful. "What were we actually trying to decide in this conversation?" The question interrupts the basic assumption without analysing it and creates a small opening for the work group to re-emerge.
Using the assumption as information: before moving to intervene, the coach asks internally — what is this group anxious about that it cannot yet think about directly? The fight/flight assumption tells you there is a threat being avoided. The dependency assumption tells you the group does not yet trust its own capacity. The pairing assumption tells you the present feels unworkable. Each basic assumption is a communication, coded and indirect, about what the group most needs to be able to approach. The intervention that responds to the underlying anxiety — rather than the surface behaviour — is the one that actually moves something.
The fear is the real coaching material
If you can identify which basic assumption mode a team is operating in, you know something more important than which intervention to try next. You know what the group is afraid of. Fight/flight tells you: the group is afraid of something within itself that it is externalising. Dependency tells you: the group is afraid that it does not have what it takes to do this work on its own. Pairing tells you: the group is afraid that the present situation is fundamentally unworkable, that real change requires conditions that don't yet exist.
These fears are almost always legitimate. There usually is something difficult about the situation that the team has not been able to think about directly. The basic assumption is not a distortion of reality — it is an indirect relationship to a reality that feels too threatening to approach straight on. The coach who understands this works with respect for the assumption, not contempt for it. The team that cannot yet think about its own adequacy needs something to lean on while it develops that capacity. The coach who rips the assumption away without providing an alternative container does damage.
Sprint eight will probably look like sprint seven. The retrospective will surface the same themes. The coach will sit with the same flatness. But the coach who knows what they are looking at — who can see the fight/flight pattern, notice the escalation structure, recognise the deferred hope — is no longer working blind. They know where the group is. They know, approximately, what the group is afraid of. That is not nothing. That is, in fact, most of what there is to know before you can begin to help.
Continue Exploring
Go deeper into the work
The Book
The Art of Creating Self-Organizing Teams
The full framework behind this article — contracting, team dynamics, and practical coaching tools for every stage of the journey.
Companion Toolkit
Resistance Radar & Resilience Scorecard
Practical tools for mapping resistance patterns and measuring whether interventions increased capacity — not just compliance.
TA for Agile
Co-creative TA in Agile Contexts
Ego states, psychological contracts, group imago, and the relational concepts that underpin this article — applied to real teams.