Scrum Developers: Teamgroesse, Selbstmanagement-Praktiken & Rollen-Leitfaden (2026)

Developers sind die Personen im Scrum Team, die sich verpflichten, in jedem Sprint einen nutzbaren Aspekt eines Increment zu erstellen. Die Rolle ist nicht auf Softwareentwickler beschraenkt - sie umfasst jeden, dessen Faehigkeiten direkt zum Produkt beitragen, etwa Tester, Designer, UX-Researcher, Datenbankspezialisten, technische Redakteure und Operations-Ingenieure.

Viele Praktiker suchen weiterhin nach "Entwicklungsteam" (Development Team), da dies bis Ende 2020 die offizielle Bezeichnung war. Das Scrum-Guide-2020-Update (opens in a new tab) hat "Entwicklungsteam" zugunsten von "Developers" abgeloest und die Rolle zusammen mit dem Product Owner und dem Scrum Master in ein einziges, vereinheitlichtes Scrum Team aus Verantwortlichkeiten integriert, statt drei getrennte Unterteams zu fuehren. Dieser Leitfaden verwendet durchgehend die aktuelle Bezeichnung "Developers", erklaert aber die Umbenennung im Detail, da die aeltere Sprachregelung in Stellenanzeigen, Zertifizierungs-Lernmaterialien und im alltaeglichen Gespraech weiterhin gebraeuchlich ist.

Dies ist eine umfassende Ressource fuer alle, die verstehen muessen, wofuer Developers verantwortlich sind, wie gross eine Developers-Gruppe sein sollte, was den Unterschied zwischen Selbstorganisation und Selbstmanagement ausmacht, was Cross-Funktionalitaet wirklich erfordert, und welche Fehler selbst wohlmeinende Teams still und leise untergraben.

Schnellantwort: Scrum Developers im Ueberblick

Aspekt	Details
Offizieller Begriff (Scrum Guide 2020)	"Developers" - die Bezeichnung "Entwicklungsteam" aus dem Guide von 2017 wurde abgeloest
Teamgroesse	Das Scrum Team umfasst insgesamt 10 oder weniger Personen; Developers zaehlen typischerweise 3-9
Struktur	Cross-funktional (alle fuer ein Increment noetigen Faehigkeiten vorhanden) und selbstmanagend (entscheidet, wer was, wann und wie tut)
Kernverantwortlichkeiten	Den Sprint-Backlog-Plan erstellen, Qualitaet durch die Definition of Done verankern, den Plan taeglich in Richtung Sprint Goal anpassen, sich gegenseitig zur Verantwortung ziehen
Interne Hierarchie	Keine - keine Unterteams, keine Titel, niemand weist einem anderen Developer Arbeit zu
Wichtige Unterscheidung 2020	Selbstmanagement (wer, was und wie) ersetzte Selbstorganisation (nur wie) als Begriff fuer das gesamte Scrum Team

Was sind Developers in Scrum?

Developers sind eine von drei Verantwortlichkeiten, aus denen sich das Scrum Team zusammensetzt, neben dem Product Owner und dem Scrum Master. Sie sind die Personen, die aus einem Product-Backlog-Element ein funktionierendes, wertvolles Stueck des Produkts machen.

Trotz des Namens ist "Developers" nicht auf Softwareentwickler beschraenkt. Der Scrum Guide stellt explizit klar, dass zu den Developers gehoeren koennen:

• Softwareentwickler und Programmierer
• Qualitaetssicherungs- und Testingenieure
• UX/UI-Designer und -Researcher
• Datenbankadministratoren und Data Engineers
• Technische Redakteure und Dokumentationsspezialisten
• DevOps-, Infrastruktur- und Plattformingenieure
• Jeder andere Spezialist, dessen Faehigkeit tatsaechlich noetig ist, um das Increment zu erstellen

Von Entwicklungsteam zu Developers: Warum sich der Begriff geaendert hat

Der Scrum Guide 2017 (opens in a new tab) beschrieb ein Scrum Team, das aus drei Teilen bestand: einem Product Owner, einem Scrum Master und einem "Entwicklungsteam" (Development Team). Diese Formulierung implizierte eine Struktur, in der das Entwicklungsteam ein eigenstaendiges Unterteam war, das Arbeit vom Product Owner erhielt - funktional aehnlich dazu, wie ein Projektmanager in einer traditionellen Struktur Anforderungen an ein Engineering-Team weiterreichen wuerde.

Der Scrum Guide 2020 entfernte "Entwicklungsteam" vollstaendig. An seine Stelle definiert der Guide ein Scrum Team, das drei Verantwortlichkeiten enthaelt: Developers, Product Owner und Scrum Master. Dies war die bewusste Korrektur eines verbreiteten Missverstaendnisses, kein einfacher Wortaustausch. Ken Schwaber und Jeff Sutherland wollten den Eindruck beseitigen, dass Product Owner und Scrum Master ausserhalb oder oberhalb der Personen stehen, die die eigentliche Arbeit leisten.

Was sich tatsaechlich geaendert hat:

• "Entwicklungsteam" (ein Unterteam innerhalb des Scrum Teams) wurde zu "Developers" (eine von drei Verantwortlichkeiten innerhalb eines einzigen Scrum Teams)
• Die Vorstellung, ein Product Owner oder Scrum Master "verwalte" ein separates Entwicklungsteam, wurde explizit ausgeschlossen
• "Selbstorganisierend" (wie die Arbeit erledigt wird) wurde durch "selbstmanagend" (wer was, wann und wie tut) ersetzt - im Detail im naechsten Abschnitt behandelt
• Die Verantwortlichkeiten des Teams wurden als kurze, explizite Liste neu formuliert statt als lose Beschreibung von "Aufgaben"

