True Agility comes from structure and clarity

This morning, I commented on a post by Matthias Orgler where he brought up a decision made by Sy Liebergot during the Apollo 13 mission. Matthias sees this as an example of how true Agile works if we trust the people closest to the problem instead of having management decisions. While I don't think this example is a strong advocate for team autonomy or distributed leadership per se, it does bring up a good case for why true Agility demands structure and clarity.

What happened on Apollo 13?

Let's quickly summarize the article and what happened on Apollo 13 that sparked this article by Matthias (who you should follow btw, because he writes a ton of awesome articles and posts!).

On April 13, 1970, during the Apollo 13 mission, oxygen tank pressures started to drop, and fuel cells began to fail. An EECOM controller by the name Seymour Liebergot made a decision to shut down the fuel cells to save the crew. Liebergot was an EECOM controller and was responsible for the electrical and environmental systems on board the Command Module.

During Apollo 13, flight controller Seymour Liebergot ordered a routine stirring of the oxygen tanks to address a faulty sensor reading. When astronaut Jack Swigert activated the fans, a wiring fault caused Oxygen Tank 2 to explode, damaging Tank 1 and knocking out two of the three fuel cells that powered the spacecraft. Liebergot initially suspected an instrumentation error, but working closely with his backroom support team, the collective picture of abnormal readings across multiple systems led them to confirm a catastrophic failure. With oxygen leaking and power critically reduced, the mission shifted from lunar landing to crew survival.

As a result, the crew survived, and Apollo 13 became known as NASA’s “successful failure.”

A great example of how teams should work

Matthias sees this as a great example of distributed leadership, which I disagree with, as this, in my opinion, was not leadership but authority and ownership. This might seem like nitpicking, but as you know, words matter. He also identifies that this situation required several things that are often missing in many organizations.

• Clear Goals

• Clear Ownership

• Trust

• Preparation

From this, Matthias sees that "Ordinary people, trusted with leadership, rose to extraordinary heights". The thing is, though, that Seymour Liebergot was not ordinary in any way. He was an expert in charge of one of the most critical systems onboard the Apollo 13. He was not a generalist or T-shaped worker; he was a specialised electric engineer with 8 years of hard-earned experience on multiple Apollo missions and a distinguished military background.

Where Matthias sees this as an example of Agile working because leadership was distributed, I see it as a great example of how Agility is working because of experience and expertise. This was also a team effort, as Seymour Liebergot got help from his team to identify the best solution for the situation. The decision was made not from chance, not from opinion, but from experience and expertise, and it was based on evidence as the crew of Apollo 13 confirmed the situation.

This situation did not work because the team was Agile; it worked because the team had clarity and because they knew exactly how to act through clear processes and training. It did not work because authority was distributed; it worked because the team was experienced and had earned the trust required for decisions to be the appropriate way to act.

It worked because the team was prepared and had procedures and workbooks for almost any scenario that could happen. It worked because the team knew every wire, every bolt, and every valve in the spacecraft. It worked because the team had trained and planned every aspect of the mission in detail months before launch. It worked because there was a team that trusted each other and worked together with clear ownership and authority.

Most organizations don't have teams

We tend to use the term Team for any collection of people, but a team requires more than just putting people together in a room with a common goal. People who just work together towards something are just a group, not a team. All teams are groups, but not all groups are teams. The distinction hinges on interdependence: when members genuinely need each other to accomplish something, a group becomes a team.

In group psychology, groups and teams are distinct in several important ways:

Group

A group is a collection of individuals who share a common identity, characteristic, or purpose, but whose members work largely independently. Key features:

• Members may have loosely related or even unrelated goals

• Coordination is minimal — members don't need to rely on each other to succeed

• Success is measured individually (e.g., a class of students, a department at work)

