What “Developer” Means

A Developer is accountable for:

• Creating a usable Increment each Sprint

• Meeting the Definition of Done

• Adapting the Sprint Backlog daily

• Holding each other accountable as professionals

Designers, testers, analysts, architects—if they contribute to the Increment, they are Developers in Scrum.

Scrum optimizes for flow to Done, not role silos.

What “Developer” Does Not Mean

It does not mean:

• “The person who writes code only”

• “Someone who waits for instructions”

• “QA is separate from Developers”

• “Only seniors decide technical direction”

These are anti-patterns that fragment ownership and slow delivery.

When work moves between functional silos, flow degrades.

Common Anti-Patterns That Kill Flow

1. Mini-waterfall inside the Sprint
   Dev → QA → Rework

2. Specialist bottlenecks
   One person owns testing, automation, or deployment.

3. Partial ownership
   “My task is done” vs. “The Increment is Done.”

Scrum requires shared accountability for outcomes.

Practical Diagnostic

If your Sprint ends with:

• Stories “almost done”

• Testing deferred

• Integration incomplete

The team is likely operating with role boundaries instead of shared Developer accountability.

Exercise

1. Write your team’s top 3 Developer responsibilities.

2. Compare them to your current working agreements.

3. Identify gaps between:

   • What Scrum expects

   • What your team actually practices

If responsibilities do not clearly support producing a Done Increment every Sprint, adjust your agreements.

Clarity here improves throughput immediately.