Scrum Accountabilities, Leadership and Team Dynamics

Introduction

Scrum is not merely a set of meetings or a project schedule. It is a social and organisational system for creating value under conditions of uncertainty. Its effectiveness depends substantially on how people interpret accountability, exercise authority, make decisions, manage disagreement and learn together.

The Scrum Guide identifies three accountabilities within the Scrum Team: Product Owner, Scrum Master and Developers. These are not traditional job descriptions, functional departments or hierarchical ranks. They describe areas of accountability required for an effective product-development system. A Scrum Team is designed to be small, cross-functional and self-managing. Its members decide who does what, when and how, while remaining accountable for delivering a valuable, usable Increment.

This chapter examines these accountabilities, the leadership behaviours that support them, and the team dynamics that enable empirical product development. Particular attention is given to servant leadership, coaching, facilitation, conflict resolution and psychological safety.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish the accountabilities of the Product Owner, Scrum Master and Developers.
2. Explain how self-managing and cross-functional teams operate.
3. Apply servant-leadership, coaching and facilitation techniques.
4. Diagnose and address conflict, power imbalances and ineffective team norms.
5. Design conditions that support psychological safety and responsible experimentation.
6. Evaluate leadership and team practices in a complex organisational case.

Scrum Accountabilities as a System

An accountability is a commitment to achieving a result, not simply a list of activities. For example, the Product Owner is accountable for maximising the value of the product, not merely for writing requirements. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, not merely for scheduling events. Developers are accountable for creating a usable Increment each Sprint, not merely for completing assigned tasks.

The three accountabilities are interdependent:

• The Product Owner provides product direction and value ordering.
• Developers transform selected work into a usable Increment.
• The Scrum Master improves the conditions in which the Product Owner, Developers and wider organisation can work effectively.

Confusion occurs when these accountabilities are replaced by familiar project-management roles. A project manager may attempt to allocate tasks, a business analyst may become the sole author of requirements, or a technical lead may make all design decisions. Such arrangements can reduce ownership and delay feedback. Scrum instead places decision-making close to the people doing the work, while retaining explicit accountability for value, process and product delivery.

Product Owner

The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. This requires product judgement, stakeholder engagement and the ability to make timely trade-offs.

The Product Owner’s responsibilities include:

• developing and communicating the Product Goal;
• creating, ordering and communicating Product Backlog items;
• ensuring that the Product Backlog is transparent, visible and understood; and
• making or enabling decisions about product scope, sequencing and release priorities.

The Product Owner is one person, not a committee. Stakeholders may provide information, constraints and preferences, but accountability cannot be diluted among a group. The Product Owner must reconcile competing interests using evidence about customer outcomes, risk, regulatory obligations, cost and strategic fit.

Product ownership is not equivalent to requirements administration. A Product Owner must understand the problem being solved and the outcomes expected. Useful questions include:

• Which customer or organisational problem is most important now?
• What evidence supports this priority?
• What is the smallest experiment that can reduce uncertainty?
• What opportunity cost follows from selecting this item?
• How will value or learning be recognised?

A Product Owner who changes priorities continually without explaining the product strategy can destabilise the team. Conversely, a Product Owner who refuses to revise priorities despite new evidence undermines empiricism.

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for helping the Scrum Team and organisation understand Scrum theory and practice. The role is one of leadership through service rather than command.

Scrum Master responsibilities include:

• coaching team members in self-management and cross-functionality;
• helping the team focus on creating valuable, usable Increments;
• facilitating Scrum events when useful;
• removing or helping to remove impediments;
• supporting the Product Owner with effective Product Goal and Product Backlog practices; and
• helping the organisation adopt an empirical and iterative approach.

A Scrum Master does not act as a task controller, meeting secretary or compliance police officer. Facilitation is not the same as taking over. The Scrum Master may initially provide structure, but should gradually increase the team’s capacity to facilitate, inspect and adapt independently.

Impediments may be technical, organisational, interpersonal or systemic. Examples include an unavailable test environment, excessive approval layers, unclear product authority, dependency on another department, or a climate in which people fear reporting problems. Treating only visible technical problems while ignoring organisational causes limits the value of the role.

