Developers are accountable for ensuring work meets the team’s Definition of Done (DoD), but the DoD itself is a shared agreement reflecting collective quality standards. Sustainable delivery requires both enforcing DoD and continuously refining it as a team.

Key Clarifications on Accountability for "Done"

1. Developers Adherence to DoD
   • They are responsible for ensuring that each product increment aligns with the agreed-upon DoD.
   • This encompasses code quality, testing, documentation, and any other standards the team has set.
   • If work doesn’t meet DoD, developers must either fix it or flag it as incomplete.
2. DoD is a Team Agreement (Not Just Developers’)
   • While developers enforce DoD, the entire Scrum Team (Developers, Product Owner, Scrum Master) collaborates on defining it.
   • Example:
     • PO may require user-facing docs.
     • QA (if separate) may contribute test coverage thresholds.
     • Security/DevOps may set compliance checks.
   • Developers ensure that the Definition of Done (DoD) criteria are met, but they do not define the DoD independently.

However, the Product Owner is responsible for accepting or rejecting after verifying that the work completed by the developers meets the DOD (business acceptance) and aligns with the requirement of Product backlog item.

Refined Guidance on Scrum Event Participation

1. Core Rule
   • Scrum Team members (Developers, Product Owner, Scrum Master) are the only required participants in all events.
2. Flexible Invitations (When Helpful, determined by Scrum Team)
   • Subject Matter Experts (SMEs) may join partially (e.g., clarify technical details during Backlog Refinement).
   • Stakeholders/Users may contribute to:
     • Sprint Reviews (feedback on the increment)
     • Backlog Refinement (clarify requirements)

Key Boundaries:

• Invite selectively – Only include those who add immediate value to the discussion.
• Timebox external input – Avoid letting guests dominate the event.
• Scrum Master’s Role – Ensures outsiders don’t disrupt the team’s self-management.

Scrum’s effectiveness stems not from its structure (roles, events, artifacts) but from its alignment with Agile: iterative value delivery, rapid feedback loops, and responsiveness to change.

The 3 pillars allow teams to work in a fact-based, experience-based, and evidence-based manner.

The 3 pillars of Empiricism:

1. Transparency – All work, progress, and challenges must be visible to the team and stakeholders.
2. Inspection – Frequent reviews of artifacts (e.g., Increment, Sprint Backlog) and processes.
3. Adaptation – Adjusting based on inspections to minimize deviation from goals.

Systems thinking is a core competency for Scrum Masters and all change agents. The role focuses on facilitation, coaching, and removing impediments rather than technical or project management expertise. It enables them to see interdependencies, identify root causes, and foster sustainable improvements, rather than applying quick fixes.