• Social influence operates through norms, conformity, and social identity (Tajfel & Turner's Social Identity Theory)

• Membership can be passive — you can belong to a group without actively participating

Team

A team is a specific, more structured type of group where members are interdependent and work toward a shared goal. Key features:

• Members have complementary roles and must coordinate to succeed

• Collective outcomes matter more than individual ones

• Accountability is mutual — members depend on each other

• High levels of communication and collaboration are required

• Teams develop stronger cohesion and role clarity over time

Psychologists like Richard Hackman (Hackman, J.R. (2002). Leading Teams. Harvard Business School Press) argued that true teams require a real task, clear boundaries, and a stable membership — without those, you just have a group calling itself a team (what was referred to as a "pseudo-team" by researcher Michaela West, 2000-2012 - team effectiveness in healthcare), which can actually perform worse than a well-functioning group because it creates coordination overhead without the benefits of genuine teamwork.

Research by Ruth Wageman ("Interdependence and Group Effectiveness" in Administrative Science Quarterly in 1995) specifically found that teams perform best when the task itself requires collaboration, not just when collaboration is encouraged culturally. If I can complete my work without needing you, we're functionally a group regardless of what we call ourselves.

This is why many Scrum teams struggle. If developers just pull tickets independently from a backlog and work in parallel without needing each other, they are psychologically a co-acting group — individuals doing parallel work under a shared label — not a true team.

The key is that Scrum distinguishes between role and skill. Everyone shares the accountability for delivering the increment, but in practice, people still bring different skills — frontend, backend, testing, UX, etc. The interdependence comes from needing all those skills to deliver a working product, even if no one "owns" a specialism exclusively.

This distinction is often missed in dysfunctional Scrum groups, where the impression is that Scrum teams should be T-shaped or consist of generalists. Groups that do not have specializations are, by definition, groups and not teams.

Teams develop stronger cohesion and role clarity over time

While it is broadly true that teams develop stronger cohesion and role clarity over time, the process is neither linear nor automatic. Schutz's FIRO model suggests that role clarity and cohesion are sequential rather than parallel — groups first negotiate belonging, then authority and roles, and only then develop genuine closeness. Unresolved tensions at any stage can stall or reverse the process entirely.

Sports psychology adds further nuance: Albert Carron's research (Carron, A.V., Widmeyer, W.N., & Brawley, L.R. (1985), Carron, A.V., Colman, M.M., Wheeler, J., & Stevens, D. (2002)) distinguishes between task cohesion (shared commitment to the goal) and social cohesion (interpersonal liking), and finds that task cohesion is the stronger predictor of performance — meaning a team does not need to be close to be effective. Sports research also shows that role acceptance matters as much as role clarity; a player who understands their role but resents it contributes less than one who has genuinely bought in.

Finally, cohesion is not simply a function of time together — membership changes, conflict, or weak leadership can reset a team's development, while shared pressure and challenge can accelerate it. A more precise claim is that teams have the potential to develop cohesion and role clarity over time, provided interpersonal needs are worked through, roles are accepted rather than merely assigned, and membership remains reasonably stable.

FIRO (Schutz, 1958)

FIRO (Fundamental Interpersonal Relations Orientation) describes three interpersonal needs — Inclusion, Control, and Affection — and Schutz proposed that groups move through these phases sequentially as they develop.

The fit with the claim is reasonable: FIRO implies that cohesion and role clarity do emerge over time, but through a specific interpersonal process:

• Inclusion phase — members test whether they belong (identity and membership are uncertain)

• Control phase — members negotiate influence and hierarchy (role clarity is being worked out here)

• Affection phase — genuine closeness and trust develop (cohesion emerges here)

So FIRO actually adds important texture — cohesion and role clarity don't develop simultaneously or smoothly. Role clarity comes before cohesion in Schutz's model, and the process can stall or regress at any phase. This complicates the simple claim that teams "develop stronger cohesion and role clarity over time" as if they move together in parallel.

FIRO also implies that unresolved inclusion or control issues actively block cohesion — meaning time alone doesn't produce development. The interpersonal work has to happen.

Sports Team Research

Sports psychology offers some of the richest empirical data on team development, and it adds further nuance:

Cohesion is multidimensional — Albert Carron's work (the Group Environment Questionnaire) distinguishes between task cohesion (commitment to the group's goal) and social cohesion (liking each other). These don't always develop together, and crucially, task cohesion predicts performance better than social cohesion. A team can be high performing without members being close friends.