Developers

Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The term includes software engineers, testers, designers, analysts, data specialists and other professionals required to create the product.

Developers are accountable for:

• creating a plan for the Sprint, the Sprint Backlog;
• instilling quality by adhering to a Definition of Done;
• adapting their plan each day toward the Sprint Goal; and
• holding one another accountable as professionals.

Developers decide how selected work will be accomplished. This does not imply that every decision is made by consensus. Consensus may be useful for significant architectural or product decisions, but requiring unanimous agreement for every action can slow delivery. Teams need explicit decision rules, such as consent, advice-seeking, delegated authority or majority decision, depending on the decision’s impact and reversibility.

The Definition of Done is a shared quality standard. It may include reviewed code, automated tests, security checks, updated documentation and deployment readiness. A partially completed feature is not a usable Increment merely because its coding task is finished.

Self-Managing and Cross-Functional Teams

A self-managing team decides internally who does what, when and how. Self-management is not an absence of leadership, standards or accountability. It is a shift from external task allocation toward collective responsibility and local decision-making.

Cross-functionality means the team collectively possesses the skills necessary to create value in each Sprint. It does not require every individual to possess every skill. A team may contain specialists, but it should avoid becoming a sequence of disconnected functional hand-offs.

Conditions for Self-Management

Self-management is supported by five conditions:

1. A clear purpose. The Product Goal and Sprint Goal provide direction.
2. Decision authority. The team must control relevant implementation decisions.
3. Transparent information. Work status, risks, quality and constraints must be visible.
4. Capability and learning. Members need opportunities to broaden skills and obtain help.
5. Psychological safety. People must be able to raise concerns without humiliation or retaliation.

Self-management can fail in two opposite ways. In pseudo-autonomy, the team is held accountable for results but denied authority or resources. In unstructured autonomy, no one knows who decides, quality standards are unclear and conflict is avoided. Effective Scrum combines autonomy with purpose, transparency, inspection and adaptation.

Team Development and Norms

Teams develop through interaction rather than simply through the passage of time. Tuckman’s commonly used model describes forming, storming, norming and performing. Although real teams may move back and forth among these states, the model helps leaders recognise that disagreement and uncertainty are normal during development.

Team norms should make expected behaviour explicit. Examples include:

• challenge ideas rather than people;
• surface risks early;
• seek evidence before escalating claims;
• ask for help before a delay becomes invisible;
• rotate facilitation responsibilities; and
• treat the Definition of Done as a collective commitment.

Norms become credible when leaders model them and when the team discusses breaches openly. A poster listing values is not a substitute for observable behaviour.

Servant Leadership in Scrum

Servant leadership, associated with Robert Greenleaf’s work, emphasises the growth, autonomy and well-being of those being served. In Scrum, servant leadership does not mean passivity or avoidance of difficult decisions. It means using authority to strengthen the team’s ability to create value rather than to preserve the leader’s control.

A Scrum-oriented servant leader:

• clarifies purpose and constraints;
• protects the team from harmful interference;
• makes systemic impediments visible;
• develops capability rather than dependency;
• encourages direct communication;
• asks questions before giving solutions; and
• remains accountable for organisational improvement.

A practical test is substitution: if the leader is absent for a week, does the team make sound decisions, or does work stop while awaiting instructions? The objective is not to make the leader indispensable but to make the team capable.

Servant leadership must also be critically examined. If interpreted as unlimited accommodation, it can allow poor performance or harmful behaviour to continue. Service includes setting boundaries, addressing misconduct, enforcing quality expectations and making unpopular organisational issues visible.

Coaching and Facilitation

Coaching

Coaching helps individuals or teams improve their own understanding and capacity. It differs from mentoring, teaching, consulting and managing, although all may be appropriate at different times.

Useful coaching questions include:

• What outcome are you trying to achieve?
• What assumptions are influencing the decision?
• What options have you considered?
• What evidence would change your view?
• What is the next responsible experiment?

Coaching should be adapted to competence and context. A novice facing an urgent production failure may need direct instruction first and reflection later. A highly capable team may be harmed by excessive intervention.

Facilitation

