Scrum Framework Explained: The Complete Guide (Part 2)
Scrum Roles: Building High-Performing Scrum Teams
"People build products—not processes."
Many Scrum implementations fail because organizations focus heavily on Scrum ceremonies while overlooking the people responsible for delivering customer value.
The Scrum Team is intentionally small, collaborative, and self-managing. Unlike traditional project structures where work passes through managers, analysts, developers, testers, and multiple approval layers, Scrum empowers one cross-functional team to own product delivery from idea to customer value.
In this guide, you'll learn how each Scrum accountability contributes to product success, how these roles collaborate, common anti-patterns to avoid, and how the PACE Framework can help build high-performing Scrum teams.
The Scrum Team
A Scrum Team consists of three accountabilities that work together to deliver valuable products through short, iterative development cycles called Sprints.
- Product Owner
- Scrum Master
- Developers
Unlike traditional organizational structures where responsibilities are divided across separate departments, Scrum brings together professionals with different expertise into a single team that owns product delivery from start to finish.
Every Sprint should produce a usable product increment that delivers measurable customer value.
Why Scrum Teams Are Different
Traditional project management often relies on handoffs between specialized teams. Business analysts gather requirements, developers write code, testers verify functionality, managers coordinate work, and steering committees approve releases.
This approach frequently creates delays, communication gaps, duplicated effort, and slow customer feedback.
Scrum replaces these handoffs with continuous collaboration.
Instead of asking:
"Whose responsibility is this?"
Scrum Teams ask:
"What is the best way for us to deliver value together?"
Characteristics of Effective Scrum Teams
According to the Scrum Guide, Scrum Teams should be:
- Cross-functional — possessing all skills necessary to deliver working product increments without depending heavily on outside teams.
- Self-managing — deciding internally who performs work, how work is completed, and how responsibilities are shared.
- Small enough to remain agile — typically ten or fewer members to encourage rapid communication and decision-making.
- Focused on one Product Goal — maintaining a shared vision rather than competing priorities.
Successful Scrum Teams also display several cultural characteristics.
- Shared ownership
- Open communication
- Continuous learning
- Psychological safety
- Mutual respect
- Customer-centric thinking
- Rapid feedback loops
- Continuous experimentation
High-performing Scrum Teams rarely succeed because individual members are exceptional. They succeed because collaboration enables the entire team to perform beyond what individuals could accomplish alone.
Cross-Functional Teams Explained
A cross-functional team possesses all the capabilities required to deliver customer value without excessive dependence on external departments.
Depending on the product, Developers may include:
- Software Engineers
- UX Designers
- QA Engineers
- Data Engineers
- Business Analysts
- Security Specialists
- DevOps Engineers
- Cloud Architects
The goal is not for everyone to possess identical skills but for the team collectively to have everything required to complete valuable work.
Why Self-Management Matters
Self-management does not mean working without leadership.
Instead, it means the Scrum Team decides how work is performed while remaining accountable for outcomes.
Research consistently shows that autonomous teams demonstrate:
- Higher engagement
- Greater innovation
- Faster decision-making
- Improved ownership
- Higher job satisfaction
The Product Owner determines what should be built.
Developers determine how it will be built.
The Scrum Master helps the team continuously improve how they work together.
The Product Owner
Who Is the Product Owner?
The Product Owner is accountable for maximizing the value delivered by the Scrum Team.
Many organizations mistakenly view the Product Owner as someone who simply writes user stories or manages the Product Backlog.
In reality, the Product Owner is a strategic leader responsible for ensuring the team invests its time in solving the most valuable customer problems.
Think of the Product Owner as the bridge connecting:
- Customer needs
- Business objectives
- Market opportunities
- Technical capabilities
Every prioritization decision made by the Product Owner influences product success.
Suppose stakeholders request ten new features.
The Product Owner evaluates customer impact, business value, technical effort, competitive advantage, and strategic alignment before deciding which features deserve development first.
The Product Owner's greatest strength is often the ability to say "No" to low-value work.
Primary Responsibilities
The Product Owner is responsible for maximizing return on development investment.
- Creating and communicating the Product Goal.
- Managing the Product Backlog.
- Prioritizing work based on business value.
- Collaborating with customers and stakeholders.
- Clarifying product requirements.
- Accepting completed work.
- Making product decisions.
- Balancing customer needs with organizational objectives.
Every backlog item should contribute toward delivering meaningful customer value.
Busy backlogs do not necessarily create successful products.
Focused backlogs do.
Skills of an Effective Product Owner
Exceptional Product Owners combine business strategy, customer empathy, communication, and decision-making skills to maximize product value. While technical knowledge can be helpful, the most successful Product Owners focus on understanding customer problems and guiding the Scrum Team toward meaningful outcomes.
Rather than acting as a feature manager, a Product Owner serves as a product strategist who balances customer expectations, organizational goals, market opportunities, and technical constraints.
A Product Owner doesn't need to know how to build every feature—but they must understand why it should be built and how it contributes to customer value.
1. Strategic Thinking
Strategic thinking enables Product Owners to look beyond today's backlog and focus on the product's long-term direction.
Instead of asking, "What feature should we build next?", strategic Product Owners ask:
- What customer problem are we solving?
- How does this support the Product Goal?
- Will this increase business value?
- Does this differentiate us from competitors?
- Is this the best investment of our Sprint capacity?
Strong strategic thinking ensures every Sprint contributes toward a larger product vision rather than becoming a collection of unrelated features.
2. Customer Empathy
Customer empathy is the ability to understand user needs, frustrations, motivations, and expectations.
Outstanding Product Owners spend time talking with customers instead of relying only on stakeholder opinions.
They collect information through:
- Customer interviews
- User observation
- Surveys
- Support tickets
- Usage analytics
- Customer feedback sessions
- A/B testing
Empathy helps Product Owners avoid building features customers never requested or rarely use.
A customer may ask for a "Download PDF" button. After deeper conversations, the Product Owner discovers the real need is offline access. A mobile-friendly offline mode could solve the problem more effectively than generating PDFs.
3. Decision-Making
Product Owners make hundreds of prioritization decisions throughout a product's lifecycle.
Waiting for perfect information often delays value delivery. Instead, experienced Product Owners make informed decisions using available evidence while remaining willing to adapt as new information emerges.
Effective decision-making involves balancing:
- Customer value
- Business impact
- Development effort
- Technical risk
- Market timing
- Regulatory requirements
Decisiveness keeps teams moving forward and prevents backlog stagnation.
4. Communication
A Product Owner spends a significant portion of their time communicating with developers, stakeholders, customers, executives, and business teams.
Clear communication ensures everyone understands:
- The Product Vision
- The Product Goal
- Sprint priorities
- Expected outcomes
- Business rationale
Good communication reduces misunderstandings, builds trust, and helps the Scrum Team stay aligned.
5. Negotiation
Competing priorities are common in every organization. Marketing wants new features, Sales requests customer-specific functionality, Support needs bug fixes, and Engineering seeks time to reduce technical debt.
The Product Owner balances these competing demands while protecting the team's focus.
Successful negotiation is not about pleasing everyone—it is about making transparent decisions based on value.
6. Analytical Thinking
Modern Product Owners rely on evidence instead of assumptions.
Useful sources of information include:
- Customer analytics
- Conversion rates
- User engagement metrics
- Customer retention data
- Net Promoter Score (NPS)
- Revenue trends
- Product experiments
By analyzing data, Product Owners can continuously refine priorities and validate product decisions.
Common Product Owner Anti-Patterns
Even experienced Product Owners can unintentionally reduce team effectiveness. Recognizing these anti-patterns helps organizations build healthier Scrum Teams.
1. Acting as a Requirements Secretary
Some Product Owners simply document stakeholder requests without evaluating their value.
This turns the Product Backlog into a task list instead of a strategic roadmap.
Better Practice: Evaluate each request based on customer value, business objectives, and the Product Goal.
2. Saying "Yes" to Everything
Accepting every feature request creates an overloaded backlog, frequent context switching, and slower delivery.
High-performing Product Owners understand that every "Yes" also means saying "No" to something else.
An overloaded Product Backlog often indicates weak prioritization—not increased productivity.
3. Constantly Changing Sprint Priorities
Frequent priority changes during an active Sprint reduce focus and disrupt the team's ability to achieve the Sprint Goal.
Although business conditions sometimes change, unnecessary interruptions should be avoided.
Stable Sprints improve predictability and team confidence.
4. Writing Technical Solutions
The Product Owner defines what needs to be achieved—not how developers should implement the solution.
Specifying technical architecture or implementation details reduces developer creativity and ownership.
5. Delegating Backlog Ownership
Some organizations assign backlog management to business analysts or project coordinators.
While others may help refine backlog items, accountability always remains with the Product Owner.
6. Limited Customer Interaction
Relying solely on internal stakeholders creates products based on assumptions instead of customer evidence.
Regular conversations with users help validate priorities and reduce the risk of building low-value features.
7. Prioritizing Based on Hierarchy
The highest-paid person's opinion (often called the HiPPO effect) should not automatically determine backlog priorities.
Instead, prioritization should consider:
- Customer value
- Business impact
- Strategic alignment
- Technical feasibility
- Evidence from data and feedback
The Psychology of Great Product Owners
Product management is as much about understanding people as it is about managing products. Cognitive biases and human behavior influence decision-making every day.
Loss Aversion
People tend to fear losses more than they value equivalent gains. Stakeholders may resist removing outdated features because eliminating functionality feels like a loss, even when usage data suggests otherwise.
Effective Product Owners focus conversations on customer outcomes rather than feature ownership.
Confirmation Bias
Teams naturally seek information that supports their existing beliefs.
To counter this bias, Product Owners encourage experimentation, usability testing, and hypothesis-driven development before making large investments.
Decision Fatigue
Making many complex decisions throughout the day reduces judgment quality over time.
Experienced Product Owners establish clear prioritization principles, product strategies, and evaluation criteria to simplify routine decisions.
Building Trust
Trust is one of the Product Owner's most valuable assets.
Stakeholders trust Product Owners who make transparent decisions supported by evidence, while Scrum Teams trust Product Owners who provide clear priorities and avoid unnecessary interruptions.
Strong trust improves collaboration, speeds decision-making, and creates healthier working relationships.
The Product Owner is not simply a backlog manager. They are a value maximizer, strategic decision-maker, customer advocate, and communicator who ensures the Scrum Team focuses on solving the right problems at the right time.
The Scrum Master
Who Is the Scrum Master?
The Scrum Master is accountable for establishing Scrum as described in the Scrum Guide. While the title may suggest authority over the team, the Scrum Master is not a project manager, team lead, or supervisor.
Instead, the Scrum Master is a servant leader, coach, facilitator, mentor, and change agent who helps the Scrum Team and the wider organization understand and apply Scrum effectively.
The primary objective of a Scrum Master is to create an environment where the Scrum Team can continuously improve, deliver value consistently, and become increasingly self-managing.
A great Scrum Master doesn't make the team dependent on them. They help the team become capable of solving problems independently.
Why the Scrum Master Role Exists
Scrum introduces new ways of working that often challenge traditional management practices. Teams transitioning from command-and-control environments may struggle with self-management, collaboration, and continuous improvement.
The Scrum Master helps bridge this gap by coaching individuals, facilitating collaboration, and removing obstacles that slow the team's progress.
Without effective Scrum Masters, organizations often revert to traditional project management practices while calling them "Agile."
Core Responsibilities of the Scrum Master
The Scrum Guide groups Scrum Master responsibilities into three primary areas:
- Serving the Scrum Team
- Serving the Product Owner
- Serving the Organization
1. Serving the Scrum Team
The Scrum Master helps Developers and the Product Owner work effectively together by promoting collaboration, continuous learning, and self-management.
Key responsibilities include:
- Teaching Scrum principles and values
- Facilitating Scrum events when needed
- Helping the team remove impediments
- Encouraging self-management
- Supporting healthy communication
- Improving team collaboration
- Promoting engineering excellence
- Encouraging continuous improvement
Rather than solving every problem personally, effective Scrum Masters teach teams how to solve problems themselves.
2. Serving the Product Owner
The Scrum Master supports the Product Owner in maximizing product value by improving product management practices and stakeholder collaboration.
Typical activities include:
- Helping define and communicate the Product Goal
- Improving Product Backlog management
- Facilitating backlog refinement sessions
- Improving stakeholder communication
- Supporting evidence-based decision making
- Coaching effective prioritization techniques
The Scrum Master never makes product decisions for the Product Owner but instead improves the Product Owner's ability to make informed decisions.
3. Serving the Organization
Many organizational problems affecting Scrum Teams exist outside the team's control.
The Scrum Master works with leaders, managers, and departments to improve organizational agility.
Examples include:
- Reducing unnecessary approval processes
- Improving cross-team collaboration
- Coaching Agile leadership
- Supporting organizational change
- Promoting empirical decision-making
- Removing systemic impediments
This organizational coaching often creates more long-term value than solving day-to-day team issues.
Essential Skills Every Scrum Master Should Develop
Exceptional Scrum Masters combine technical understanding with strong interpersonal and leadership skills.
1. Coaching
Coaching focuses on helping people discover their own solutions instead of providing ready-made answers.
Powerful coaching questions include:
- What options have you considered?
- What evidence supports that assumption?
- What experiment could help validate this idea?
- What is preventing progress?
- What would success look like?
Coaching develops long-term capability rather than short-term dependency.
2. Active Listening
Listening is one of the Scrum Master's most valuable skills.
Effective listening involves:
- Giving full attention
- Clarifying assumptions
- Observing non-verbal communication
- Avoiding interruptions
- Reflecting key points back to the speaker
Many conflicts are resolved simply because people feel genuinely heard.
3. Facilitation
Facilitation helps groups collaborate effectively while ensuring every voice is heard.
Scrum Masters facilitate:
- Sprint Planning
- Daily Scrums (when necessary)
- Sprint Reviews
- Sprint Retrospectives
- Backlog refinement sessions
- Problem-solving workshops
Good facilitation encourages participation without controlling outcomes.
4. Conflict Resolution
Healthy disagreement often leads to better decisions.
The Scrum Master's role is not to eliminate conflict but to ensure it remains constructive.
Useful approaches include:
- Encouraging respectful dialogue
- Identifying root causes
- Focusing on shared goals
- Separating people from problems
- Supporting collaborative solutions
5. Systems Thinking
Many team problems are symptoms of larger organizational issues.
Systems thinking helps Scrum Masters identify patterns instead of treating isolated events.
For example, repeated missed Sprint Goals may result from:
- Frequent priority changes
- Weak backlog refinement
- Poor stakeholder alignment
- Technical debt
- Organizational bottlenecks
Understanding the system enables more effective improvements.
6. Emotional Intelligence
Scrum Masters work with people under pressure, making emotional intelligence essential.
Key competencies include:
- Self-awareness
- Self-regulation
- Empathy
- Relationship management
- Social awareness
Emotionally intelligent Scrum Masters build trust and psychological safety within the team.
7. Continuous Learning
Agile practices continue to evolve.
Successful Scrum Masters regularly expand their knowledge through books, conferences, certifications, experimentation, mentoring, and community involvement.
Spend time learning not only Scrum but also psychology, systems thinking, facilitation, leadership, negotiation, and organizational change management.
Common Scrum Master Anti-Patterns
Organizations frequently misunderstand the Scrum Master role, leading to behaviors that reduce team effectiveness.
1. Acting as a Project Manager
Assigning tasks, tracking individual performance, approving work, and directing daily activities are project management behaviors—not Scrum Master responsibilities.
Scrum Masters create conditions for success rather than directing execution.
2. Running the Daily Scrum as a Status Meeting
The Daily Scrum belongs to the Developers.
When Scrum Masters ask each person for status updates, the meeting shifts from team planning to management reporting.
The Daily Scrum should focus on adapting the Sprint Plan—not reporting progress.
3. Solving Every Problem Personally
Helping the team does not mean doing everything for them.
Constant intervention creates dependency and limits team growth.
Instead, Scrum Masters should coach teams toward independent problem-solving.
4. Becoming the Process Police
Strictly enforcing Scrum rules without understanding their purpose creates frustration.
Scrum exists to improve value delivery—not to maximize process compliance.
5. Shielding the Team from Every Stakeholder
Healthy stakeholder collaboration improves products.
The Scrum Master should facilitate productive interactions rather than isolating the team.
6. Measuring Success Only by Velocity
Velocity is a planning metric—not a performance metric.
High velocity does not automatically mean high customer value.
More meaningful indicators include:
- Customer satisfaction
- Product quality
- Business outcomes
- Cycle time
- Defect rates
- Team health
The Psychology of Servant Leadership
Servant leadership places the needs of the team before personal authority. Rather than directing people, servant leaders create environments where individuals can perform at their best.
Behavioral science has consistently linked servant leadership with improved employee engagement, innovation, trust, collaboration, and organizational commitment.
Characteristics of Servant Leaders
- Listening before speaking
- Empathy
- Humility
- Stewardship
- Coaching mindset
- Long-term people development
- Empowerment
Instead of asking:
"How do I get people to follow my instructions?"
Servant leaders ask:
"What obstacles can I remove so this team succeeds?"
The most effective Scrum Masters become almost invisible over time because the team has learned to collaborate, adapt, and improve independently.
Quick Comparison: Project Manager vs Scrum Master
| Project Manager | Scrum Master |
|---|---|
| Directs project execution | Coaches self-managing teams |
| Assigns tasks | Encourages team ownership |
| Measures schedule compliance | Focuses on value delivery and improvement |
| Controls project activities | Facilitates collaboration |
| Reports project status | Improves team capability |
Key Takeaways
- The Scrum Master is a coach, facilitator, mentor, and servant leader—not a project manager.
- Success comes from enabling teams, not controlling them.
- Strong coaching, facilitation, and emotional intelligence are essential competencies.
- Removing systemic obstacles often creates greater impact than solving daily issues.
- Servant leadership builds trust, collaboration, innovation, and long-term team performance.
Developers
Who Are the Developers?
In Scrum, the term Developers refers to every professional responsible for creating a usable product Increment during a Sprint. The title describes an accountability, not a specific job title.
This is one of the most misunderstood aspects of Scrum. Many people assume that Developers are only software programmers. In reality, anyone directly involved in building, testing, validating, designing, securing, documenting, or deploying the product Increment is considered a Developer within the Scrum Team.
Depending on the product and industry, Developers may include:
- Software Engineers
- Quality Assurance (QA) Engineers
- UX/UI Designers
- DevOps Engineers
- Cloud Engineers
- Security Specialists
- Database Engineers
- Business Analysts
- Data Scientists
- Machine Learning Engineers
- Technical Writers
- System Architects
In Scrum, "Developer" means everyone who contributes directly to creating a Done Increment. It does not describe seniority, programming language, or department.
Responsibilities of Developers
Developers are collectively accountable for delivering a valuable product Increment that meets the team's Definition of Done.
Unlike traditional organizations where work is assigned by managers, Scrum Developers determine how work will be completed.
Their responsibilities include:
- Creating the Sprint Plan
- Selecting Product Backlog Items during Sprint Planning
- Breaking work into manageable tasks
- Estimating effort when appropriate
- Designing technical solutions
- Writing and testing code
- Maintaining quality standards
- Reviewing each other's work
- Collaborating daily
- Improving engineering practices
- Delivering a usable Increment every Sprint
The Scrum Guide intentionally avoids assigning work to individual Developers. Instead, accountability belongs to the team as a whole.
Ownership Over Individual Heroics
Traditional organizations often reward individual performance. Scrum encourages collective ownership.
Instead of asking:
"Who built this feature?"
Healthy Scrum Teams ask:
"How did our team deliver value together?"
Collective ownership encourages:
- Knowledge sharing
- Peer reviews
- Cross-functional learning
- Higher quality
- Reduced delivery risk
When knowledge is shared across the team, work continues smoothly even if individual members are unavailable.
Characteristics of High-Performing Developers
Technical expertise alone does not create outstanding Scrum Developers. High-performing teams combine technical excellence with collaboration, adaptability, and customer awareness.
1. Ownership
Developers take responsibility for outcomes rather than simply completing assigned tasks.
They ask:
- Does this solve the customer's problem?
- Is the quality sufficient?
- Can we improve this solution?
2. Accountability
Accountability means honoring Sprint commitments, maintaining quality standards, communicating risks early, and supporting teammates whenever necessary.
3. Collaboration
Successful Developers work across disciplines rather than remaining isolated within specialized roles.
Examples include:
- Pair programming
- Peer code reviews
- Collaborative testing
- Joint design sessions
- Shared debugging
4. Curiosity
Technology changes rapidly. Developers who continuously learn new tools, techniques, and engineering practices adapt more effectively to changing customer needs.
5. Adaptability
Scrum embraces change. Developers remain flexible when priorities evolve, customer feedback reveals new opportunities, or experiments suggest better solutions.
6. Technical Excellence
Delivering quickly should never come at the expense of quality.
Professional Developers continuously improve engineering practices such as:
- Automated testing
- Continuous Integration
- Continuous Delivery (CI/CD)
- Refactoring
- Secure coding
- Code reviews
- Performance optimization
7. Customer Awareness
Great Developers understand that writing code is not the final objective.
The real goal is improving customer outcomes.
Every line of code should contribute toward solving a real customer problem—not simply completing a backlog item.
Developer Anti-Patterns
Several behaviors reduce team effectiveness and slow value delivery.
Waiting for Detailed Instructions
Scrum encourages initiative and self-management rather than dependency on managers.
Working in Functional Silos
When Developers refuse to help outside their specialty, bottlenecks emerge and Sprint Goals become harder to achieve.
Avoiding Testing Responsibilities
Quality belongs to everyone—not only QA Engineers.
Ignoring Technical Debt
Continuously delaying refactoring eventually slows future development and increases maintenance costs.
Optimizing Individual Performance
High individual productivity means little if the overall Sprint Goal is not achieved.
Knowledge Hoarding
Teams become vulnerable when only one person understands a critical component.
Knowledge sharing increases resilience and improves long-term delivery capability.
Collaboration Between Scrum Roles
Scrum succeeds because three accountabilities complement one another.
Each role answers a different question while working toward the same Product Goal.
| Accountability | Primary Focus | Key Question |
|---|---|---|
| Product Owner | Product Value | Are we building the right product? |
| Scrum Master | Team Effectiveness | Are we working effectively? |
| Developers | Product Delivery | How can we build it well? |
These perspectives complement rather than compete with each other.
How Scrum Roles Work Together
Product Owner + Developers
- Clarify customer needs
- Refine backlog items
- Discuss priorities
- Validate delivered value
Scrum Master + Developers
- Improve collaboration
- Remove impediments
- Facilitate learning
- Encourage continuous improvement
Scrum Master + Product Owner
- Improve backlog quality
- Strengthen stakeholder communication
- Coach evidence-based prioritization
- Support Product Goal clarity
All Three Accountabilities
Healthy Scrum Teams share:
- Mutual respect
- Open communication
- Trust
- Transparency
- Customer focus
- Continuous learning
RACI Matrix for Scrum
The following matrix illustrates how common Scrum activities are typically shared among the three accountabilities.
| Activity | Product Owner | Scrum Master | Developers |
|---|---|---|---|
| Product Vision | A | C | I |
| Product Backlog | A | C | C |
| Sprint Planning | R | F | R |
| Development Work | I | I | A |
| Daily Scrum | I | F | A |
| Sprint Review | A | F | R |
| Sprint Retrospective | C | F | R |
| Product Release | A | C | R |
Legend
- A – Accountable
- R – Responsible
- C – Consulted
- I – Informed
- F – Facilitates
The PACE Framework for Scrum Leadership
Processes alone do not create high-performing Scrum Teams. Leadership behaviors have a profound influence on collaboration, innovation, and long-term success.
The PACE Framework is an original leadership model designed to help Scrum leaders enable rather than control their teams.
P — Purpose
Ensure every team member understands the Product Goal, Sprint Goal, and the customer problem being solved. Teams with a clear purpose make better day-to-day decisions and remain focused during changing priorities.
A — Alignment
Create shared understanding among stakeholders, Product Owners, Scrum Masters, and Developers. Alignment reduces misunderstandings, minimizes conflicting priorities, and supports faster decision-making.
C — Coaching
Develop people through mentoring, constructive feedback, facilitation, and continuous learning. Coaching builds long-term capability, while command-and-control creates dependency.
E — Empowerment
Give teams the authority to make decisions, experiment, learn from feedback, and continuously improve. Empowered teams adapt more quickly to change and take greater ownership of outcomes.
Applying the PACE Framework
| PACE Principle | Leadership Action | Expected Outcome |
|---|---|---|
| Purpose | Communicate a clear Product Goal | Shared direction |
| Alignment | Encourage transparent communication | Reduced confusion |
| Coaching | Ask questions instead of giving answers | Greater capability |
| Empowerment | Delegate decisions to the team | Higher ownership and innovation |
Organizations often attempt to improve Scrum by adding more processes and approvals. High-performing teams usually improve by increasing trust, clarity, collaboration, and empowerment instead.
Authoritative References
The concepts discussed in this guide are based on internationally recognized Scrum and Agile resources.
-
The Scrum Guide
Ken Schwaber & Jeff Sutherland - Agile Manifesto
- Project Management Institute (PMI)
-
Harvard Business Review
The New New Product Development Game (1986) -
Google re:Work
Psychological Safety Research
Peer-Reviewed Research
Several scientific studies support the psychological and organizational principles behind Scrum.
- Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams.
- Takeuchi, H. & Nonaka, I. (1986). The New New Product Development Game.
- Deci, E. & Ryan, R. Self-Determination Theory.
- Schwaber, K. & Sutherland, J. The Scrum Guide.
Comments
Post a Comment