Role clarity and role acceptance are different things — In sports teams, players may understand their role clearly but resent it (a talented player stuck on the bench, for example). Research suggests that role acceptance matters as much as role clarity for both cohesion and performance, and this is harder to develop than mere clarity.

Cohesion can develop quickly or not at all — Elite sports teams, particularly those assembled for short tournaments, show that cohesion can form rapidly under pressure and shared challenge, rather than gradually over time. This challenges any simple linear model.

Tuckman's model Bruce Tuckmans model (Forming, Storming, Norming, Performing), is often cited alongside sports contexts and aligns with FIRO reasonably well — but sports research has shown teams can skip or revisit stages, especially when membership changes (a new signing, an injury), which resets some of the development.

Summary

The original claim — that teams develop cohesion and role clarity over time — is a reasonable default but oversimplified in three ways:

1. FIRO suggests that role clarity and cohesion are sequential, not parallel, and the process can stall

2. Sports research shows that task cohesion and social cohesion are separable, and time doesn't guarantee either

3. Development isn't linear — membership changes, conflict, or poor leadership can regress a team to earlier stages

A more defensible claim would be: teams have the potential to develop cohesion and role clarity over time, provided interpersonal needs are addressed, roles are not just clarified but accepted, and membership remains reasonably stable.

Authority and Leadership in Group Psychology

Group psychology has a lot to say about authority, and it's one of the more complex and contested areas.

Formal vs Emergent Leadership

Groups consistently produce leadership even when none is formally assigned. Research on leaderless groups shows that within a short time, informal hierarchies emerge based on perceived competence, assertiveness, or social dominance. This suggests leadership is a group-level phenomenon, not just an individual trait — the group partly constructs its leader by granting them influence.

Hollander's idiosyncrasy credit model is useful here — leaders earn influence by first conforming to group norms, building trust and credibility, and only then can they deviate from norms or push the group in new directions. Authority is therefore socially negotiated, not just assigned.

FIRO and Authority

As discussed earlier, Schutz placed the Control phase at the heart of group development — the negotiation of influence, hierarchy, and decision-making. Until this is resolved, the group cannot move to genuine cohesion. This means unresolved authority is one of the primary blockers of team effectiveness in FIRO's model.

Bion's Basic Assumptions

Wilfred Bion's psychodynamic work on groups is particularly rich here. He observed that groups under stress abandon rational task focus and regress into one of three basic assumption states:

• Dependency — the group looks to a leader to solve everything, becoming passive

• Fight-Flight — the group unites around an enemy or threat, real or imagined

• Pairing — the group invests hope in two members producing a solution that saves them

These are unconscious defenses against the anxiety of collective work. The implication is that authority figures attract powerful unconscious projections — groups will idealise, rebel against, or become dependent on leaders in ways that have little to do with the leader's actual behavior. This makes authority in groups inherently emotionally loaded.

Social Identity and Leadership

Tajfel and Turner's Social Identity Theory suggests that the most effective leaders are those who are seen as prototypical of the group — embodying what the group stands for. This is why outsiders imposed as leaders often struggle even when competent, and why leadership transitions are psychologically disruptive — they threaten the group's sense of identity.

How This Fits With Scrum

Scrum's approach to authority is one of its most psychologically interesting and ambitious features — and also one of its most frequently misunderstood.

Scrum Distributes Authority Deliberately

Scrum splits authority three ways:

• The Product Owner has authority over what is built

• The Scrum Master has authority over how the process runs

• The Developers have authority over how the work is done

This is a conscious attempt to avoid concentrating authority in a single leader, which group psychology would predict leads to either dependency (Bion) or resentment and power struggles (FIRO Control phase).