Facilitation designs a process that enables a group to think and decide effectively. It includes clarifying the purpose, managing participation, making information visible, handling time and recording decisions.

A facilitator should distinguish divergent and convergent activity. During divergence, the group generates perspectives and options. During convergence, it evaluates alternatives against explicit criteria. Premature evaluation suppresses useful information; endless divergence prevents commitment.

Techniques include silent writing before discussion, round-robin participation, affinity mapping, dot voting, fist-to-five confidence checks and explicit decision logs. These tools are not substitutes for judgement. For example, voting may reveal preferences but does not necessarily produce the best technical or ethical decision.

Conflict Resolution

Conflict is not automatically dysfunctional. Task conflict can expose assumptions and improve decisions. Relationship conflict, characterised by personal hostility or contempt, is more likely to damage collaboration. Process conflict concerns how work, authority or responsibilities are organised.

A useful conflict approach has five stages:

1. Name the issue neutrally. Describe observable behaviour and impact.
2. Separate positions from interests. Ask what each party is trying to protect or achieve.
3. Create a shared fact base. Distinguish evidence from interpretation.
4. Generate and evaluate options. Use agreed criteria such as value, risk, quality and reversibility.
5. Commit and inspect. Record the decision, owner and review point.

For example, “The design discussion has continued for three meetings without a decision” is more constructive than “The architects are indecisive.” The first statement identifies an observable process problem; the second assigns a negative identity.

Conflict resolution must account for power. A junior employee may appear to agree because disagreement feels unsafe. A facilitator should use private check-ins, anonymous input or structured turn-taking when status differences distort participation. Serious harassment, discrimination or retaliation should not be treated as ordinary team conflict; it requires organisational safeguarding and formal procedures.

Psychological Safety

Psychological safety, associated especially with Amy Edmondson’s research, is the shared belief that the team is safe for interpersonal risk-taking. It does not mean that all ideas are accepted, performance standards are relaxed or people are protected from accountability.

A psychologically safe team can say:

• “I do not understand this requirement.”
• “I made an error.”
• “The Sprint Goal is at risk.”
• “This design has a security concern.”
• “I disagree with the proposed decision.”

Leaders build safety through three behaviours:

1. Set the stage: explain uncertainty, purpose and the value of candour.
2. Invite participation: ask specific questions and create equitable opportunities to speak.
3. Respond productively: thank people for raising issues, investigate facts and avoid humiliation.

Safety and accountability are complementary. A team may be safe to speak but still fail if it does not act on information. Conversely, a team may meet targets temporarily through fear while accumulating hidden defects, burnout and turnover.

Measuring Team Effectiveness

No single metric captures team effectiveness. Teams should use a balanced set of indicators, interpreted in context.

Velocity is a planning observation, not a productivity score. Comparing velocity across teams encourages estimation inflation and undermines trust. Similarly, counting completed tasks can reward fragmentation rather than value. Metrics should support learning and conversation, not surveillance.

Illustrative Case: The Atlas Claims Platform

Background

Atlas is a fictional insurance company developing a claims platform. The Scrum Team includes six Developers, a Product Owner from operations and a Scrum Master shared with another team. The organisation has imposed a quarterly feature target and requires weekly reports showing individual task completion.

Problem

After three Sprints, the team meets its apparent task targets but releases no usable customer capability. Testers are involved late, technical debt is increasing and Developers avoid reporting risks. The Product Owner changes priorities during Sprints after receiving requests from senior managers. A senior engineer makes most design decisions, while two less experienced Developers remain silent.

Analysis

The problem is systemic rather than a simple performance deficit. Individual task reporting encourages local optimisation. The Product Owner lacks protected decision authority. The team is nominally cross-functional but operates through functional hand-offs. Psychological safety is weak, and the Scrum Master is acting as a status-report coordinator rather than an organisational coach.

Approach

The Scrum Master facilitates a reset:

• The Product Owner and stakeholders define a Product Goal and agree on a decision-making boundary.
• The team revises its Definition of Done to include integrated testing, security review and deployment readiness.
• Sprint Goals replace lists of unrelated tasks as the primary focus.
• Daily Scrum discussion centres on progress toward the Sprint Goal and impediments.
• Developers establish pairing and review practices to reduce dependence on the senior engineer.
• Individual task reports are replaced with transparent Sprint and product evidence.
• Retrospectives use anonymous input initially, followed by explicit action owners and review dates.
• The Product Owner introduces a policy that urgent requests enter through a visible ordering decision rather than informal interruption.