Warum der aeltere Begriff weiterlebt: Vor 2021 veroeffentlichte Zertifizierungs-Lernmaterialien, von Recruitern verfasste Stellenanzeigen, die das Update nicht kennen, sowie unzaehlige Blogbeitraege und Buecher verwenden weiterhin "Entwicklungsteam". Das Suchvolumen fuer "Entwicklungsteam" im Scrum-Kontext bleibt genau aus diesem Grund hoch - dieser Leitfaden behandelt die Begriffe historisch als Synonyme, verwendet aber standardmaessig "Developers" als aktuell korrekten Sprachgebrauch.

Verantwortlichkeiten der Developers gemaess dem Scrum Guide 2020

Der Scrum Guide listet vier Dinge auf, fuer die Developers immer verantwortlich sind. Das sind keine optionalen Praktiken, die man bei Gelegenheit uebernimmt - sie definieren die Verantwortlichkeit selbst.

Verantwortlichkeit	Was das in der Praxis bedeutet
Den Sprint-Backlog-Plan erstellen	Developers waehlen waehrend des Sprint Planning Product-Backlog-Elemente aus und erstellen den Sprint Backlog selbst
Qualitaet durch die Definition of Done verankern	Jedes Arbeitsinkrement muss die Definition of Done des Teams erfuellen, bevor es als fertig gilt
Den Plan taeglich in Richtung Sprint Goal anpassen	Im Daily Scrum inspizieren Developers den Fortschritt und planen die naechsten 24 Stunden neu
Sich gegenseitig als Profis zur Verantwortung ziehen	Kein externer Manager setzt Standards durch - Developers halten sich selbst und einander an die Verpflichtungen, die sie eingegangen sind

Den Sprint-Backlog-Plan erstellen

Waehrend des Sprint Planning entscheiden Developers - nicht der Product Owner und nicht der Scrum Master -, wie viel Product-Backlog-Arbeit sie realistisch zusagen koennen und wie sie diese umsetzen werden. Der daraus entstehende Sprint Backlog ist ein lebendiger Plan, kein fester Vertrag; Developers aktualisieren ihn waehrend des Sprints, sobald sie mehr erfahren.

In der Praxis bedeutet das:

• Developers prognostizieren ihre eigene Kapazitaet, statt eine von aussen auferlegte Zusage zu akzeptieren
• Der Sprint Backlog gehoert Developers und wird von ihnen bearbeitet, ist aber fuer das gesamte Scrum Team sichtbar
• Aufgabenaufteilung, technischer Ansatz und Reihenfolge-Entscheidungen liegen allein bei Developers

Qualitaet durch die Definition of Done verankern

Die Definition of Done ist der objektive, gemeinsame Standard, der "Code, der kompiliert" von "einem Increment, das wirklich nutzbar ist" unterscheidet. Developers erfuellen nicht nur die Definition of Done - sie sind es, die sie gestalten und weiterentwickeln, da sie den technischen Praktiken, die zu ihrer Erfuellung noetig sind, am naechsten stehen.

Den Plan taeglich in Richtung Sprint Goal anpassen

Jeden Tag nutzen Developers den Daily Scrum, um den Fortschritt gegenueber dem Sprint Goal zu inspizieren und den Sprint Backlog entsprechend anzupassen. Hier zeigt sich Selbstmanagement am sichtbarsten: Niemand ausserhalb des Teams weist die Arbeit fuer den naechsten Tag zu.

Ein gesundes Anpassungsmuster sieht so aus:

1. Tatsaechlichen Fortschritt mit dem Sprint Goal vergleichen, nicht mit einer Aufgaben-Checkliste
2. Alles identifizieren, was den Fortschritt blockiert, und als Team entscheiden, wie es geloest wird
3. Verbleibende Sprint-Backlog-Arbeit basierend auf dem Gelernten neu ordnen
4. Den Product Owner sofort informieren, wenn das Sprint Goal selbst gefaehrdet ist

Sich gegenseitig zur Verantwortung ziehen

Es gibt keinen Manager innerhalb des Scrum Teams, der Konsequenzen fuer verpasste Zusagen verhaengt. Developers ziehen sich gegenseitig durch direkte, professionelle Gespraeche zur Verantwortung - verstaerkt durch die Sprint Retrospective, in der das Team explizit inspiziert, wie gut es seinen eigenen Arbeitsvereinbarungen gerecht wurde.

Selbstmanagement vs. Selbstorganisation: Die Nuance verstehen

Diese Unterscheidung ist eine der am haeufigsten missverstandenen Aenderungen im Scrum Guide 2020, und es lohnt sich, sie genau zu erklaeren, weil so viel vorhandenes Material (und sogar manche Zertifizierungsvorbereitung) die beiden Begriffe immer noch vermischt.

Konzept	Umfang der Entscheidung	Scrum-Guide-Version
Selbstorganisierend	Das Team entscheidet, wie es seine Arbeit erledigt	Zentraler Begriff im Guide von 2017
Selbstmanagend	Das Team entscheidet, wer die Arbeit macht, wann und wie	Ersetzte "selbstorganisierend" als definierenden Begriff im Guide von 2020

Das Prinzip der Selbstorganisation im Guide von 2017 behandelte wie Arbeit erledigt wurde und liess wer was tut und teilweise sogar was gebaut wird implizit der Fremdsteuerung offen. Das Prinzip des Selbstmanagements im Guide von 2020 ist umfassender: Es uebergibt Developers explizit die Kontrolle darueber, wer welches Arbeitspaket uebernimmt und wann dies geschieht - nicht nur das technische Wie.

Konkret bedeutet Selbstmanagement:

• Kein Manager und kein Scrum Master weist einzelnen Developers Aufgaben zu
• Developers entscheiden selbst, wer an was arbeitet, basierend auf Faehigkeiten, Kapazitaet und Interesse
• Das Team entscheidet intern, wann waehrend des Sprints welches Arbeitspaket erledigt wird
• Technischer Ansatz und Umsetzungsdetails bleiben vollstaendig Sache des Teams