The Scrum Master Is Not a Manager

The Scrum Master role is psychologically unusual. It holds process authority without task authority — the Scrum Master can't tell developers what to build or how to build it, but facilitates the conditions for the team to self-organise. This maps loosely onto what group psychologists call a boundary manager — someone who manages the interface between the team and its environment rather than directing the work itself.

The risk, through Bion's lens, is that teams in the dependency basic assumption will project leadership onto the Scrum Master anyway — looking to them for answers, direction, and rescue — even when the role explicitly resists that. Many Scrum Masters inadvertently collude with this by stepping in too readily, which reinforces dependency rather than building team autonomy.

The Authority Vacuum Problem

Because Scrum deliberately avoids a traditional team leader, it can create an authority vacuum — particularly during the FIRO Control phase when the group is actively trying to negotiate hierarchy. Without a clear authority figure to either accept or push against, this negotiation can become covert and dysfunctional — playing out through passive resistance, cliques, or conflict over technical decisions rather than being worked through openly.

This is a known failure mode in Scrum adoption. Teams that haven't resolved the Control phase disguise authority struggles as technical disagreements.

Hollander in Scrum

Hollander's idiosyncrasy credit model also has interesting implications. In a self-managing team, influence needs to be earned through demonstrated competence and contribution rather than granted by hierarchy. This is psychologically healthy but takes time — and during that period, the team may feel uncomfortably rudderless, especially for members coming from traditionally managed environments.

Summary

Scrum's authority model is psychologically sophisticated — it tries to create the conditions for earned, distributed authority rather than imposed hierarchy. But it underestimates how much anxiety authority vacuums create, and how powerfully groups will fill that vacuum through unconscious means if it isn't addressed explicitly. The Scrum Master role carries enormous psychological weight that the framework doesn't fully acknowledge.

This is also why we see huge issues with Scrum, as the role of Scrum Master has been watered down, and we have seen way too many inexperienced and incompetent people try to fill that role. This inevitably creates dysfunction and an authority vacuum that dysfunctional teams try to fill with group authority, which only elevates the problem and creates a breeding ground for abuse of authority.

How does this fit with the Apollo 13 situation?

Based on the events described, the Apollo 13 mission control team acted as a true team in the psychological sense, and it's a compelling example of why the distinction matters.

The Evidence

Task interdependence was real and immediate — No single controller could diagnose or solve the problem alone. Liebergot needed his backroom support to make sense of the data; other flight controllers were simultaneously reporting abnormalities across different systems, and the crew depended entirely on the ground team's collective judgment. The task required collaboration — it wasn't just encouraged culturally.

Shared goal under pressure — The moment the failure was confirmed, the entire organisation reoriented around a single collective objective: bring the crew home. Individual roles and specialisms remained, but they were subordinated to one outcome that everyone owned jointly.

Mutual accountability was real — The decisions made by any one controller had immediate consequences for the crew and for every other controller. There was no clean separation of individual contributions — if the diagnosis had been wrong, it would have been a collective failure.

Role differentiation with interdependence — Each controller owned a distinct system (power, life support, propulsion, etc.), but those systems were physically and operationally connected. This is close to the psychological ideal — clear roles that genuinely need each other, rather than parallel independent work.

The Interesting Detail

Liebergot's initial instinct was to treat it as an instrumentation problem — essentially an individual diagnosis. It was only through working with his backroom team that the true picture emerged. This is a concrete illustration of what group psychology predicts: collective sense-making produces better decisions than individual judgment, particularly under uncertainty and time pressure. The team didn't just execute a known solution — they constructed understanding together.

Through Bion's Lens

What is also striking is that the team appears to have avoided Bion's dependency trap despite the enormous pressure. Rather than collapsing into passive reliance on a single authority figure, the team distributed the problem-solving across roles while remaining coordinated. This is psychologically difficult to achieve under stress — most groups regress toward dependency or fight-flight when anxiety is high. That they didn't speaks to strong prior development, clear role boundaries, and a culture that had already resolved the FIRO Control phase through training and simulation.