Outcome

After several Sprints, the team delivers smaller but usable Increments. Risks are raised earlier, and design knowledge is distributed. Delivery speed initially appears lower because hidden rework becomes visible. Later, fewer defects and interruptions improve predictability. The organisation also learns that its reporting policy had been producing misleading evidence.

Learning Points

1. A team cannot become self-managing without meaningful decision authority.
2. Quality must be built into the Increment, not inspected only at the end.
3. Psychological safety is strengthened by leader responses to bad news.
4. Product accountability requires a clear boundary against uncontrolled stakeholder interruption.
5. Improving transparency can make performance appear worse before the system improves.

Governance, Ethics and Contemporary Issues

Scrum teams operate within legal, regulatory and ethical constraints. Self-management does not permit bypassing privacy law, accessibility requirements, information-security controls, financial regulation or professional standards. The Product Owner must include regulatory and ethical work in product ordering; Developers must implement relevant controls; and the Scrum Master should expose organisational pressure that encourages unsafe shortcuts.

AI-assisted development introduces additional concerns. Generative tools may accelerate coding, analysis or documentation, but teams remain accountable for the Increment. They must consider intellectual-property provenance, confidential data exposure, model bias, insecure generated code, hallucinated requirements and the explainability of automated decisions. “The tool produced it” is not a defence against defective or harmful outcomes.

Distributed and hybrid teams require deliberate communication design. Time-zone differences, unequal access to informal conversations and cultural communication patterns can create hidden exclusion. Rotating meeting times, documenting decisions, using asynchronous refinement and checking participation can improve inclusion.

Best-Practice Principles

• Keep accountabilities clear while allowing collaboration.
• Give the Product Owner genuine authority over product ordering.
• Make the Definition of Done explicit and technically credible.
• Protect Developers from task-level command-and-control.
• Treat impediments as possible symptoms of system design.
• Use coaching to build capability, not dependency.
• Facilitate disagreement rather than suppressing it.
• Respond to bad news with curiosity before judgement.
• Measure outcomes, quality, flow and sustainability together.
• Review team practices empirically and adapt them.

Chapter Summary

Scrum depends on three complementary accountabilities. The Product Owner maximises product value through product direction, stakeholder alignment and Product Backlog ordering. The Scrum Master establishes Scrum, coaches the team and organisation, facilitates useful interaction and addresses systemic impediments. Developers create a usable Increment, plan their work, maintain quality and hold one another accountable.

Self-managing, cross-functional teams require purpose, authority, transparency, capability and psychological safety. Servant leadership supports autonomy without abandoning standards. Coaching develops judgement; facilitation improves group decisions; and constructive conflict resolution converts disagreement into learning. Psychological safety enables people to surface uncertainty and failure, but it must be combined with accountability and action.

Effective Scrum leadership is therefore less about controlling activity than about designing conditions for value creation, learning and responsible decision-making. Teams and leaders should evaluate their practices through evidence about outcomes, quality, flow, sustainability and learning rather than through simplistic measures such as individual utilisation or velocity comparisons.

Key Terms

Accountability: Commitment to achieving a result and being answerable for it.

Product Owner: Scrum accountability responsible for maximising product value.

Scrum Master: Scrum accountability responsible for establishing Scrum and enabling effectiveness.

Developers: Scrum Team members accountable for creating a usable Increment.

Product Goal: The longer-term objective for the Scrum Team.

Sprint Goal: The single objective for a Sprint.

Product Backlog: Ordered, evolving list of work needed to improve the product.

Definition of Done: Formal quality state required for work to be considered part of a usable Increment.

Self-management: The team’s ability to decide who does what, when and how.

Cross-functionality: Collective possession of the skills needed to create value.

Servant leadership: Leadership that strengthens the growth, autonomy and effectiveness of others.

Coaching: A process that develops insight and self-directed capability.

Facilitation: Designing and guiding interaction so a group can think and decide effectively.