Cross-Funktionalitaet und T-Shaped Skills

Cross-Funktionalitaet bedeutet, dass die Developers-Gruppe als Ganzes ueber jede Faehigkeit verfuegt, die noetig ist, um ein Product-Backlog-Element in ein nutzbares Increment zu verwandeln - ohne auf Personen ausserhalb des Teams angewiesen zu sein. Es bedeutet nicht, dass jeder einzelne Developer alles koennen muss.

T-Shaped Skills beschreiben das ideale individuelle Profil innerhalb eines cross-funktionalen Teams:

• Der senkrechte Balken des "T" steht fuer tiefgreifende Expertise in einer Disziplin (z. B. Backend-Engineering, UX-Research, Datenbankperformance)
• Der waagerechte Balken steht fuer Arbeitskompetenz in angrenzenden Disziplinen (z. B. ein Backend-Ingenieur, der einfachen Frontend-Code schreiben, einen manuellen Testdurchlauf durchfuehren oder einen Design-Mockup begutachten kann)

Warum T-Shaped Skills wichtiger sind als reine Spezialisten:

• Reduziert einzelne Ausfallpunkte - fehlt ein Spezialist, steht die Arbeit nicht vollstaendig still
• Verkuerzt Uebergabeverzoegerungen zwischen Disziplinen innerhalb eines einzelnen Sprints
• Erhoeht die Flexibilitaet, wenn sich die Zusammensetzung der Arbeit im Sprint Backlog mitten im Sprint verschiebt

Cross-Funktionalitaet aufbauen, ohne Expertise zu verwaessern:

1. Spezialisten bewusst mit Generalisten paaren, nicht nur, wenn es gerade passt
2. Verantwortung fuer wiederkehrende Aufgabentypen (Code-Review, Deployment, Support-Triage) im Team rotieren lassen
3. Explizit Zeit fuer Cross-Training einplanen, nicht nur fuer Feature-Lieferung
4. Den "Bus-Faktor" pro Faehigkeitsbereich verfolgen - kann nur eine Person etwas Kritisches tun, gilt das als zu loesendes Risiko

Teamgroesse und Zusammensetzung

Der Scrum Guide empfiehlt eine Gesamtgroesse des Scrum Teams von 10 oder weniger Personen, was typischerweise 3 bis 9 Developers bedeutet, sobald Product Owner und Scrum Master separat gezaehlt werden (in Scrum gehoeren sie ebenfalls zu den 10, auch wenn Scrum Master und Product Owner manchmal auch Developers-Arbeit leisten koennen, wenn sie die noetigen Faehigkeiten und Kapazitaeten haben).

Teamgroesse	Merkmale	Empfehlung
1-2 Developers	Minimale Redundanz, hohes individuelles Abhaengigkeitsrisiko	Meist zu klein - nach Moeglichkeit vermeiden
3-5 Developers	Schlank, schnelle Kommunikation, funktioniert gut fuer fokussierte Produkte	Solide fuer Produkte in fruehen Phasen oder enge Anwendungsbereiche
6-9 Developers	Genug Kapazitaet fuer nennenswerten Durchsatz, waehrend Kommunikation handhabbar bleibt	Idealer Bereich fuer die meisten etablierten Produktteams
10+ Developers	Kommunikationsaufwand waechst schneller als der Output; Koordination wird zur Dauerbeschaeftigung	Stattdessen in mehrere Scrum Teams aufteilen

Zusammensetzungshinweise jenseits der Kopfzahl:

• Priorisieren Sie, die tatsaechlich benoetigten Faehigkeiten des Produkts abzudecken, statt eine bestimmte Zahl zu erreichen
• Ein eng gefasstes Produkt (z. B. eine einzelne mobile App) braucht einen anderen Faehigkeiten-Mix als eine breite Plattform
• Testing- und Design-Faehigkeiten innerhalb des Teams verankern, statt sie als externe Dienstleistungen zu behandeln
• Vermeiden Sie ein Team, das ausschliesslich aus Spezialisten einer Disziplin besteht - das erzeugt innerhalb eines einzelnen Sprints erneut funktionale Silos

Team-Arbeitsvereinbarungen etablieren

Arbeitsvereinbarungen sind die expliziten, vom Team selbst verfassten Regeln, die Selbstmanagement und gegenseitige Verantwortung im Alltag praktikabel machen. Ohne sie hat "sich gegenseitig zur Verantwortung ziehen" keinen gemeinsamen Massstab, an dem irgendjemand gemessen wird.

Gaengige Kategorien von Arbeitsvereinbarungen:

Kategorie	Beispielvereinbarung
Verfuegbarkeit	Kern-Kollaborationszeiten, in denen jeder erreichbar ist, auch ueber Zeitzonen hinweg
Code-Review	Kein Merge ohne mindestens ein genehmigendes Review; Reviews werden innerhalb von 24 Stunden erledigt
Kommunikation	Der Daily Scrum beginnt puenktlich, unabhaengig davon, wer anwesend ist; Blocker werden noch am selben Tag gemeldet
Definition of Done	Explizit, schriftlich festgehalten und mindestens einmal pro Quartal ueberpruefen
Umgang mit Konflikten	Meinungsverschiedenheiten werden zunaechst direkt mit der Person besprochen, nicht sofort eskaliert
Meeting-Disziplin	Kameras an bei Remote-Sync-Meetings; Agenda im Voraus geteilt

Wie man Arbeitsvereinbarungen erstellt, die halten:

1. Sie gemeinsam in einem Workshop entwerfen, niemals von oben herab vorgeben
2. Die anfaengliche Liste kurz halten - fuenf oder sechs Vereinbarungen, an die sich das Team tatsaechlich haelt, sind besser als fuenfzehn, die ignoriert werden
3. Sie sichtbar veroeffentlichen (Team-Wiki, Board-Header), damit sie eine lebendige Referenz sind, kein vergessenes Dokument
4. Sie waehrend einer Sprint Retrospective alle paar Sprints explizit ueberpruefen und ueberarbeiten

