Das Entwicklungsteam Selbstorganisiert arbeiten — nicht nur Aufgaben abarbeiten

Das Entwicklungsteam ist die Mannschaft, die tatsächlich baut, was der Product Owner sich wünscht. Keine Hierarchie, kein Teamleiter, keine Einzelkämpfer. Stattdessen: Ein crossfunktionales Team, das selbst entscheidet, WIE es die Arbeit erledigt — und gemeinsam die Verantwortung für das Ergebnis trägt.

Entwicklungsteam auf einen Blick

Was?
Die Umsetzungsrolle in Scrum
Größe
3-9 Personen (ohne PO und SM)
Prinzip
Selbstorganisiert und crossfunktional
Besonderheit
Keine Titel, keine Hierarchie innerhalb des Teams

Was bedeutet Selbstorganisation konkret?

Selbstorganisation heißt nicht, dass alle machen, was sie wollen. Es heißt: Das Team entscheidet gemeinsam, wie es die Arbeit erledigt — nicht der Chef, nicht der Projektleiter, nicht der Scrum Master.

Im Sprint Planning zieht sich das Team eigenständig Aufgaben aus dem Product Backlog. Wer was macht, klären die Teammitglieder untereinander. Das setzt Vertrauen voraus — und die Bereitschaft, Verantwortung zu übernehmen, statt auf Anweisungen zu warten.

Klassisch: Top-down Chef vs. Scrum: Selbstorganisiert
Klassische Hierarchie vs. Scrum-Selbstorganisation

Warum muss das Team crossfunktional sein?

Crossfunktional bedeutet: Das Team hat alle Fähigkeiten, die es braucht, um ein fertiges Produktinkrement zu liefern — ohne auf andere angewiesen zu sein. Designer, Entwickler, Tester? Alles in einem Team.

Warum? Weil Übergaben zwischen Abteilungen der größte Zeitfresser in der Produktentwicklung sind. Wenn der Designer erst sein Mockup an die Entwicklung weitergibt, die es dann an das Testing übergibt — dann dauert alles dreimal so lang und die Qualität leidet.

In Scrum arbeiten alle Disziplinen zusammen, gleichzeitig, im selben Sprint. Das produziert nicht nur schnellere Ergebnisse, sondern auch bessere — weil Probleme sofort auffallen, nicht erst drei Wochen später.

Wie groß sollte das Team sein?

Der Scrum Guide empfiehlt 3 bis 9 Personen im Entwicklungsteam (ohne Product Owner und Scrum Master). Warum genau diese Spanne?

  • Unter 3: Zu wenig Perspektiven, zu wenig Kapazität. Ein Ausfall einer Person lähmt das ganze Team.
  • 3-5: Ideal für fokussierte Arbeit. Kommunikation funktioniert ohne formale Strukturen.
  • 6-9: Mehr Kapazität, aber die Abstimmung wird aufwändiger. Ab hier lohnen sich Subteams für komplexe Themen.
  • Über 9: Zu viel Koordinationsaufwand. Besser: Zwei Teams bilden, die am selben Produkt arbeiten (→ SAFe oder Nexus).

Wichtig: Der Product Owner und der Scrum Master zählen nicht zur Teamgröße — es sei denn, sie arbeiten aktiv an der Umsetzung mit (was der Scrum Guide eigentlich nicht vorsieht).