Scrum ist ein starkes Fundament – aber kein Gesetz. In einem Projekt mit 30 Personen haben wir vier Regeln bewusst gebrochen. Ergebnis: schnellere Lieferungen bei höherer Qualität. Ein ehrlicher Praxisbericht über das, was wirklich half.

Letztens diskutierte ich mit ein paar Scrum Mastern aus dem IT-Bereich. Wir warfen mit denselben Buzzwords um uns –„agil”, “Scrum”, „flexibel”, aber je länger das Gespräch lief, desto klarer wurde mir: In ihren Projekten existierte diese Agilität vor allem auf dem Papier. Regeln wurden befolgt, weil das Lehrbuch sie vorschreibt, nicht weil sie dem Produkt halfen.

Wir sind den umgekehrten Weg gegangen. In einem Projekt mit einem Team von 30 Personen, aufgeteilt in zwei Produktteams, haben wir vier klassische Scrum-Regeln bewusst über Bord geworfen. Nicht aus Bequemlichkeit, sondern nach mehreren Anläufen und ehrlichem Inspect & Adapt. Genau das ist „agil”, das eigene Vorgehen regelmäßig zu hinterfragen. Das Ergebnis: spürbar mehr ausgelieferte Features pro Quartal – bei steigender Qualität.

Der häufigste Fehler, den ich sehe: Scrum wird zelebriert statt genutzt. Teams führen Zeremonien durch, weil sie im Framework stehen, und verwechseln das mit Agilität. Ein typisches Beispiel: ein Daily, in dem reihum Status referiert wird, weil „man das so macht” – während die eigentliche Abstimmung danach im Nebengespräch passiert. Solche Rituale kosten Zeit, ohne dem Produkt zu helfen.
Wir haben daraus zwei eigene Leitprinzipien gemacht:

• Scrum nicht dogmatisch umsetzen, sondern nur die Aspekte anwenden, die in der Zusammenarbeit mit dem Kunden echten Mehrwert bringen.
• Prinzipien an die Situation anpassen und, wo nötig, durch wirksamere Mittel ersetzen.

Das klingt simpel, ist aber die Grundlage für alles Weitere. Die folgenden drei Punkte sind nichts anderes als die konsequente Anwendung dieser Haltung.

Die Definition of Done (DoD) soll ein einheitliches „fertig” für alle Aufgaben schaffen. Das funktioniert – solange die Aufgaben vergleichbar sind. In unserem Projekt waren sie das nicht: Umfang und Art der Tasks unterschieden sich massiv, und wir mussten dem Kunden in kurzen Abständen ein Produkt-Inkrement liefern.

Eine starre DoD wurde damit zur Bremse: Releases verzögerten sich, weil Aufgaben formalen Kriterien genügen mussten, die im Einzelfall gar keinen Mehrwert hatten. Nach mehreren Versuchen haben wir sie gestrichen – und stattdessen voll auf individuelle Akzeptanzkriterien gesetzt: eine detaillierte, laufend gepflegte Checkliste pro Feature. Jeder Teil wird danach umgesetzt, getestet und beim Abschluss abgehakt.

Das brachte uns dieselben Vorteile, die eine DoD verspricht – plus die Geschwindigkeit, die sie uns genommen hätte:

• Gemeinsames Verständnis der Anforderungen im gesamten Entwicklungsteam.
• Regelmäßige, inkrementelle und schnelle Lieferungen.
• Hohe Qualität durch umfangreiches Testing.
• Bessere Prüfbarkeit auf jeder Team-Ebene.

Unterm Strich erreichen wir nicht nur dasselbe Ziel wie mit einer DoD, sondern auch die Business-Ziele des Kunden – schneller.

Die Lehre ist klar: Der Scrum Master (SM) sorgt für Arbeitseffizienz und coacht das Team, der Product Owner (PO) maximiert den Produktwert und priorisiert den Backlog. Beide Rollen sind wichtig – aber keine von beiden steuert das Projekt fachlich-organisatorisch durch den Alltag.

Der SM ist Coach und Facilitator, trifft aber keine technischen Richtungsentscheidungen. Unser PO sitzt beim Kunden, verantwortet Produktvision und Backlog – nicht die konkrete Umsetzung. Dazwischen klaffte eine Lücke: Wer koordiniert die Teams, hält den Überblick über Fortschritt, Backlog und Prioritäten, und sorgt für sauberen Informationsfluss? Diese Lücke wurde mit der Projektgröße zum echten Problem. Der Scrum Guide nennt als typische Teamgröße zehn Personen oder weniger – unser Setup sprengt das deutlich:

• 30 Personen, in zwei Teams.
• Vier Gewerke: Frontend, Backend, UX/UI, QA.
• Kundenseite: zusätzlich das Product-Owner-Team und das Entwicklungsteam des Kunden.

Deshalb haben wir eine Projektmanagement-Rolle (PM) ins Scrum-Team geholt – mit Aufgaben, die sich klar von SM und PO abgrenzen:

• Organisatorischer Rückhalt für die Teams (Planung, Kommunikation, Koordination), damit sich das Team voll auf die Entwicklung konzentrieren kann.
• Entlastung des PO auf Kundenseite bei Planung, Priorisierung und Backlog-Pflege.
• Proxy zwischen Sub-Teams und Kunde – die richtigen Anforderungen zum richtigen Zeitpunkt mit den richtigen Ressourcen.
• Kein Eingriff in die Team-Arbeit selbst: Das Team organisiert sich weiterhin eigenständig.

Bei 30 Personen liegt die Frage nahe: Warum nicht gleich ein Skalierungsframework wie SAFe oder LeSS? Wir haben auch verschiedene Frameworks geprüft und uns dann gemeinsam dagegen entschieden. Der wichtigste Grund war Konsistenz mit unserem eigenen Prinzip: Unser ganzer Ansatz reduziert Overhead und Dogma, während SAFe, LeSS & Co genau das Gegenteil mitbringen – zusätzliche Ebenen, neue Rollen und weitere Zeremonien. Das hätte konterkariert, was wir mit dem Verzicht auf DoD und Story Points gerade gewonnen hatten.

Hinzu kommt die Teamgröße: Mit zwei Sub-Teams bewegen wir uns am unteren Ende dessen, wofür Skalierungsframeworks überhaupt gedacht sind. Sie zahlen sich erst bei vielen parallelen Teams aus und wären für uns schlicht überdimensioniert gewesen. Uns ging es um die Koordination und Kommunikationsfluss zwischen den Gewerken – und das ließ sich mit einer einzigen PM-Rolle lösen, statt eine ganze Framework-Schicht einzuziehen.

Story Points messen den relativen Aufwand einer User Story. Genau dieses „relativ” wurde bei uns zur Dauerquelle für Missverständnisse – in den Teams und mit dem Kunden. Jede:r interpretierte die Punkte anders, was zu langen Diskussionen und wenig Zeit für die eigentliche Entwicklung führte. Der Versuch, Story Points über Formeln und Excel-Tabellen in Personentage umzurechnen, kostete nur noch mehr Aufwand.

Unser Fazit nach mehreren Anläufen war eindeutig: Wir schätzen User Stories direkt in Personentagen. Für unser Projekt und unseren Kunden ist das schlicht klarer und präziser – und es spart die Übersetzungsschleife komplett.

Natürlich gibt es das Gegenargument: Personentage verleiten dazu, in Aufwand statt in Wert zu denken. Für uns überwiegt aber der Vorteil einer gemeinsamen, eindeutigen Sprache – über den Wert entscheidet ohnehin der PO bei der Priorisierung, nicht die Schätzeinheit.

Diese vier Punkte sind kein Rezept für das perfekte agile Projekt – und sie gelten nicht für jedes Team. Ein kleines Greenfield-Projekt braucht weder eine PM-Rolle noch den Verzicht auf eine DoD. Voraussetzung für unseren Weg war ein erfahrenes Team, das Disziplin bei den Akzeptanzkriterien hält. Wer Regeln streicht, ohne sie durch etwas Besseres zu ersetzen, landet nicht bei Agilität, sondern im Chaos.

Bei uns hat sich der Mut ausgezahlt – und zwar messbar. Innerhalb eines Jahres mit Erprobung und Anpassung stiegen Qualität und Anzahl der gelieferten Features deutlich.

Scrum gibt Projekten Transparenz und kontinuierliche Verbesserung. Aber je nach Kontext und Kundenanforderungen darf – und sollte – man einzelne Prinzipien anpassen, um agil zu bleiben oder es sogar mehr zu werden. Oder, wie es ein Scrum-Grundprinzip sagt: Das Team lernt aus Erfahrung und passt sich an.

Dieses pragmatische Vorgehen passt zu uns: SYZYGY Techsolutions – Enterprise IT-Spezialist mit agilem Mindset und Hands-on-Mentalität. Wir sind überzeugt: Genau hinzuschauen, was ein Projekt wirklich braucht, bringt am Ende mehr als das starre Festhalten an Frameworks und Guidelines