Technische Praktiken, die leistungsstarke Developers unterstuetzen

Selbstmanagement und Qualitaetsverantwortung funktionieren nur, wenn Developers das technische Fundament haben, um schnell voranzukommen, ohne die Definition of Done zu brechen. Die folgenden Praktiken unterscheiden typischerweise eine Developers-Gruppe, die sich taeglich anpassen kann, von einer, die jedes Release fuerchtet.

• Continuous Integration und Continuous Delivery (CI/CD): Automatisierte Build-, Test- und Deployment-Pipelines, die "den Plan jeden Tag anzupassen" sicher statt riskant machen. Siehe Continuous Integration fuer Umsetzungshinweise.
• Automatisiertes Testing: Unit-, Integrations- und End-to-End-Testsuiten, mit denen das Team die Definition of Done schnell und wiederholt verifizieren kann, statt sich auf langsame manuelle Regressionsdurchlaeufe zu verlassen. Siehe Agiles Testen.
• Pair- und Mob-Programming: Zwei oder mehr Developers arbeiten gleichzeitig am selben Code, verbreiten Wissen und finden Fehler frueher als bei einem Solo-dann-Review-Workflow.
• Code-Review: Eine feste Praxis, kein nachtraeglicher Gedanke - Review-Kriterien sollten Teil der Definition of Done sein, kein separates, optionales Gate.
• Trunk-Based Development oder kurzlebige Branches: Reduziert das Risiko von Merge-Konflikten und haelt das Increment waehrend des gesamten Sprints naeher am Release-Zustand, nicht nur am Ende.
• Refactoring als laufende Arbeit: Kleine, kontinuierliche Codequalitaetsverbesserungen, eingebettet in regulaere Sprint-Backlog-Elemente, statt auf einen seltenen "Technical-Debt-Sprint" verschoben zu werden.

Branchenspezifische Beispiele fuer Developers

Wie Developers die Definition of Done, technische Praktiken und die Qualitaetsmesslatte anwenden, verschiebt sich je nach Branche deutlich. Diese Checklisten zeigen feste Praktiken, die es sich lohnt fuer gaengige Branchenkontexte hinzuzufuegen.

SaaS / Cloud-Produktteams

✓ Code von mindestens einem Peer vor dem Merge begutachtet ✓ Automatisierte Unit- und Integrationstests bestehen (Ziel >75% Abdeckung) ✓ CI/CD-Pipeline laeuft gruen vor dem Deployment ✓ Feature-Flags fuer riskante oder unvollstaendige Funktionalitaet verwendet ✓ Uptime- und Monitoring-Alerts fuer neue Services konfiguriert ✓ Auf Staging deployt und vor dem Produktions-Release smoke-getestet

Healthcare-Software-Teams

✓ Vier-Augen-Code-Review fuer jeden Code erforderlich, der Protected Health Information (PHI) beruehrt ✓ HIPAA-Compliance-Checkliste vollstaendig abgeschlossen und abgezeichnet ✓ Audit-Logging fuer jeden PHI-Zugriff und jede PHI-Aenderung implementiert ✓ Verschluesselung fuer PHI im Ruhezustand und bei der Uebertragung verifiziert ✓ Rollenbasierte Zugriffskontrolle getestet, einschliesslich negativer Testfaelle ✓ Sicherheitsscan ohne Befunde hoher oder kritischer Schwere bestanden

Finanzdienstleistungsteams

✓ PCI-DSS- und SOC-2-Kontrollanforderungen fuer neuen Code verifiziert ✓ Verschluesselung fuer alle Finanzdatenfluesse implementiert ✓ Betrugserkennungslogik gegen bekannte False-Positive-/False-Negative-Muster getestet ✓ Regulatorische Dokumentation zusammen mit der Codeaenderung aktualisiert ✓ Unabhaengiges Sicherheitsreview fuer zahlungsnahe Funktionalitaet abgeschlossen ✓ Rollback-Verfahren vor dem Release getestet und dokumentiert

E-Commerce-Teams

✓ Zahlungsabwicklungspfade gegen Fehler- und Wiederholungsszenarien getestet ✓ Ziele fuer Seitenladezeit und Checkout-Performance erreicht ✓ Warenkorb- und Bestandslogik unter gleichzeitigen Nutzerbedingungen getestet ✓ Bereitschaft fuer Lastspitzen vor saisonalen Traffic-Ereignissen verifiziert ✓ Barrierefreiheit des Checkout-Ablaufs validiert ✓ Analytics und Konversions-Tracking nach dem Deployment als funktionierend bestaetigt

Mobile-App-Teams

✓ Auf echten Geraeten ueber unterstuetzte Betriebssystemversionen hinweg getestet, nicht nur in Simulatoren ✓ Auswirkung auf Akkulaufzeit und Performance fuer neue Features bewertet ✓ Offline-Verhalten und Umgang mit schlechter Verbindung verifiziert ✓ Einhaltung der App-Store-Richtlinien vor der Einreichung geprueft ✓ iOS-/Android-Paritaet bestaetigt, wo Features identisch funktionieren sollen ✓ Crash-Reporting und Analytics fuer das neue Release instrumentiert

Enterprise / DevOps-Teams

✓ Infrastructure-as-Code-Aenderungen zusammen mit Anwendungscode begutachtet ✓ Sicherheitsscanning in die CI/CD-Pipeline integriert, nicht nachtraeglich manuell ausgefuehrt ✓ Rollback- und Disaster-Recovery-Verfahren getestet, nicht nur dokumentiert ✓ Konfigurationsabweichung gegen den beabsichtigten Infrastrukturzustand geprueft ✓ Team-uebergreifende Abhaengigkeiten vor dem Merge kommuniziert, nicht danach ✓ Monitoring und Alerting aktualisiert, um neue Infrastrukturkomponenten abzudecken