Psychological safety: Shared belief that interpersonal risk-taking is safe within the team.

Task conflict: Disagreement about ideas, evidence or solutions.

Relationship conflict: Interpersonal hostility or antagonism.

Impediment: A condition that obstructs progress or reduces team effectiveness.

Empiricism: Decision-making based on transparency, inspection and adaptation.

Team norm: An explicit or implicit expectation governing team behaviour.

Review Questions

Short Answer Questions

1. What is the central accountability of the Product Owner?
2. How does self-management differ from the absence of leadership?
3. What is the purpose of a Definition of Done?
4. Define psychological safety.
5. Why is velocity unsuitable as a direct productivity comparison between teams?

Long Answer Questions

1. Compare and contrast the accountabilities of the Product Owner, Scrum Master and Developers.
2. Explain how servant leadership can support autonomy while preserving accountability.
3. Discuss the conditions required for a Scrum Team to become genuinely cross-functional and self-managing.
4. Analyse the relationship between psychological safety, conflict and product quality.
5. Evaluate the strengths and limitations of using team metrics to assess Scrum effectiveness.

Analytical / Application Questions

1. A Product Owner repeatedly changes priorities during a Sprint because of executive requests. Diagnose the systemic causes and propose an intervention.
2. A team’s senior engineer makes all technical decisions while other members remain silent. Apply coaching, facilitation and psychological-safety practices to address the situation.
3. A team delivers many completed tasks but few usable Increments. Analyse which accountability and quality practices may be failing, and design a recovery plan.

Multiple Choice Questions with Answers

Question 1

Which accountability is primarily responsible for maximising product value?

A. Product Owner

B. Scrum Master

C. Developers

D. Stakeholder committee

Correct Answer: A. Product Owner

Question 2

Which activity is most consistent with the Scrum Master accountability?

A. Assigning daily tasks to Developers

B. Establishing Scrum and helping remove impediments

C. Approving every technical design

D. Writing all Product Backlog items alone

Correct Answer: B. Establishing Scrum and helping remove impediments

Question 3

What does self-management mean in Scrum?

A. Working without goals or standards

B. Allowing stakeholders to assign tasks directly

C. Deciding internally who does what, when and how

D. Having no accountable role

Correct Answer: C. Deciding internally who does what, when and how

Question 4

Which statement best describes cross-functionality?

A. Every person must master every skill

B. The team collectively has the skills needed to create value

C. Work is handed between isolated departments

D. Only Developers need product knowledge

Correct Answer: B. The team collectively has the skills needed to create value

Question 5

What is the primary purpose of the Definition of Done?

A. To rank individual performance

B. To specify the quality state required for a usable Increment

C. To estimate Product Backlog size

D. To replace the Sprint Goal

Correct Answer: B. To specify the quality state required for a usable Increment

Question 6

Which behaviour most directly supports psychological safety?

A. Punishing people who report risks

B. Avoiding disagreement in meetings

C. Thanking people for raising concerns and investigating them

D. Allowing only senior members to speak

Correct Answer: C. Thanking people for raising concerns and investigating them

Question 7

Which response is an example of constructive conflict framing?

A. The architects are indecisive

B. You always block progress

C. The design discussion has continued for three meetings without a decision

D. Nobody here understands the problem

Correct Answer: C. The design discussion has continued for three meetings without a decision

Question 8

Why should velocity generally not be used to compare teams?

A. Velocity has no relationship to any planning observation

B. Comparison encourages estimation inflation and undermines trust

C. Velocity is measured only by the Product Owner

D. Velocity can be calculated only once per year

Correct Answer: B. Comparison encourages estimation inflation and undermines trust

Question 9

Which coaching question best encourages reflection?

A. Why did you make that mistake?

B. What evidence would change your view?

C. Who should be blamed?

D. Would you like me to decide for you?

Correct Answer: B. What evidence would change your view?

Question 10

In the Atlas case, what was a major systemic problem?

A. The team had too many Product Goals

B. Individual task reporting encouraged local optimisation

C. The team used no technology

D. The Scrum Master prevented all retrospectives

Correct Answer: B. Individual task reporting encouraged local optimisation