Summary

The Apollo 13 mission control team exhibited every psychological marker of a true team — real interdependence, shared accountability, complementary roles, and collective sense-making under pressure. It is arguably a near-perfect real-world example of what group psychology describes as effective team performance.

Where It Matches Scrum and Distributed Authority

Authority was distributed by domain — Just like Scrum splits authority between Product Owner, Scrum Master, and Developers, Mission Control splits authority by system. Each flight controller had sovereign authority over their domain — Liebergot owned power and fuel cells, others owned propulsion, life support, and so on. Nobody told Liebergot how to interpret his data. This maps closely onto Scrum's principle that developers have authority over how the work is done within their area.

No single heroic leader solved it — The diagnosis emerged collectively. Flight Director Gene Kranz coordinated, but he didn't have the technical answer — the answer came from the distributed expertise of the team working together. This mirrors the Scrum ideal where the Scrum Master facilitates without directing the technical work.

Collective ownership of the outcome — Once the crisis was confirmed, nobody was protecting their individual domain. The shared goal overrode specialisation, which is exactly what Scrum's mutual accountability model tries to produce.

Where It Diverges From Scrum

There was a clear authority figure in Kranz — Unlike Scrum, which deliberately avoids a team leader, mission control had a Flight Director with real authority. Kranz could and did make final calls. This is significant through Bion's lens — having a legitimate, trusted authority figure likely prevented the dependency or fight-flight regression that leaderless groups under stress typically fall into. Scrum's authority vacuum might have been catastrophic in this situation.

The backroom structure was explicitly hierarchical — There were front room controllers and backroom support teams in a clear hierarchy. Liebergot worked with his backroom, but he was the decision-maker for his domain. This is closer to a federated authority model than Scrum's flat self-managing team.

Decisions had to be made fast under life-or-death pressure — Scrum's ceremonies and collaborative decision-making work well when there is time to reflect, inspect, and adapt. Apollo 13 required rapid authoritative calls with incomplete information. The structure supported this by being clear about who had authority in each moment. A pure Scrum model without that clarity might have produced paralysis.

The Most Interesting Insight

Apollo 13 actually resolves one of the tensions we identified in Scrum earlier — the authority vacuum problem. Mission control had distributed authority by domain (like Scrum) but retained coordinating authority in the Flight Director role (unlike Scrum). This meant the Control phase in FIRO terms was already resolved — everyone knew their role, their boundaries, and who had final say when consensus wasn't possible.

Scrum tries to achieve the benefits of distributed authority without the coordinating authority layer, which is psychologically ambitious. Apollo 13 suggests that under high pressure and complexity, some form of coordinating authority — not micromanagement, but a trusted final decision-maker — may be what allows distributed expertise to function without collapsing into confusion.

Summary

Apollo 13 mission control was closer to a federated leadership model than pure Scrum — distributed authority within domains, but with a clear coordinating authority above them. It matched Scrum's spirit of respecting domain expertise and collective ownership, but retained enough formal authority structure to prevent the psychological risks that Scrum's flat model can create under pressure. It could be argued that this hybrid model is actually more psychologically robust than either pure hierarchy or pure self-management.

The conclusion

While I do not see the same evidence for distributed leadership or authority as Matthias, he has picked a very good example where we can see how certain aspects of Scrum and Agile mindsets are applied, but also where it is lacking. Perhaps more importantly, it shows that with some adjustments to address gaps in authority, for example, without descending to bureaucracy, we can get really good collaboration if we have the experience, expertise, and the ingredients required to form teams.

Agile can not be just a mindset. It must have a strong structure and clearly defined authority and processes that allow for decisions that are not bureaucratic and not ad-hoc, even under stress. We must build teams, not groups, and above all, we must have strong expertise combined with high competence where collaboration is required, and trust is earned, not demanded.

Agile can only exist in clarity where the unknown is the exception, not the norm.

Then we can have true Agility.