Regierungs- und oeffentliche Sektor-Teams

✓ Section-508-/WCAG-2.1-AA-Barrierefreiheit fuer alle UI-Aenderungen validiert ✓ FISMA- oder gleichwertige Sicherheitskontrollanforderungen geprueft ✓ Anforderungen an oeffentliche Aufzeichnungen und Datenaufbewahrung fuer neue Datenfluesse geprueft ✓ Beschaffungs- und Compliance-Einschraenkungen in der Definition of Done beruecksichtigt ✓ Review auf einfache Sprache fuer buergerorientierte Features abgeschlossen ✓ Aenderung ausreichend fuer Anforderungen an oeffentliche Transparenz dokumentiert

EdTech-Teams

✓ FERPA- und COPPA-Compliance fuer jedes Feature verifiziert, das Schuelerdaten beruehrt ✓ Barrierefreiheit fuer die UI-Aenderungen des Sprints getestet, einschliesslich Screenreader-Unterstuetzung ✓ Schuelerdaten wo technisch machbar anonymisiert oder minimiert ✓ Paedagogische Auswirkung beruecksichtigt, nicht nur technische Korrektheit ✓ Eltern- oder institutionelle Einwilligungsablaeufe wo zutreffend getestet ✓ Datenschutzmassnahmen in die Definition of Done eingebaut, nicht nachtraeglich ergaenzt

Developers-Reifegradmodell

Die Faehigkeit von Developers zur Selbststeuerung, zur Cross-Funktionalitaet und zur nachhaltigen Qualitaet waechst schrittweise. Nutzen Sie dieses Modell, um realistische Erwartungen dafuer zu setzen, wo ein Team steht und wohin als naechstes investiert werden sollte.

Stufe 1: Grundlegend / Forming (Sprints 1-6)

Zeitrahmen: die ersten 6 Sprints einer neu gebildeten Developers-Gruppe

Merkmale:

• Starke Abhaengigkeit von manuellem Testen und Ad-hoc-Code-Review
• Definition of Done existiert, ist aber minimal und wird unter Druck manchmal ausgelassen
• Aufgabenzuweisung zeigt noch Spuren externer Steuerung (ein Lead, der Arbeit "verteilt")
• Cross-Funktionalitaet ist begrenzt - die meiste Arbeit geht an den jeweiligen Spezialisten, dem dieser Bereich "gehoert"

Fokus fuer diese Stufe:

• Eine anfaengliche Definition of Done aufschreiben, auch eine kurze, und sich ausnahmslos daran halten
• Grundlegende Arbeitsvereinbarungen etablieren (siehe oben)
• Damit beginnen, Spezialisten mit Generalisten bei einer Teilmenge der Aufgaben jedes Sprints zu paaren
• Ueben, Arbeit waehrend des Sprint Planning selbst auszuwaehlen, statt sie zugewiesen zu bekommen

Stufe 2: Mittel (Sprints 7-15)

Zeitrahmen: Sprint 7 bis etwa Sprint 15

Merkmale:

• Automatisierte Testabdeckung waechst (typischerweise 50-70%)
• Eine funktionierende CI/CD-Pipeline existiert, auch wenn nicht vollstaendig durchgaengig automatisiert
• Code-Review erfolgt konsistent und nutzt eine gemeinsame Checkliste
• Das Team hat eine schriftliche, regelmaessig ueberpruefte Definition of Done

Fokus fuer diese Stufe:

• Automatisierte Testabdeckung erhoehen und Abhaengigkeit von manuellen Regressionsdurchlaeufen reduzieren
• Verantwortung fuer wiederkehrende Aufgaben (Deployment, Bereitschaftsdienst, Review) auf mehr Teammitglieder rotieren lassen
• Beginnen, den "Bus-Faktor" fuer kritische Faehigkeiten zu verfolgen und einzelne Ausfallpunkte aktiv zu reduzieren
• Die Sprint Retrospective explizit nutzen, um Arbeitsvereinbarungen zu ueberarbeiten, nicht nur ueber Stimmung zu sprechen

Stufe 3: Fortgeschritten / Hochleistungsfaehig (Sprints 16-30)

Zeitrahmen: Sprint 16 bis etwa Sprint 30

Merkmale:

• Umfassende Testautomatisierung (typischerweise >80% Abdeckung) einschliesslich Integrations- und End-to-End-Suiten
• Vollstaendig automatisiertes CI/CD mit gestaffelten, risikoarmen Deployments
• Echte Cross-Funktionalitaet - die meisten Sprint-Backlog-Elemente koennen von mehr als einem Developer uebernommen werden
• Das Team loest die meisten technischen und zwischenmenschlichen Probleme ohne externes Eingreifen

Fokus fuer diese Stufe:

• Performance-, Sicherheits- und Barrierefreiheitstests zur Standard-Definition-of-Done hinzufuegen
• Neuere Developers oder neuere Teams innerhalb der Organisation mentorieren
• Technische Schulden aktiv als sichtbare, priorisierte Backlog-Elemente managen, statt sie aufzuschieben
• Mehr mehrdeutige Probleme angehen, die Urteilsvermoegen erfordern, nicht nur Ausfuehrung

Stufe 4: Experte (Sprint 31+)

Zeitrahmen: ab Sprint 31

Merkmale:

• Das Team verbessert routinemaessig und ohne Aufforderung seine eigenen Engineering-Praktiken
• Technische Praktiken und Arbeitsvereinbarungen werden als lebendige, versionierte Artefakte behandelt
• Die Developers-Gruppe traegt wiederverwendbare Werkzeuge, Muster oder Playbooks zu anderen Teams bei
• Gegenseitige Verantwortung ist vollstaendig verinnerlicht - Konflikte und Qualitaetsluecken werden direkt und frueh angesprochen

Fokus fuer diese Stufe:

• Engineering-Praktiken und Definition-of-Done-Vorlagen zur breiteren Organisation beitragen
• Eine aktive Rolle beim Onboarding und Mentoring ueber mehrere Teams hinweg uebernehmen
• Grundlagen regelmaessig neu ueberdenken - selbst Expertenteams profitieren davon, Arbeitsvereinbarungen gelegentlich neu zu betrachten
• Skalierungsentscheidungen unterstuetzen (siehe Fortgeschrittene Strategien), waehrend die Organisation waechst

Haeufige Developers-Fehler

Fehler 1: Sprint-Backlog-Elemente Einzelpersonen von ausserhalb des Teams zuweisen

Problem: Ein Manager, Team-Lead oder sogar der Product Owner weist waehrend oder vor dem Sprint Planning bestimmten Developers bestimmte Aufgaben zu.

Warum es problematisch ist: Das verstoesst direkt gegen Selbstmanagement - Developers, nicht eine externe Rolle, entscheiden, wer was und wann tut.

Loesung: Developers Arbeit waehrend des Sprint Planning basierend auf Faehigkeit, Kapazitaet und Interesse selbst auswaehlen lassen.

Praevention: Selbstauswahl zu einer expliziten, festgelegten Arbeitsvereinbarung machen und den Scrum Master eingreifen lassen, wenn externe Zuweisung wieder auftritt.

Fehler 2: Selbstmanagement mit fehlender Verantwortlichkeit verwechseln

Problem: Ein Team interpretiert "niemand steuert uns" als "niemand darf unsere Entscheidungen hinterfragen", und Qualitaet oder Zusagen rutschen ohne Widerspruch ab.

Warum es problematisch ist: Selbstmanagement ersetzt externe Steuerung durch interne Verantwortlichkeit - es hebt Verantwortlichkeit nicht insgesamt auf.

Loesung: Gegenseitige Verantwortung explizit in der Sprint Retrospective staerken; verpasste Zusagen zu einem stehenden Diskussionsthema machen, nicht zu einem Tabu.

Praevention: Arbeitsvereinbarungen aufstellen, die benennen, was passiert, wenn eine Zusage verpasst wird, vom Team selbst vereinbart.

Fehler 3: Silos aufbauen, obwohl das Team auf dem Papier "cross-funktional" ist

Problem: Nur eine Person kann eine bestimmte Komponente gefahrlos anfassen, obwohl das Team nominell ueber alle noetigen Faehigkeiten verfuegt.

Warum es problematisch ist: Ein einzelner Ausfallpunkt untergraebt den Zweck der Cross-Funktionalitaet - das Team ist nur dem Namen nach cross-funktional.

Loesung: Die alleinige Inhaberin oder den alleinigen Inhaber eines Faehigkeitsbereichs bewusst mit jemand anderem bei relevanten Aufgaben paaren, bis sich der Bus-Faktor verbessert.

Praevention: Den Bus-Faktor pro kritischem Faehigkeitsbereich als stehenden Punkt in Planning oder Retrospektiven verfolgen.

Fehler 4: Die Definition of Done unter Terminddruck aufweichen

Problem: Das Team ueberspringt vereinbarte Qualitaetsschritte (Testing, Review, Dokumentation), um einen Releasetermin zu erreichen.

Warum es problematisch ist: Auf diese Weise entstandene Qualitaetsschulden werden selten zurueckgezahlt - sie haeufen sich an und verlangsamen jeden zukuenftigen Sprint.

Loesung: Die Definition of Done als nicht verhandelbar behandeln; kann der Sprint Backlog innerhalb dieser Grenzen nicht abgeschlossen werden, den Umfang reduzieren statt der Qualitaet.

Praevention: Die Definition of Done sichtbar machen und die Einhaltung waehrend Sprint Review und Retrospective explizit ueberpruefen.

Fehler 5: Das Team ueber neun Developers hinaus wachsen lassen, statt es zu teilen

Problem: Eine Developers-Gruppe blaeht sich auf 12-15 Personen auf, um Kapazitaet hinzuzufuegen, statt ein zweites Scrum Team zu bilden.

Warum es problematisch ist: Koordinationsaufwand waechst schneller als der Output, sobald ein Team etwa neun Personen ueberschreitet, und Scrum-Ereignisse geraten zunehmend an ihre Timebox-Grenzen.

Loesung: In zwei Scrum Teams aufteilen, die sich ein Product Backlog teilen, koordiniert durch Praktiken wie Scrum skalieren.

Praevention: Neun Developers als weiche Obergrenze behandeln und die Aufteilung planen, bevor das Team den Schmerz der Groesse spuert.

Fehler 6: Titel und informelle Hierarchie wieder einschleichen lassen

Problem: Ein "Senior"- oder "Lead"-Developer beginnt, die taeglichen Aufgaben anderer wie ein informeller Manager zu steuern.

Warum es problematisch ist: Der Scrum Guide stellt explizit klar, dass es innerhalb der Developers keine Hierarchie gibt - eine wieder einzufuehren untergraebt sowohl Selbstmanagement als auch gegenseitige Verantwortung.

Loesung: Technische Fuehrung auf Mentoring und Einfluss ausrichten, nicht auf Aufgabenzuweisung oder Genehmigungsbefugnis.

Praevention: "Keine interne Hierarchie" zu einem expliziten Onboarding-Thema fuer neue Developers und neue Leads gleichermassen machen.

Fehler 7: Testing und Design als externe Dienstleistungen behandeln

Problem: Tester oder Designer sitzen ausserhalb der Developers-Gruppe und erhalten Arbeit als Uebergabe, statt am Sprint selbst teilzunehmen.

Warum es problematisch ist: Das erzeugt in jedem Sprint einen Mini-Wasserfall und bricht das Versprechen "nutzbares Increment in jedem Sprint".

Loesung: Testing- und Design-Faehigkeiten vollstaendig in die Developers-Gruppe einbeziehen, beteiligt ab dem Sprint Planning.

Praevention: Bei der Bildung oder Neubesetzung eines Teams die vom Produkt benoetigten Faehigkeiten priorisieren, nicht bequeme organisatorische Berichtslinien.

Fehler 8: Technische Praktiken ueberspringen, um "schneller voranzukommen"

Problem: Das Team ueberspringt automatisiertes Testing, CI/CD oder Code-Review, um kurzfristige Termine zu erreichen.

Warum es problematisch ist: Das tauscht einen kleinen, sichtbaren kurzfristigen Geschwindigkeitsgewinn gegen deutlich groessere, versteckte langfristige Kosten in Form von Fehlern und langsamerer zukuenftiger Lieferung.

Loesung: In technische Praktiken als Teil der Definition of Done investieren, nicht als optionale Extras.

Praevention: Fehlerentweichungsrate und Deployment-Haeufigkeit im Zeitverlauf verfolgen, um die Kosten ausgelassener Praktiken sichtbar zu machen.

Fehler 9: Keine Arbeitsvereinbarungen, oder Vereinbarungen, an die sich niemand haelt

Problem: Das Team hat keine expliziten Normen oder hat Normen, die einmal aufgeschrieben und nie wieder erwaehnt wurden.

Warum es problematisch ist: Ohne gemeinsame, befolgte Normen hat gegenseitige Verantwortung nichts Konkretes, woran sie irgendjemanden messen kann.

Loesung: Einen kurzen, konkreten Satz von Arbeitsvereinbarungen gemeinsam entwerfen und regelmaessig ueberpruefen (siehe oben).

Praevention: Die Ueberpruefung der Arbeitsvereinbarungen alle paar Sprints zu einem festen Tagesordnungspunkt der Sprint Retrospective machen.

Fehler 10: Das Team unterbesetzen, um Kosten zu sparen

Problem: Von einem Team aus ein oder zwei Developers wird erwartet, das gesamte fuer das Produkt benoetigte Spektrum an Faehigkeiten abzudecken.

Warum es problematisch ist: Minimale Redundanz bedeutet, dass jede Abwesenheit, Krankheit oder jeder Weggang ein unmittelbares Lieferrisiko erzeugt, und echte Cross-Funktionalitaet wird unmoeglich.

Loesung: Auf den vom Scrum Guide empfohlenen Bereich besetzen und dabei die spezifischen Faehigkeiten priorisieren, die das Produkt tatsaechlich braucht.

Praevention: "Mindestens 3 Developers" als Ausgangspunkt fuer Tragfaehigkeit behandeln, nicht als Wunschziel, in das man irgendwann hineinwaechst.

Wie man eine starke Developers-Gruppe aufbaut und weiterentwickelt

Eine starke Developers-Gruppe aufzubauen ist ein bewusster, stufenweiser Prozess, kein Vorgang, der automatisch geschieht, sobald Personen einem Team zugewiesen werden.

Schritt 1: Fuer die vom Produkt benoetigten Faehigkeiten besetzen (Wochen 1-2)

• Die Faehigkeiten kartieren, die noetig sind, um fuer dieses spezifische Produkt ein nutzbares Increment zu liefern
• Das Schliessen von Luecken priorisieren, statt eine bestimmte Kopfzahl zu erreichen
• 3-9 Developers anstreben, basierend auf dem Produktumfang, nicht auf organisatorischer Bequemlichkeit

Schritt 2: Grundlegende Vereinbarungen etablieren (Sprints 1-3)

• Eine anfaengliche Definition of Done gemeinsam entwerfen
• Grundlegende Arbeitsvereinbarungen zu Verfuegbarkeit, Kommunikation und Code-Review erstellen
• Explizit klarstellen, dass Aufgabenzuweisung innerhalb des Teams geschieht, nicht von aussen

Schritt 3: Technische Grundlagen aufbauen (Sprints 1-10)

• CI/CD so frueh wie moeglich aufsetzen, auch in minimaler Form
• Automatisiertes Testing schrittweise einfuehren, nicht alles auf einmal
• Eine konsistente Code-Review-Praxis mit einer gemeinsamen Checkliste etablieren

Schritt 4: Cross-Funktionalitaet bewusst ausbauen (Sprints 5-20)

• Spezialisten rotierend mit Generalisten paaren
• Bus-Faktor pro Faehigkeitsbereich verfolgen und Konzentrationsrisiko direkt angehen
• Verantwortung fuer wiederkehrende operative Aufgaben (Deployment, Bereitschaftsdienst, Review) rotieren lassen

Schritt 5: Verantwortlichkeit und Selbstmanagement reifen lassen (fortlaufend)

• Die Sprint Retrospective nutzen, um Arbeitsvereinbarungen zu ueberpruefen und zu verfeinern
• Das Team coachen, Konflikte und Qualitaetsluecken direkt zu loesen, ohne Eskalation
• Die Beteiligung des Scrum Masters an der taeglichen Facilitation schrittweise reduzieren, waehrend das Team reift

Die Effektivitaet der Developers-Gruppe messen

Die Gesundheit einer Developers-Gruppe ist teilweise immateriell (Vertrauen, Qualitaet der Zusammenarbeit), aber mehrere konkrete Signale zeigen, ob Selbstmanagement und Cross-Funktionalitaet in der Praxis tatsaechlich funktionieren - nicht nur in einer Team-Charta erklaert werden.

Metrik	Was sie anzeigt
Einhaltungsrate der Definition of Done	Wie oft "fertige" Arbeit tatsaechlich jedes vereinbarte Kriterium erfuellt, statt Schritte unter Druck still auszulassen
Bus-Faktor pro Faehigkeitsbereich	Wie viele Developers eine kritische Faehigkeit abdecken koennten, waere eine Person nicht verfuegbar - ein direkter Massstab fuer echte Cross-Funktionalitaet
Stabilitaet von Zykluszeit und Velocity	Ob sich Sprint-zu-Sprint-Schwankungen verringern, waehrend Arbeitsvereinbarungen und technische Praktiken reifen
Fehlerentweichungsrate	Ob Qualitaetspraktiken (Testing, Review, Definition of Done) Probleme vor dem Release abfangen
Deployment-Haeufigkeit	Wie oft das Team sicher ausliefert - ein Naeherungswert dafuer, wie gut CI/CD und automatisiertes Testing die taegliche Anpassung unterstuetzen
Einhaltung der Arbeitsvereinbarungen	Ob die eigenen erklaerten Normen des Teams tatsaechlich befolgt werden, regelmaessig ueberprueft waehrend der Sprint Retrospective
Rate der Aufgaben-Selbstauswahl	Wie oft Developers Arbeit waehrend des Sprint Planning selbst uebernehmen, statt sie von jemandem ausserhalb des Teams zugewiesen zu bekommen

Verfolgen Sie diese Metriken ueber mehrere Sprints hinweg, statt auf einen einzelnen Datenpunkt zu reagieren - ein Team, das seine Definition of Done verfeinert, zeigt beispielsweise oft einen vorruebergehenden Ruckgang im Durchsatz, bevor sich die Zykluszeit auf einem schnelleren, nachhaltigeren Niveau stabilisiert.

Fortgeschrittene Strategien und Skalierungsueberlegungen

Mit wachsenden Produkten und Organisationen kann eine einzelne Developers-Gruppe den noetigen Umfang irgendwann nicht mehr allein abdecken. Mehrere Strategien erweitern Scrums Struktur, ohne dessen Kernverantwortlichkeiten aufzugeben.

Wenn ein Team nicht ausreicht:

• In mehrere Scrum Teams aufteilen, die sich ein Product Backlog und einen Product Owner (oder ein Product-Owner-Team) teilen, sobald eine einzelne Developers-Gruppe sonst etwa neun Personen ueberschreiten wuerde
• Gemeinsame Abhaengigkeiten ueber ein Scrum of Scrums koordinieren, bei dem Developers-Vertreter aus jedem Team teamuebergreifende Blocker sichtbar machen
• Das interne Selbstmanagement jeder einzelnen Developers-Gruppe intakt lassen - Skalierungs-Frameworks koordinieren zwischen Teams, sie sollten Entscheidungen innerhalb eines Teams nicht wieder zentralisieren

Framework-Optionen fuer mehrere Teams:

• Nexus: Ein leichtgewichtiges Framework, das direkt auf Scrum aufbaut und ein Nexus Integration Team hinzufuegt, das dafuer verantwortlich ist, teamuebergreifende Abhaengigkeiten zu erkennen und aufzuloesen und ein einziges, integriertes Increment ueber etwa 3-9 Scrum Teams hinweg sicherzustellen.
• LeSS (Large-Scale Scrum): Erweitert Scrums Struktur auf mehrere Teams, die sich ein Product Backlog, einen Sprint und eine Definition of Done teilen, und minimiert bewusst zusaetzliche Rollen oder Zeremonien ueber das hinaus, was Scrum mit einem einzelnen Team bereits hat.
• Scrum of Scrums: Der einfachste Skalierungsmechanismus - Vertreter jedes Teams treffen sich regelmaessig, um Abhaengigkeiten zu koordinieren, ohne eine neue Framework-Ebene einzufuehren.

Praktische Skalierungshinweise:

• Priorisieren Sie, die Definition of Done ueber Teams hinweg konsistent zu halten, die am selben Produkt arbeiten
• Adressieren Sie Probleme der Teamdynamik auf Teamebene, bevor sie sich ueber mehrere Teams hinweg summieren
• Fuer verteilte oder global verstreute Developers-Gruppen pruefen Sie dedizierte Hinweise zu verteilten Teams
• Widerstehen Sie, Koordinationsaufwand (zusaetzliche Meetings, zusaetzliche Berichtsebenen) schneller hinzuzufuegen, als er tatsaechlich gebraucht wird - skalieren Sie die minimal noetige Struktur, nicht die maximal verfuegbare

Fazit

Developers sind die Verantwortlichkeit innerhalb des Scrum Teams, die dafuer sorgt, dass in jedem Sprint aus einem Product Backlog ein wirklich nutzbares Increment wird - ohne externe Vorgabe, wer was oder wie tut. Die Umbenennung von "Entwicklungsteam" zu "Developers" im Jahr 2020 war eine bewusste Korrektur: Es gibt ein Scrum Team, nicht einen Product Owner und Scrum Master, die ueber einem separaten Lieferteam stehen.

Ihre naechsten drei Aktionen:

1. Pruefen Sie, ob die Groesse Ihrer Developers-Gruppe im Bereich 3-9 liegt - ist sie darueber gewachsen, planen Sie eine Aufteilung, statt die Koordinationskosten zu absorbieren
2. Pruefen Sie, ob Aufgabenzuweisung tatsaechlich innerhalb des Teams geschieht, oder ob eine externe Rolle still und leise weiterhin Arbeit zuweist
3. Ueberpruefen Sie Ihre Definition of Done bei der naechsten Sprint Retrospective und bestaetigen Sie, dass das Team sich unter Terminddruck tatsaechlich daran haelt, nicht nur auf dem Papier

Cross-Funktionalitaet, Selbstmanagement und gegenseitige Verantwortung werden nicht einmal erreicht und dann automatisch aufrechterhalten - sie werden genauso aufgebaut wie das Produkt: iterativ, Sprint um Sprint, durch ehrliche Inspektion und bewusste Anpassung.

Häufig gestellte Fragen (FAQs)